This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

User Guide

Portal Server User Guide

Thank you for using the Real Load product.

On this first page of the user guide you will learn:

  • How to perform a simple HTTP/S test
  • The basic concepts of the product
  • How to determine the system capacity of a stressed server

Projects Menu

“alt attribute”

After you have signed in to the portal server, you will see a navigation bar whose first menu on the left is Projects. This is a file browser that displays all of your files. The view is divided into Projects and Resource Sets which contain the files for executing your tests and the measured test results. You can also store additional files in a Resource Set which contain e.g. instructions on how a test should be performed.

Among other things, you can:

  • Create, clone and delete projects.
  • Create, clone and delete resource sets (subdirectories of projects).
  • Upload and download files, create new files, display the content of files, edit and delete files.

There is also a recycle bin from which you can restore deleted projects, resources sets and files.

“alt attribute”

Measuring Agents and Proxy Recorders

“alt attribute”

In order to perform a test you need at least one “Measuring Agent” (load generator). If you want to test entire Web pages, you also need an “HTTP/S Proxy Recorder” to record the HTTP/S calls of the Web pages.

Ready-to-use Amazon EC2 instances of these two components are already available, which you can start by yourself. Alternatively, you can install an operate “Measuring Agents” and “HTTP/S Proxy Recorders” on your own systems.

After you have started a “Measuring Agent” or “HTTP/S Proxy Recorder” you can register it in the portal server, and check the reachability by a “ping” at application level.

“alt attribute”

“alt attribute”

HTTP Test Wizard

“alt attribute”

Tests can be created in a number of different ways. You can even develop test programs from scratch that measure anything and use any protocol.

To keep it simple in the first step, we introduce the “HTTP Test Wizard”, with which you can easily define HTTP/S sessions and run them as tests.

Test Preparation

  1. Navigate to the “Projects Menu” and create a new Project and a new Resouce Set.
  2. Navigate to the “HTTP Test Wizard”.
  3. Create a New Session in the “HTTP Test Wizard”.
  4. Save the New Session to the Project and Resouce Set which you have created before.

“alt attribute”

You now have an empty session to which you can add HTTP requests (URL calls).

Test Creation

Now add one or more URLs to the test. If you want to subdivide the URLs into individual groups, first add a “Measuring Group”, then add the associated URLs and then again, add the next “Measuring Group” with the corresponding URLs.

If you define a “Measuring Group”, the (separately measured) response time of the group is measured overall URLs of the group.

“alt attribute”

Entering a URL is easy. Select the HTTP method (GET, POST, …) and enter the absolute URL. If you want to execute an HTTP POST method, first select the requests content type and then enter the data of the post request. Finally click at the “Add URL” button at the bottom of the dialog.

After you’ve created the test, it looks similar to this:

“alt attribute”

Save the test again (save session) and then debug the test.

Debugging the Test

In order to debug a test, at least one “Measuring Agent” must be available. This is because it is a remote debugger.

If you click on “Debug Session”, the test is automatically transmitted to one of your measuring agents and the debugger is started. If you have registered several measuring agents, you can select in the debugger at the top right on which measuring agent the debug session will be executed.

“alt attribute”

During debugging, please pay close attention to the HTTP status code you get from the URLs. For example, if you receive a 404 status code (not found), you have probably entered a faulty url. In such a case, cancel the debug session, correct the URL and then start the debugger once again.

As you may have already noticed, the HTTP status code of the URLs has not yet been checked by the debugger. Return to the HTTP Session Wizard and configure the corresponding HTTP status code for each URL (section “Verify HTTP Response”). Don’t forget to click at the “Modify URL” button at the bottom of the dialog.

“alt attribute”

Debug your test one last time and then save it.

Generating the Code

Generating the code is pretty easy. First click on “Generate Source Code” and then on “Compile & Generate JAR”.

“alt attribute”

“alt attribute”

Then click on “Define New Test”.

Defining the Test

Defining a test with the “HTTP Test Wizarzd” is also quite easy. Optionally, you can enter here a test description. Then click on “Define Test”.

“alt attribute”

After you have clicked on “Define Test” the test is created and the view changes from the “HTTP Test Wizarzd” menu to the “Tests” menu.

Tests Menu

The Test Menu shows all tests that you have defined - across all Projects and Resource Sets. You can also filter the view according to Projects and Resource Sets, and sort the tests in different ways.

“alt attribute”

Note that a test is something like a bracket that only contains references to the files that are required for the test execution. There a no files stored inside the test itself.

On the one hand, this means that a test become invalid/corrupted if you delete the corresponding resource files of the test in the Projects Menu. On the other hand, this also means that all changes to files that are saved in the tree of the Projects Menu are immediately applied to the test.

Each test has a base location from which it was defined (Project and Resource Set) and to where also the test results are saved.

A test itself can reference its resource files in two ways:

  • Resource Files that reside in the base location of the test (the test core files).
  • Referenced Files that are located in other Projects / Resource Sets. These are typically libraries, plug-ins and input files which are used/shared by several, different tests.

Defining a Test Job

After you have clicked on a test on “Define Test Job” and then on “Continue”, the intermediate “Define Test Job” menu is displayed.

“alt attribute”

In contrast to a “test”, all referenced files of the test are copied into the “test job”. For this reason there is also the option “Synchronize Files at Start of Job” which you should always have switched on. At “Additional Job Arguments” you can enter test-specific command line arguments that are transferred directly to the test program or test script. However, you usually do not need to enter anything.

After you have clicked on “Define Load Test Job” the test job is created and the view changes from the “Tests” menu to the “Test Jobs” menu.

Test Jobs Menu

In this menu all test jobs are displayed with their states. The green point at the top right next to the title indicates that all measurement agents that are set to active can also be reached. The color of the point changes to yellow or red if one or more measuring agents cannot be reached / are not available.

“alt attribute”

A test job can have one of the following state:

  • invalid: The job is damaged and can only be deleted.
  • defined: The job is defined locally in the portal server, but has not yet been transmitted to a masuring agent. Jobs that are in this state can still be modified.
  • submitted: The job was transmitted to a measuring agent, but is not yet ready to be started.
  • ready to run: The job on the measuring agent is ready to start (the corresponding data collector process is already running on the measuring agent, but the job itself is not yet started).
  • start failed: The start of the job has failed.
  • running: The job is currently running and can be monitored at real time.
  • completed: A job that was previously running is now completed (done).

As soon as a job is in the “defined” state, it has a “local job Id”. If the job is then transmitted to a measuring agent, the job has additionally a “remote job Id”.

Starting a Test Job

After you have clicked on “Start Test Job” in a test job you can select/modify the measuring agent on which the job will be executed and configure the job settings.

“alt attribute”

Input Fields:

  • Measuring Agent: The measuring agent on which the test is executed.
  • Number of Users: The number of simulated users that are started.
  • Max. Test Duration: The maximum test duration.
  • Max. Loops per User: The maximum number of sessions executed per user (the number of iterations of the test per user). Each time a new session of a user is started, the user’s session context is reset.
  • Loop Iteration Delay: The delay time after a session of a user has ended until the next session of the user is started.
  • Ramp Up Time: The length of time at the beginning of the test until all simulated users are started. Example: with 20 simulated users and a time of 10 seconds, a new user is started each 0.5 seconds.
  • Additional Arguments: Additional values which are transferred on the command line when the test script is started. These arguments are test specific. For tests that were created with the “HTTP Test Wizard” you can specify for example the following values: “-tcpTimeout 8000 -sslTimeout 5000 -httpTimeout 60000” (TCP connect timeout / SSL handshake timeout / HTTP processing timeout) which are considered by the executed URL calls and override the default values.
  • Debug Execution: This option effects that detailed information are written to the log file of the test. For example variable values which have been extracted from input files or from HTTP responses as well as variable values which are assigned at runtime. Only activate this option if you have problems with the execution of the test.
  • Debug Measuring: Effects that the Data Collector of the Measuring Agent writes the JSON objects of the DKFQS All Purpose Interface to its log file. This option can be enabled to debug self-developed tests that have been written from scratch.

Normally you do not have to enter any “Additional Arguments” and leave “Debug Execution” and “Debug Measuring” switched off.

After clicking on “Start Test Job”, the job is started on the measuring agent and the status of the job is now “Running”. Then click on “Monitor Jobs”.

“alt attribute”

Real-Time Monitor Menu

The real-time display shows all currently running jobs including their measured values and measured errors.

“alt attribute”

You can also suspend a running job for a while and resume it later. However this has no effect on the “Max. Test Duration”.

“alt attribute”

After the job is completed you can click on “Analyze Result”. The view changes then to the “Test Results” menu.

“alt attribute”

Test Results Menu

The “Test Results” menu is a workspace into which you can load multiple test results. You can switch back and forth between the test results. As in the “Real-Time Monitor” menu, all measured values and all measured errors are displayed. In addition, percentile statistics and diagrams of error types are also displayed in this menu.

This menu enables you also to combine several test results into a so-called “load curve” - and thus to determine the maximum number of users that a system such a Web server can handle (see next chapter).

“alt attribute”

The Summary Statistic of a test result contains some interesting values:

  • Avg. Measured Samples per Second: These are the number of successful measured values per second, counted over the whole test (in other products also so-called as “hits per second”).
  • Max. Concurrent Users: These are the maximum number of concurrent user that have been really reached during the test (which may differ from the “Number of Users” defined when starting the test).
  • Max. Pending Samples: This is the maximum amount of requests to the server, for which no immediately response has been received, measured over the whole test (the maximum traffic jam of the requests).
  • Average CPU Load: This is the average CPU load in percent on the measuring agent (load generator) which was captured during the execution of the test. If this value is greater than 95% the test is invalid because the measuring agent itself was overloaded.

Since several thousand to several million response times can be measured in a very short time during a test, the successfully measured response times are summarized in the response time diagrams at 4-second intervals. For this reason, a minimum value, a average value and a maximum value is displayed for each 4-second interval in such diagrams.

However, this summarization is not performed for percentile statistics and for measured errors. Every single measured value is taken into account here.

Determining System Capacity

The maximum capacity of a system, such as the maximum number of users that a web server can handle, can be determined by a so-called “load curve”.

To obtain such a load curve, you must repeat the same test several times, by increasing the number of users with each test. For example a test series with 10, 50, 100, 200, 400, 800, 1200 and 1600 users.

The easiest way to repeat a test is to clone a test job. You can then enter the higher number of users when starting the test.

“alt attribute”

A measured load curve looks like this, for example:

“alt attribute”

As you can see, the throughput of the server increases linearly up to 400 users - with the response times remaining more or less the same (Avg. Passed Session Time). Then, with 800, 1200 and 1600 users, only individual errors are measured at first, then also many errors, with the response times now increasing sharply.

This means that the server can serve up to 400 users without any problems.
But could you operate the server with 800 users if you accept longer response times? With 800 users, 745,306 URL calls were successfully measured, with only 50 errors occurring. To find it out, let’s compare the detailed response times of “Page 1” of 400 users with 800 users.

Response Times of “Page 1” at 400 Users: “alt attribute”

Response Times of “Page 1” at 800 Users: “alt attribute”

The 95% percentile value at 400 users is 224 milliseconds and increases to 1952 milliseconds at 800 users. Now you could say that it just takes longer. However, if you look at the red curve of the outliers, these are only one time a little bit more than 1 second at 400 users, but often more than 8 seconds at 800 users. Conclusion: The server cannot be operated with 800 users because it is then overloaded.

Now let’s do one last test with 600 users. Result:

“alt attribute”

The throughput of the server at 600 users is a little bit higher than at 400 users and also little bit higher than at 800 users. No errors were measured.

Response Times of “Page 1” at 600 Users: “alt attribute”

The 95% percentile value at 600 users is 650 milliseconds, and there are only two outliers with a little bit more than one second. Final Conclusion: The server can serve up to 600 Users, but no more.

Troubleshooting a Test

In rare cases it can happen that a test does not measure anything (neither measurement results nor errors). In this case you should either wait until the test is finished or stop it directly in the “Real Time Monitor” menu.

Then you can then acquire the test log files in the “Test Jobs” menu and search for errors.

“alt attribute”

“alt attribute”

1 - AWS Measuring Agents

How to locate and use AWS based Mesuring Agents

This document describes how to launch Measuring Agents in AWS as EC2 instances. Readers are assumed to be familiar with AWS EC2 terms used in here, in particular if launching Measuring Agents manually.

Listing available AWS AMIs

We make pre-installed Measuring Agents available for everybody to use in AWS redy-to-run AMIs. No additional costs (beyong the costs charged by AWS) apply when using these images.

To obtain a list of these ready to run AMIs proceed you can use one of these options:

Via our Desktop Companion

Our Desktop Companion allows you to manage AWS Measuring Agents. You can launch and terminate agents as well as register them directly with the Real Load Portal with a few mouseclicks.

Refer to the Desktop Companion Documentation for further information.

Via the Real Load portal

Login to the Real Load portal and then head to the Measuring Agents configuration section. Then click on the AWS logo:

… and a list of available AWS AMIs will be displayed.

Via the AWS Console

Using the AWS console locate AMIs belonging to our AWS account 775953462348 in your preferred AWS region. This can be done by looking for public images owned by our account, as illustrated in this screenshot:

For example in the Sydney region (ap-southeast-2) you’ll find the above listed AMI. If you can’t find an AMI in your desired region please contact us so that we can make it available.

Launching an AMI

Via our Desktop Companion

Our Desktop Companion allows you to launch AMIs with a mouseclick.

Refer to the Desktop Companion Documentation for further information.

Via the AWS Console

Once you’ve located a suitable AMI you can launch it as you would with any other Linux image as illustrated in this section.

Configure a Security Group

In order for the AMI to be reachable from the Real Load Portal you’ll need to configure a Security Group allowing inbound connections to port 8080 as a minimum.

Set the Measuring Agent secret

In order to protect access to your Measuring Agent we strongly recommend setting a non-default secret when launching the AMI.

The secret can be set at launch time by providing User Data to the AMI as follows (replace “secret” with the secret of your choice):

echo "AGENT_SECRET=secret" > /home/ec2-user/

(Optional) Set instance tag

If you want this instance to appear in the Desktop Companion application then you’ll have to set the “REAL_LOAD_AGENT” tag to “true” when launching.

Select the Security Group

(Optional) Select SSH key

If for some reasons you think you might need to login via SSH to the Measuring Agent instance, then select an SSH key. This is not required for normal agent operations.

Configure EC2 instance in Real Load Portal

Via our Desktop Companion

Our Desktop Companion allows you to configue EC2 instances with a mouseclick.

Refer to the Desktop Companion Documentation for further information.

Manual Configuration

Once the EC2 instance is up and running, you’ll need to configure it in the Real Load portal so that you can execute load tests from it.

Once added you can validate connectivity to the agent as shown in this screenshot:

Terminating EC2 instances

Once you’ve completed your load testing it’s important to terminate the Measuring Agent instance to avoid unwatend AWS charges.

Via our Desktop Companion

Our Desktop Companion allows you to terminate EC2 instances and remove it from the Real Load Portal configuration with a mouseclick.

Refer to the Desktop Companion Documentation for further information.

Via the AWS Console

Terminate the instace as you would terminate any other Linux instance.

Remove EC2 instance from Real Load Portal

Via our Desktop Companion

Our Desktop Companion allows you to remove Measuring Agent instances with a mouseclick.

Refer to the Desktop Companion Documentation for further information.

Manual Configuration

From the Meausring Agents menu select to delete the agent.

Alternatively you could decide to keep the agent configured and simply deactivate it. Disabling is recommended to avoid warning messages in the Portal console about failing connectivity tests.

2 - HTTP Test Wizard

User Guide | HTTP Test Wizard

“alt attribute”

Overview and Functionality

The HTTP Tests Wizard supports you to create sophisticated tests in an easy way. You can compile (define) the entire test via the user interface and then generate a ready-to-run test program from this definition. A powerful debugger helps you to perfect your test.

As the name suggests, the HTTP Tests Wizard is optimized for the execution of HTTP/S tests. However, by using plug-ins, any other protocols can also be tested and measured (such as SMTP, DNS queries, DB-SQL queries, etc.).

HTTP Tests Wizard Features:

  • No programming required (except for self written plug-ins). You can create your test through the powerful user interface by assembling all required functionalities via simple dialogs.
  • The executed HTTP/S calls can be either entered manually our can be inported from a Proxy Recorder session.
  • Variable values (variables) can be extracted and assigned directly via the user interface.
  • Integrated Remote-Debugger: The defined test can be debugged in advance on any Measuring Agent - before generating the test program. The degugger supports also to define variables as well as to define variable-extractors and variable-assigners at the fly, which are adopted into the test.
  • After the test has been passed by the debugger, the defined test can be automatically converted into a performance-optimized test program.

Session and Session Elements

The test sequence is referred to as a so-called “Session”, whereby each simulated user repeatedly executes the session in a loop (so called “User Session” or “Session Loop”).

In order to define a test sequence, you can add various “Session Elements” to a session:

  • User Input Field: Displays an additional input field when starting the test and stores the entered value in a global variable.
  • Measurement Group: Measures the execution time over several session elements.
  • URL: Executes a HTTP request and receives the HTTP response. Measures the execution time, and verifies the HTTP response. The HTTP response can either received synchronously or asynchronously (see also URL Synchronisation Point). Supports “Bound to URL Plug-Ins” which, among other things, can modify HTTP request and postprocess HTTP responses.
  • URL Synchronisation Point: Synchronizes asynchronously received HTTP responses.
  • Delay Time: Delays the execution of the user session for an amount of time.
  • Basic Authentication: Adds a Basic Authentication username and password to all or selected URLs.
  • SSL/TLS Client Certificate: Adds a SSL/TLS Client Certificate to all or selected URLs.
  • General Request Header Field: Adds a HTTP request header field (for example “User-Agent”) to all or selected URLs.
  • Cookie Modifier: Sets/Extracts/Deletes cookies.
  • Plug-In: Initializes and executes a “Normal Session Element Plug-In”.
  • Input File: Reads an input file line by line, tokenizes the line and extracts the values of the tokens into variables.
  • Output File: Stores the values of variables into an output file.

“alt attribute”

Adding session elements is in most cases quite simple and self-explanatory, but it can be a bit challenging for URLs and Input Files. For this reason, adding of these two session elements is described in more detail in the next two sub-chapters.

Adding URLs

When adding an URL you have at least to select the HTTP Method (for example GET) and to enter the absolute URL (https://<host>/path).

Checking the HTTP response code and the HTTP response content is optional, but strongly recommended, as otherwise the test result may contain false positive results.

“alt attribute”

The following fields can be entered or selected:

  • General Area
    • HTTP Method: Select the HTTP method (GET, POST, …).
    • URL: Enter an absolute URL, inclusive (optional) query string parameters. Example:
    • Execute - synchronous or asynchronous: Select how the HTTP response is received. If you choose “asynchronous” then you have also to add an “URL Synchronisation Point” to the test sequence after the asynchronous executed URLs.
    • Error Handling: Select what happens if the HTTP request fails or if the HTTP response is invalid. “Final End” means that the whole test is aborted.
    • Enable Implicit Assigners ${<variable-name>}: If checked, then placeholders for variables are considered in the URL as well as in the HTTP request header and content. Example: URL = https://${vHost}/?v=1&w=2, Variable vHost = “”, Result = . Note insted of using inplicit Assigners you can also define Variable Assigers (see next chapter: Variables).
  • HTTP Request Content Area | Only fill in this area if the HTTP request contains a content, for example for POST requests.
    • Request Content Type: Select or enter the request content type. For example “application/x-www-form-urlencoded” or “application/json”.
    • Request Content Charset: Select or enter the request content charset - or let the field blank if not applicable.
    • Direct Value or Read From File: Select if the request content data are directly entered here or are read from a file.
    • Request Content Data: Enter the request content data (if they are not read from a file). Note: select first the Request Content Type before you enter the Request Content Data.
    • Also send Zero Content Length: If checked, but no content is available, the HTTP request header field “Content-Length: 0” is sent.
  • Additional HTTP Header Fields Area
    • You can enter additional HTTP request header fields here which are only applied for this URL. Note: additional HTTP request header fields that apply to all URLs should instead be defined by using a “General Request Header Field” session element.
  • Verify HTTP Response Area | Note: you should configure at least a HTTP response code in order to verify the test result.
    • Verify HTTP Status Code: Select the expected HTTP response code(s).
    • Verify Content Type: Select the expected HTTP response content type(s).
    • Verify Content Text: Enter text fragments that must be present in the HTTP response content, or let the fields blank if not applicable.
  • Plug-Ins Area
    • Here you can add “Bound to URL Plug-Ins” (see chapter “Plug-Ins”).

Adding Input Files

Input files are text files (*.txt, *.csv) whose content is read line by line during the test. Each line is divided into tokens from which values of variables are extracted. Empty lines are skipped. Note that the variables must first be defined before you can add an input file.

The following fields can be entered or selected:

  • Token Delimiter: The token delimiter. This is usually a single character, but can be also a string.
  • Comment Tag: Lines which are starting with the comment tag are skipped. You can place also the comment tag within a line which means that the remaining part of the line is ignored. The comment tag is usually a single character, but can be also a string.
  • Cyclic Read: If not checked, then the test will end when no further line can be read (at eof). On the other hand, if checked, the file is re-read after the end of file was reached.
  • Randomize Lines: if checked then the order of the lines is randomized each time when the file is read.
  • Trim Values: If checked then whitespace characters are removed from the start and end of the extracted values (tokens).
  • Remove Double Quotes: If checked then double quotes are removed from the extracted values (tokens).
  • Scope: Get Next Line per:
    • Global: Reads only a single one line of the file. The line is read at the start of the test.
    • User: Reads each time a line from the file when a simulated user is started.
    • User Session: Reads each time a line from the file when a simulated user starts a new session loop iteration.
  • 6x Variable - Token[Index]: You can configure up to 6 token indexes whose values are extracted into variables.


The HTTP Tests Wizard (as well as the debugger) supports to define variables and to extract and assign variable values from/to session elements. Variable definitions which are (remotely) made in the debugger are automatically synchronized with the HTTP Test Wizard at portal server side.

The data type of a variable is always a string, which can also be empty, but is usually never null.

Defining Variables

“alt attribute”

When defining a variable, the following attributes can be set:

  1. Variable Name
  2. Scope: “Global”, “User” or “User Session”
  3. Defailt Value (initial value)

For variables with the scope “Global” there is only one instance which is initialized when the test is started.

For variables that have the scope “User”, there is a separate instance for each simulated user, which is initialized when the user is started.

In the case of variables with the scope “User Session”, a new instance is created and initialized at the start of each iteration of the session loop. The visibility is resricted to the current session loop of the simulated user.

Variable Extractors and Assigers

Variable extractors are definitions which contain instructions about how to extract a value from a session element into a variable. Variable assigners, on the other hand, are definitions that contain instructions how to assign or replace a value of a session element.

The following two images show a variable extractor that extracts a dynamic value from URL[2], and a variable assigner which assigns the value to a JSON post request of URL[3].

“alt attribute”

“alt attribute”

While variables (almost) always have to be defined manually, the definition of variable extractors and assigners is usually done implicitly (semi-automatically), depending on the context of the session element.

For example, if you define an input file, you must first create the variables that contain the extracted values (for username and password in this example). If you then assign the line token numbers to the variables, the corresponding variable extractors are automatically created.

“alt attribute”

“alt attribute”

“alt attribute”

Note: In this example above, a separate username and password are read from the input file for each simulated user and assigned to the value of the corresponding variables. For this reason the variables have the scope “User”, and the input file has the scope “Get Next Line per User”.

Assigning and Extracting Variable Values to/from URLs

Apart from Implicit Assigners (see “Adding URLs”), variable values of URLs can only be extracted and assigned by using the debugger. However, this is not a problem as definitions made in the debugger are automatically synchronized with the portal server.

Extracting variable values from URLs during debugging is quite easy. After executing a URL in the debugger, click on the symbol of the HTTP response header or of the HTTP response content and then extract the value.

“alt attribute”

“alt attribute”

Assigning variable values to URLs is a little bit more tricky. You have to interrupt the HTTP request in the debugger in the middle - after the request is initialized, but before the request is send to the server.

For this you have temporary to enable the option “HTTP Request Breakpoint” in the debugger, before you execute the URL (Next Step):

“alt attribute”

After you have clicked on “Next Step” you can assign the variable value to the pending HTTP request:

“alt attribute”

Click on the symbol of the URL, or of the HTTP request header or of the HTTP request content, and then assign the variable value:

“alt attribute”

“alt attribute”


Plug-Ins are reusable HTTP Test Wizard extensions that are manually programmed. They can also be published by manufacturing users and imported by other users. Therefore, before you start programming your own plug-in, take first a look at the already published plug-ins.

Plug-In Types

There are 3 types of plug-ins:

  • Normal Session Element Plug-Ins: As the name suggests, such plug-ins are executed as a normal session element. This type of plug-in is versatile and can, among other things, process variables, abort the current session, the user or the entire test, or even perform independent measurements with any protocol.
  • Bound to URL Plug-Ins: Such plug-ins are linked to a URL session element and can change the HTTP request before sending it to the server and post-process the received HTTP response - such as extracting variable values or checking the content of the HTTP response. Such plug-ins can also abort the current session, the user, or the entire test.
  • Java Source Code Modifier Plug-Ins: These are special plug-ins that can subsequently modify the source code generated by the HTTP Test Wizard. Usually such plug-ins are only used as a workaround if the HTTP Test Wizard generates faulty or incomplete source code.

Importing Published Plug-Ins

“alt attribute”

“alt attribute”

After you have imported the plug-in you have to load and compile it - then save the compiled plug-in.

“alt attribute”

“alt attribute”

“alt attribute”

“alt attribute”

After you have saved the compiled plug-in you can add it to your HTTP Test Wizard session. Plug-ins of the type “Java Source Code Modifier Plug-Ins” do not have to be added, but can be called directly after the source code of the test program has been generated.

Developing own Plug-ins

Own plug-ins can be developed in Java 8 or 11. The following example shows a plug-in which decode a base64 encoded string.

“alt attribute”

After clicking at “New Plug-In” the plugin type has to be selected (in this example “Normal Session Element Plug-In”): “alt attribute”

At the “General Settings” tab you have at least to enter the Plug-In Title and the Java Class Name. You should als enter a Plug-In Description which can be formatted by simple HTML tags. The onInitialize Scope can be set to “Global”, as this plug-in does not require any initialization. The onExecute Scope is set to “User Session” in order that all kind of variabe scopes are supported. “alt attribute”

At the next tab - “Input & Output Values” - a plug-in input and a plug-in output (Java-)variable is defined for the plug-in method onExecute. The values of this two Java variables will later correspond with two HTTP Test Wizard variables (which may have a different variable name): “alt attribute”

When you click at the next tab - “Resources Files” - you will see that the Java library is already added to the plugin. This is normal as all kind of plug-ins require this library. Here you may add also other Java libraries required by the plug-in - but in this case no other libraries are needed. “alt attribute”

Now at the “Source Code & Compile” tab, you can first generate the plug-in template. Then you have to extend the generated code with your own code, ie in this example you have to complete the Java import definitions and program the inner logic of the Java method onExecute. Then compile the plug-in.

“alt attribute”

“alt attribute”

At the last tab “Test & Save” you can first test the plug-in (remotely) on any Measuring Agent. To perform the test enter for example “SGVsbG8gV29ybGQ=” as input and you will see as output “Hello World”. “alt attribute”

“alt attribute”

Finally save the plug-in: “alt attribute”

After you have saved the plug-in click at the “Close” button. Then you will see the new plug-in in the plug-in list: “alt attribute”

Publishing Plug-Ins

If your plug-in can be used universally, it would be nice if you also publish it - to make it available to other users.

Note that you have to enable in your Profile Settings the option “Public In-App User” in order that you entitled to publish plug-ins.

Publishing plug-ins is especially useful for users who have additionally activated the option “Publish My Profile as Technical Expert” in their Profile Settings. This will significantly improve your visibility and competence.

“alt attribute”

“alt attribute”

3 - HTTP/S Remote Proxy Recorder

User Guide | HTTP/S Remote Proxy Recorder

By using an HTTP/S Proxy Recorder, the HTTP/S traffic from Web browsers and technical Web clients can be recorded and easily converted into a HTTP Test Wizard session.

The HTTP Test Wizard session can then be debugged and post-processed. Finally, an executable test program can be generated from the recorded session.

Functional Overview: Remote Proxy Recorder

“alt attribute”

An HTTP/S Remote Proxy Recorder has two service ports:

  • A Control Port that is addressed by the portal server.
  • A Proxy Port that records the data traffic from a Web browser or from a technical Web client.

All data traffic that passes through the proxy port is first decrypted by the Proxy Recorder and then encrypted again before it is forwarded to the target Web server(s).

In order to record a Web surfing session by a Web browser you have to start two different Web browser products on your local machine. For example:

  • A Chrome browser to operate the portal server (Web Browser 1), and
  • A Firefox browser to record the Web surfing session (Web Browser 2)

We recommend to use always Firefox as Web Browser 2.

To be able to record a Web surfing session, you have to reconfigure Web Browser 2:

  • Import the Proxy Server CA Root Certificate into the Web Browser 2.
  • Configure the Network Settings of Web Browser 2 to use the Proxy Server.

Additional note: Before you start recording a Web surfing session in Web Browser 2, you must always clear the browser cache.

Once the recording is completed you should undo the configuration changes in Web Browser 2 (restore the original network settings and delete the Proxy Server CA Root Certificate).

Registering a Proxy Recorder at the Portal

After you have started a HTTP/S Proxy Recorder as a cloud instance or installed it on one of your systems, you have to register it at the Portal Server.

“alt attribute”

“alt attribute”

You can set any user name and password for Proxy Authentication. The Control API Authentication Token was defined/set by the person who started or installed the Proxy Recorder.

Once you have registered the Proxy Recorder you can try to ping it on the application level:

“alt attribute”

“alt attribute”

Then try to connect to the Control Port of the Proxy Recorder. If this works, the Proxy Recorder is now ready for use.

“alt attribute”

“alt attribute”

Configuring Web Browser 2 for Recording

Import the Proxy Server CA Root Certificate

Click at the certificate icon and store the certificate at any location.

“alt attribute”

“alt attribute”

Then open the Web browser settings and import the certificate.

“alt attribute”

“alt attribute”

“alt attribute”

Since there is a small bug in some versions of Firefox, you have to close and reopen the Certificate Manager to view the imported certificate.

“alt attribute”

Configure the Network Settings

“alt attribute”

“alt attribute”

Recording a Web Surfing Session

Navigate with Web Browser 1 to the Proxy Recorder control menu.

“alt attribute”

Then configure the “Hosts Recording Filter” and click on the “Start Recording” icon.

“alt attribute”

In Web Browser 2, first clear the browser cache and then enter the URL where you want the recording to start.

“alt attribute”

“alt attribute”

In Web Browser 1 you can now see the recording of the first page. Before navigating to the next page in Web Browser 2, first insert a “Page Break” in Web Browser 1 with a brief description of the next page.

“alt attribute”

“alt attribute”

Then navigate to the next page in Web Browser 2.

“alt attribute”

In Web Browser 1 you can now see the recording of the next page.

“alt attribute”

Then continue as before. Insert a Page Break in Web Browser 1, navigate to a next page in Web Browser 2. and so on …

After you have done the recording click on the “Stop Recording” icon. Then convert the recording into an HTTP Test Wizard session.

“alt attribute”

Converting the Recorded Session

Here you can select different options. The HTTP Status Code Filter also supports * as a wildcard. An exclamation mark in the font of a value means “do not / exclude”.

The option Enable Parallel Execution of HTTP Requests should be enabled if you have recorded a session with a Web browser (as described above), but should be disabled if the recording was performed by a technical Web client.

“alt attribute”

Once you have clicked on the Convert button, the recorded session is converted and directly loaded into the HTTP Test Wizard.

“alt attribute”

After that debug the converted session in the HTTP Test Wizard and then save the HTTP Test Wizard session. Finally generate and execute the test.