Jmeter Setup

 JMeter is pure Java desktop application, it requires a fully compliant JVM 6 or higher. You can
download and install the latest version of Java SE Development Kit

 Download Jmeter the latest version of JMeter is Apache JMeter 4.2

 unzip the zip/tar file into the directory where you want JMeter to be installed.

Directory Structure
/bin: Contains JMeter script file for starting JMeter

/docs: JMeter documentation files

/extras: ant related extra files – Jmeter additional plugins

/lib/: Contains the required Java library for JMeter

/lib/ext: contains the core jar files for JMeter and the protocols

/lib/junit: Junit library used for JMeter

/printable_docs:
Launch JMeter
You can start JMeter in 3 modes

1. GUI Mode : “just run the file /bin/jmeter.bat to start JMeter in GUI mode”

2. Server Mode :

3. Command Line Mode

How to run JMeter in Non-GUI Mode

 Server Mode : used for distributed testing , works as client-server model. Where the server
computer in server mode and on client Jmeter runs on GUI mode.

 This is used to simulate the load generators to take the load.

 One jmeter server can control any number of jmeter instances

 are running exactly the same version of JMeter and are using the same version of Java on all
systems.

 If the test uses any data files, note that these are not sent across by the client so make sure that
these are available in the appropriate directory on each server

Configuring The load generators

 start the JMeter server component on all machines you wish to run on by running the
JMETER_HOME/bin/jmeter-server (unix) or JMETER_HOME/bin/jmeter-server.bat (windows)
script.

 Add the server IP to your client's Properties File, properties file on the controlling JMeter
machine. “/bin/jmeter.properties”, "remote_hosts" add the value of your running JMeter
server's IP address. Multiple such servers can be added, comma-delimited.

 Start the JMeter Client from a GUI client to check configuration, run menu will have 2 the
remote machienes with remote start and stop

Command Line Mode

GUI mode should only be used for debugging, as a better alternative, you should start the test on
remote server(s) from a non-GUI (command-line) client
Version control
Git : Git is a distributed version control system. Lets use this to version control our Jmeter
repository

Plugin Manager : Download link https://jmeter-plugins.org/wiki/PluginsManager/

Install Plugin manager

 Download the plugin manager and copy same to “C:\apache-jmeter-4.0\lib\ext” , This will
allow to manage the installed plugins

 JMeter Plugins are software components used to customize programs by extending abilities
and inserting functions

 ranging from graph tools and listener to developer tools.

Installation steps:
 Download the Plugins Manager JAR file

 Put the file in the lib/ext directory

 Restart JMeter

 Click “Options” and then “Plugins Manager

 The “Installed Plugins” tab shows you which plugins are installed.

 To uninstall, uncheck the box next to the plugin name. The Plugins in Italics can be upgraded
by choosing the version on the right.

 The “Available Plugins” tab shows which plugins can be installed. To install, check the box
next to the plugin name.
Jmeter test plan components
 Test Plan

 Thread Group

 Samplers

 Logic Controllers

 Preprocessors

 Post Processors

 Timer

 Configurations

 listner
Test Plan

 It’s a container for the overall tests

 Variables can de fined to use throughout the test, but can be overwritten if the setters in
anywhere in the tests

 If JMeter to be used for FVT then select functional testing, this instructs JMeter to save the
additional sample information - Response Data and Sampler Data - to all result files.

 This increases the resources needed to run a test and may adversely impact JMeter
performance.

 If more data is required for a sampler only, then add a Listener to it, and configure the fields as
required.

 An option exists here to instruct JMeter to run the Thread Group serially rather than in parallel.

 A special type of ThreadGroup that can be utilized to perform Post-Test Actions. The behavior of
these threads is exactly like a normal Thread Group element. The difference is that these types
of threads execute after the test has finished executing its regular Thread Groups.

o FVT Usage : After execution of my test If I want to delete a user which I have created
only for test. Thus I can send request of deleteuser in teardown threadgroup.

o PVT usage : If after the test I want to some reporting stuff on response data, then you
can add sample java code (beanshell processor) in tear down threadgroup and perform
the operation.
Thread Group: Schedulers in RPT

 This is used to configure the number of users and the ramp up plan.

 In terms of RPT these are schedulers.

 We can use different schedulers based of the requirements

 Various thread group are available apart from the basic ones, download them and copy them to
the “C:\apache-jmeter-4.0\lib\ and C:\apache-jmeter-4.0\lib\ext” (restart jmeter for the changes
to reflect )
Types of thread Group

Thread is a virtual users and thread group defines the execution behavior of the group of
threads.

Basic thread group from jmeter

Properties:

1. Number of users

2. Ramp-up period

3. Loop count – to set count for the test plan execution.

4. Scheduler to set the start and end time

5. Duration

6. Startup delay

7. Start time and end time

Step Thread group

This is basically used if we want to ramp users in step way, e.g. Every 30 seconds 100 users will be
added, until we reach 1,000 users. The first step is 1-100, the second 101-200, etc., because we defined
0 threads to run at the beginning. - It will take each of the steps (with 100 users each) 10 seconds to
complete. After that JMeter waits 30 seconds before starting the next step.
Ultimate Thread group

Add as many thread counts as needed, and choose the delay, startup time, hold time and shutdown
time for each row.
Adding New script

Note for WCM : Add cookie manager to handle all the session, to retain a handle between sessions or to
keep some state on the client side.

Steps :

1. Add a recording controller before starting the recording from the

2. Once this is done add the non-config element of HTTPS test script recorder

3. In browser set the proxy port with the value in the proxy port in the HTTPS proxy recorder

4. Click on the HTTPs test script recorder and then navigate to the request filtering if any patterns
to be excluded from recording like css, images mention the exclude patterns in Request Filtering
tab under URLs pattern to exclude.

5. Click start recording

6. Recorded script will be available under recording controller

7. Play back the scripts by adding listener and validate the response data
Listeners :

Used to show the results for the executed test plan samples.

To view reports, we need to add listeners. Elements and are used for showing results for executed test
plan samples.

There are many different types of listeners available to show results in Table, Tree, Graph or only log file
and Add any of them as per your requirement. Below are few types of listeners.

View Results Tree Listener: some requests are displayed in green color and some are displayed red
color. Green requests indicate that request is executed successfully. Red requests indicate that there
was some error during execution of request and it became fail.

Debug Sampler

The debug sampler shows the variables found as used in the script. If there is a problem with finding

the match or verifying we found it right.

To view what values are captured for post processor variable, add debug sampler and replay the

script. In View results tree listener will show list of values captured in Debug sampler for variables

declared.
User defined variables, Test Plan Variables

 Variables used to store the data

 Used to exchange information on from one session to other or tests

 This can be added from the config element User defined variables

 One of the basic usage of these variables is to define the environment variables

 To access the values of the variables in the sampler’s use ${var1}

 These user defined variables are shared across different thread groups, if you have different
thread groups then use different variable names if required.

 UDVs should not be used with functions that generate different results each time they are
called. Only the result of the first function call will be saved in the variable.

 UDVs are processed in the order they appear in the Plan, from top to bottom

 suggested that UDVs are placed only at the start of a Thread Group under thread plan

 Once the Test Plan and all UDVs have been processed, the resulting set of variables is copied to
each thread to provide the initial set of variables.

 Variables defined in this have global scope but can be overwriten by any local function ,
preprocessors, response extractors etc.
Random Variables

 JMeter allows generating random number values and using it in a variable.

 It can be done through the Random Variable config element.

Variable names : as name define it’s a any valid name

Format String : Prefix and post fix the strings

Min and Max Value : Boundaries

Per thread : if the it can be shared among threads or each thread has its own instance.

Random seed : seed value, if the same seed to be used for each thread.
Post Processor ( Correlation )
 Used to capture dynamic data from the response and posting it to the subsequent request

 Add View Results tree listener to see every request and response in detail

 Most commonly used is regular expression

JSON Extractor

 Allows extracting values from JSON responses using JSON syntax

 It will try to find the JSON path provided and extract corresponding value. If the path is not
found, it will use default value. For the null value the "null" string will be used.

 Rite click on the request and the JSON extractor post processor
 Once the post processor for JSON is added fill the following values

 Select the main sampler and subsampler

 The Json Path extractor should be placed under an HTTP Sampler.

o Variables Names

o JSON Path Expressions: expressions to extract content from the json response.
This is a JSON query

o Match Numbers: -1 for all, 0 for a random one, n for the nth one

o Compute concatenation var: create a variable like ${foo_ALL} containing the

concatenation of all extracted values,

o Default values: in the case the expression doesn’t apply to the json document
being processed.
JSON query language

 JSON Path expressions always refer to a JSON structure in the same way as XPath expression

 Since a JSON structure is usually anonymous and doesn't necessarily have a "root member
object" JSONPath assumes the abstract name $ assigned to the outer level object.

 JSONPath expressions can use the dot–notation

 JSONPath allows the wildcard symbol * for member names and array indices.

 To use the extracted value in the subsequent request ass the variable name as ${SyncVal}

JSONPath Description
$ the root object/element
@ the current object/element
. or [] child operator
recursive descent. JSONPath borrows this syntax from
..
E4X.
* wildcard. All objects/elements regardless their names.
Union operator in XPath results in a combination of node
[,] sets. JSONPath allows alternate names or array indices
as a set.
?() applies a filter (script) expression.
() script expression, using the underlying script engine.

JSON Extractor for the sync Value

Conditional Extraction

 Suppose now that we want to extract the value which has the ID as
“__o3fwph.ACTION.stateID$wizardStateID”

 In such cases we need the following JSON Path syntax elements

 ?() - filter function

 @ - current object

WCM Example:

$.page.content.elements[?
(@.id=='__o3fwph.ACTION.stateID$wizardStateID')].attributes.value

Here the root page is navigated to elements array and then the complete array is scanned to
check if the ID matches the given string when the match is found we get the attributes value
which is the wizard ID
XML Path Extractor

 For API tests where the response is in xml we can use the JMeter XPath Extractor

 XPath expressions are a language to select nodes within an XML document.

Adding the xpath extractor

Example XML xpath extractor

This is the response from the cohort creation API

XPath query to extract the cohort is “/cohort-message-response/cohort-message-response-

body/cohort-response/cohort-response-body/cohort-id/text() “

/ - document node

/cohort-message-response - this gives the first node i.e. the response node

/cohort-message-response-body – Gives the response body

Traverse until you reach the element that need to be fetched and the say “text()” gives the text
element of the cohort id.
CSV Data Set Config (Parameterization)
 A data set config element used for parametrization.

 Read values from file and use them in a test plan.

 Add the CSV data set config under thread group

 This will be processed before any samplers in current scope regardless of any position.
Parameters of CSV data set config

Filename : In this field, set CSV data file name and it's path. Example : C:\Test.csv.

Note : Make sure that file extension is provided

File Encoding : This field will be used when encoding is used to read the file.

Variable Names : Variable names list with comma-delimited to store values which are read
from csv file.

Delimiter : Delimiter to use to split data during reading it from file. Use comma(,) for comma
delimited file and \t for tab delimited file.

Allow quoted data? : If you wants to read double quoted(") data from file then set it to true.

Example : "SVT team".

Recycle on EOF? : Set it to true if data should be read from beginning of file when reaching
on end of file. Default it will be true

Stop thread on EOF? : Set it true if wants to stop thread on end of file if Recycle on EOF? =
false
CSV Sharing mode:

 All threads the file will be shared between all threads and each request will read one line in the
CSV file, in sequential order.

Results of Debug: 5 users 1 iteration

 Here each user Iine a thread group line a new line of the file
Current Thread , sharing mode should be used when we want each thread to open and read the CSV file
separately file , in this case, each user will read the CSV file from beginning to end.

Here each thread of a thread group will read same line for same iteration and move on to next line as
the iteration is moved.
current thread group then each file will be opened once per each thread group. each file is opened by
each thread group separately (not to be confused with the “Current thread” where each thread reads
the file separately. This basically means that each of the threads in each thread group reads the CSV file
from beginning to end without any impact on each other. This is applicable if we have 2 or more thread
groups.

o each thread group uses the CSV file separately

Edit Mode,

 when you choose the ‘Edit’ option under the ‘Sharing mode’ config element, this field
transforms to input. Then, you can provide your own string into this field instead of using a
predefined one.

 The main idea of this sharing mode is that you can use the same CSV file in multiple thread
groups, but only specified thread groups will share that file between each other.

 This mode hold s good if you want same file to be shared with 2 or more thread groups. i.e.
those thread groups will not pick same line.

 If the label in the Edit Mode matches then those thread group will use the same file and that
thread group will use new line

Edit Mode Example

1. CSV File : Create a CSV file with 5 names

2. Create 4 thread groups TG1, TG2, TG3,TG4

3. Add the CSV config data in al thread group and same file name
4. Click on the CSV Dataset Config File element of TG1

5. In Sharing mode Select Edit

6. Enter the Value as “Shared1_3” in TG1 and TG3

7. Enter the Value as “Shared1_3” in TG1 and TG3

8. In TG2 CSV dataset config for the Sharing mode as Edit enter text as “Shared2_4”

9. No execute the test plan

If you observed TG1 picked up susan and TG3 picked STEPHEN and same in case of Tg2
picked susan and TG4 picked Stephen
Pre-Processors
 This is added to a sampler before the sampler can be used for the prerequisite setup (i.e. to
generate some input).

Beanshell PreProcessor
 A good candidate to perform initialization routines.

 Can be used fetching data from a database, setting a timeout between sampler executions or
test data generation before Sampler execution.

 To Configure, Right click on sampler and select Add -> Pre Processors -> BeanShell PreProcessor.
BeanShell PreProcessor configs:

1. Name - the name of the sampler shown in the Thread Group tree

2. Reset bsh.Interpreter before each call - Resets the interpreter before each call and cleans
occupied memory. Setting this option as “True” might be useful for long running scripts, since
repeated invocations might consume a lot of memory

3. Parameters - JMeter parameters that will be passed to the BeanShell script

4. File Name - the path to an external BeanShell script that needs to be run

The BeanShell preprocessor script might be external or internal. If it’s internal, write it into the

“Script” field of the BeanShell Preprocessor. In any other case, need to use the ‘File Name’

configuration field.
Common variables used by the bean shell components:
 Ctx : all contenxt information about the current thread including sampler, and results
o ctx.getCurrentSampler().getCookieManager().getCookieCount().toString());

 Vars : this is a thread local set of variables stored in a map

o Get : Fetch the value of the variable ( vars.get(HOST”)

o Put : Vars.put(“finalname”,str) : To update a variable values

 Props : variables loaded as properties from external file jemeter.properties

 Prev : it holds the last result from the sampler

 Data: It holds the server response data

Example :

max = vars.get("maxCache");

int max = Integer.parseInt(max);

ctx.getCurrentSampler().getCacheManager().setMaxSize(max);
Logic Controller
This controller determines the order in which the samplers are processed, or it defines the sequence in
which the request is sent to the server.

Interleave Controller & Random Controller

Consider a scenario from WCM, where

1. Carer Login

2. Client Registration

3. Assign Carer to client

4. Don’t assign any carer

Here , Carer Login has to be executed once for a virtual user, then client registration to be executed
for every iteration and then assign the carer or don’t assign the carer for the clients has to be
executed randomly.

Run Time Controller

Here you can set the time to stop the request execution, lets say if you want the client registration only
for 8 hrs and then start with some other request such has updating client details, in that case push client
registration inside the run time controller which will execute for a given duration in the given test
duration.

Transaction Controller

This is required to get the response time of the entire transaction rather than page level response time
i.e. you group pages to form a transaction and measure response time.

Loop controller

Here you can loop the request for several iterations

If Controller

This is required to check if the samplers under this controller to be allowed to be executed or not. In
WCM the example for same would be to decide the login request for the local and MTMT logins.

Include Controller

Used to include external test fragments/test plan in your current test plan.
Timers
 Timers allow JMeter to delay between each request which a thread makes. Timer can solve the
server overload problem.

 Also, in real life visitors do not arrive to a website all at the same time, but at different time
intervals. So, Timer will help mimic the real time behavior

Synchronizing Timer :

 To make X number of threads to execute a specific step simultaneously we can use this feature

 It blocks the thread which reaches the steps first until the count reaches the X number and the
release the execution.

 This can be used at request level also.

 Select Add -> Timer -> Synchronizing Timer. Need to specify 2 parameters

o Number of simulated users to group by – How many threads to release at once.

o Timeout in milli sec – Max time to reach given number of threads beyond which it will
stop waiting and release the threads.

Constant Timer – This is similar to adding a constant think time

Uniform Random Timer : Pause the thread for a random think time, this has 2 parameters , Random
Delay Maximum – this is outer boundary limit i.e. max limit and constant delay offset – This is a fixed
delay time which will be added in random delay.

Example :

Random Delay Maximum : 3000 ms

Constant Delay offset : 2000 ms

This will pause the sampler by random number of ms ranging from 2000 to

0.x * 3000 + 2000 , here x is a digit b/w 0 to 9.

Constant Throughput Timer

 This is used to set up goal-oriented scenario, where the target is not to simulate X users but X
request per sec.

 This pause the thread to slow them to reach targeted output.

 This takes 2 parameters

o Target Throughput

o Calculate throughput based on options –

 This thread

 all active thread in current thread group

 all active thread

 All active threads in current thread group shared

 all active thread shared

Example :

To achieve 40 requests per min , configure the properties as :

Number of threads =2, rampup period =1

Loop count = forever

Target Throughput = 40

All active threads

Assertions

 This is to validate the response.

 Mostly commonly used assertions :

o Text response

o Document

o URL

o Response code

o Response message

o Response headers

 Status can be ignored if checking for negative tests.

 Response assertions has different sections as:

o Apply to

o Response field to tests

o Pattern Matching rules

o Patterns to test

Add assertions to request also to validate if the correct parameters are sent in the request.