1. Prepare a Session with one "Non Executable" URL Call

First, you need a recorded session that contains only one URL call (that never will be executed).

If you haven’t created any session, you can use the PageScanner tool or the Add URL to session. Or, you can load any existing session and remove all URL calls except the first one from that session and set the User's Think Time to a value of zero.

2. Configure the URL call as "non-executable"

For this example, we are going to take the URL call to the Apica Website and step you through the ZebraTester UI as to how to mark the call as non-executable. This is a special case as you would not normally do this except for a JUnit test case.

1. Click on URL

2. In the URL Details/Var Handler Edit the HTTP Request

3. Click either of the Special Options buttons/Icons to set the flag to ON or OFF

4. Place a check in the “Disable the execution of the URL during Load Test”

5. Apply the Special Option

3. Return to the Main Menu

Click refresh to reload the current page.

The URL call should now be shown with a yellow exclamation mark. ⚠

4. Add the JUnit Packages and the Test Package to the Session

By clicking from the (1) ZebraTester Main Menu on the URL that we set as non-executable, we open the Var Handler page, and from that, we (2) look for the black folder icon that opens the Declare External Resources (for Self-Developed Plug-ins) menu.

At the Declare External Resources menu and (3) add all Java *.jar files that are needed to execute the JUnit test.

This means that you have to add the jar files of JUnit itself (for example, junit-4.11.jar and hamcrest-core-1.3.jar) and the jar file that contains your JUnit test (for example CollectionTest.jar), so you end up with a table/list of all declared external resources at the bottom of the dialog. (4)

5. Add a System Properties File (Optional)

You can also declare a System Properties File as an external resource. Such a file will be parsed on the load generators just before the JUnit tests are executed. The key and values of such a file are stored in the Java virtual machine as system properties.

Hint: To debug the parsing of such a file you can enable the option "debug loops" when starting a load test. The debug output is written to the *.out file of the load test job.

The lines of the file can contain the following commands:

1. key = value

2. .includeProps = "<include-file-name>"

3. .includeProps = ["<include-file-name-1>", "<include-file-name-2>", ... , "<include-file-name-N>"]

• If a value ends with a backslash (\) the next line is appended to the value.

• Lines that are staring with a hash sign (#) are ignored.

Example saved and declared as an External Resource called “SystemProperties.txt”:

# General settings

loggingBufferSize = 1000

memoryStatsEnabled = true

# JSON data

jsonRequest = {\

     "defaultID": 1, \

     "keys": [\

          {"id":1, "type":"A25", "value":"57FCCA5C9F39BC2E73B5"}, \

     ],\

}

Once you have loaded all External Resources described in the JUnit testing page, navigate to the Project Navigator to the Plugins directory and call the JUnit wizard with the Icon

In the wizard, enter the full class name of the JUnit test or Search for it in the “Find Class in External Resources.”

Select which JUnit test methods should be executed during the load test

• Methods Execution Order
  You can select "Java/Reflection", "Alphabetical", "Randomly per Loop" or "In Parallel Threads".

• System Properties File
  If you have declared a System Properties File as External Resource you should select it here.

• Combine Error Types
  Similar measured errors that occur during the load test execution are grouped by ZebraTester to "Error Types" in order to get a better overview. In “Combine Error Types” you can choose how to group the Errors.
  You can select "Class + Method Name", "JUnit Failure Text", "Exception Text" or "Stack Trace".
  For example, if "JUnit Failure Text" is selected then all errors that contain exactly the same "JUnit Failure Text" will be in the same group.

• Plug-in Class Name
  The Java class name of the (new) generated JUnit plug-in.

• Plug-in GUI Label
  The label (text) of the plug-in that is displayed in the GUI.

• Plug-in Input Parameter
  🚫 Do not add or remove the plug-in input parameter. Leave them "as is".

Generate the JUnit Plug-In Code

Compile the Load Test Plug-in

Iin the Project Navigator, navigate to the directory where the load test program should be generated. In this screenshot this is called ‘MyTests’

Return to the Main Menu and add the JUnit Plug-In to the desired URL Call.

In the URL Details/Var Handler, locate the Load Test Plug-ins and click Add Plug-in

From the Var Handler, under, Add Load Test Plug-in, select the Defined Plug-ins from the dropdown box and Continue.

Add the Plug-in along with any additional parameters.

Note the Plug-in has been added, with any additional parameters.

Save the session using

From the Main Menu, Generate Load Test

On the Generate Load Test Program dialog, enter your Jave Classname and Continue

In the Project Navigator, you’ll find your class file created in your selected directory. Click the Execute Load Test Icon.

Before Executing a Load Test with a Plug-in, ZIP the Plug-ins and all external Local Resources before continuing to Executing. >>ZIP and execute

All JUnit plug-ins support to configure a Pacing Time (0 = no Pacing Time).

The Pacing Time defines how much minimum elapsed-time a simulated user should spent in the plug-in.

Example 1: If you configure a pacing time of 10 seconds and a simulated user executes the plug-in in 3 seconds the user will be delayed for 7 seconds in that executed loop (3 + 7 seconds = 10 seconds).

Example 2: If you configure a pacing time of 10 seconds and a simulated user executes the plug-in in 2 seconds the user will be delayed for 8 seconds in that executed loop (2 + 8 seconds = 10 seconds).

Example 3: If you configure a pacing time of 10 seconds and a simulated user executes the plug-in in 13 seconds the user will not be delayed in that loop (13 > 10 seconds)

During the execution of the load test you can examine the measured errors at real-time

Under the Error Overview (Real-Time) Latest Error under the Latest Error Snapshots you can drill into any row with the magnifier icon.

Drilling down into the Error log for details

After the load test has been completed, and you have acquired the test result, you can display the execution time for each JUnit method