Automation testing with J-Meter

APACHE JMETER
The Complete Guide to Test the Performance
of Web Applications
ABSTRACT
The Apache JMeter™ application is open source
software, a 100% pure Java application designed to
load test functional behavior and measure
performance. It was originally designed for testing
Web Applications but has since expanded to other
test functions.
Prince K. Raman Kinth

Introduction to Apache JMeter
[TYPE HERE] [TYPE HERE] [TYPE HERE]
Preface
What this book is about?
This book describes how to test web applications, build automation, performance and security
test knowledge implementation around test cycles. Practical knowledge on selective tools are
included to benefit the automation testers to pick right tool for test automation. Collection of
examples provided in certain chapters for better understanding over mobile testing
implementation.
Who is this book for?
This book is intended to be of most help to software testing professionals who are working in
mobile testing projects and interested to step into mobile testing assignments as beginners. The
target audience for this book includes:
potential and recent purchasers of test automation tools
those who already have a test automation experience and interested to know web
technology testing opportunities
anyone who is building in house mobile test automation, security tools
test tool vendors
technical managers who want to ensure that application testing projects provides benefits
management consultants and domain consultants

Table of Contents
What is Apache JMeter.................................................................................................................................5
How does Apache JMeter work? ..............................................................................................................5
Prerequisite of JMeter...........................................................................................................................6
How to Download JMeter.............................................................................................................................8
Steps to Launch JMeter.................................................................................................................................9
Configuration Element............................................................................................................................11
CSV Data Set Config:.........................................................................................................................12
HTTP Request Defaults:.....................................................................................................................13
User Defined Variables (UDV): .........................................................................................................14
HTTP Cookie Manager.......................................................................................................................14
Build JMeter Test Plan................................................................................................................................15
Add and Remove Test Plan Elements.....................................................................................................16
Steps to Add Elements to JMeter Test Plan........................................................................................16
Steps to Remove Elements from JMeter Test Plan.............................................................................17
Load and Save JMeter Test Plan Elements.............................................................................................18
Steps to Load Elements to JMeter Test Plan Tree ..............................................................................19
Steps to Load Elements to JMeter Test Plan Tree ..............................................................................19
Steps to Configure Tree Elements ......................................................................................................20
JMeter Actions on Test Plan...................................................................................................................21
Steps to Save JMeter Test Plan...........................................................................................................21
Steps to Run JMeter Test Plan............................................................................................................22
Steps to Stop to JMeter Test Plan .......................................................................................................22
Steps to Check JMeter Test Plan Execution Logs ..............................................................................22
What is Thread Group in JMeter?...............................................................................................................23
How to Create a Thread Group Element in JMeter Test Plan?...................................................................25
Components of Thread Group ................................................................................................................25
1) Action to be taken after a Sampler Error........................................................................................25
2) Thread Properties............................................................................................................................26
3) Scheduler Configuration.................................................................................................................26
Building a Web Test Plan ...........................................................................................................................27
Adding Users ..........................................................................................................................................27
Adding Default HTTP Request Properties..............................................................................................29

Adding Cookie Support ..........................................................................................................................30
Adding HTTP Requests..........................................................................................................................30
Adding a Listener to View Store the Test Results..................................................................................32
Logging in to a web-site .........................................................................................................................33
Building an Advanced Web Test Plan........................................................................................................34
Handling User Sessions with URL Rewriting ........................................................................................34
Using a Header Manager ........................................................................................................................35
Building a Database Test Plan ....................................................................................................................36
Adding Users ..........................................................................................................................................36
Adding JDBC Requests ..........................................................................................................................37
Adding a Listener to View/Store the Test Results..................................................................................41
Building an FTP Test Plan..........................................................................................................................41
Adding Users ..........................................................................................................................................42
Adding Default FTP Request Properties.................................................................................................43
Adding FTP Requests .............................................................................................................................44
Building an LDAP Test Plan ......................................................................................................................46
Adding Users ..........................................................................................................................................46
Adding Login Config Element................................................................................................................47
Adding LDAP Request Defaults.............................................................................................................47
Adding LDAP Requests..........................................................................................................................48
Adding a Response Assertion .................................................................................................................50
Building an Extended LDAP Test Plan ......................................................................................................51
Adding Users ..........................................................................................................................................52
Adding LDAP Extended Request Defaults.............................................................................................52
Adding LDAP Requests..........................................................................................................................53
Adding a Thread bind Request................................................................................................................53
Adding a search Request.........................................................................................................................54
Adding a Compare Request ....................................................................................................................56
Adding a Single bind/unbind ..................................................................................................................56
Adding an Add Request..........................................................................................................................57
Adding a Modify Request.......................................................................................................................57

Adding a Rename Request (moddn) .......................................................................................................58
Adding a Delete Request ........................................................................................................................59
Adding an unbind Request......................................................................................................................59
Building a WebService Test Plan ...............................................................................................................61
Creating WebService Test Plan ..................................................................................................................61
Adding Users ..........................................................................................................................................63
Rest WebService.....................................................................................................................................66
Building a JMS Point-to-Point Test Plan....................................................................................................66
Adding a Thread Group ..........................................................................................................................66
Adding JMS Point-to-Point Sampler ......................................................................................................68

What is Apache JMeter
The Apache JMeter is an open source, cross platform and user friendly desktop based Java
application, that makes it to run on any operating system with Java, e.g. Windows, Linux and
Mac. It is designed to perform various testing types like Performance, Load, Stress, Regression
and Functional testing, in order to get accurate performance metrics against your Web Server.
JMeter is not a browser and it doesn’t render html pages like any browser does, rather it works
on protocol level.
Stefano Mazzocchi of the Apache Software Foundation was the original developer of JMeter. He
wrote it primarily to test the performance of Apache JServ (currently known as Apache Tomcat
project). Apache redesigned it to enhance the GUI, to add more features and functional testing
capabilities.
How does Apache JMeter work?
JMeter send requests to a target server by simulating a group of users then collect data to
calculate statistics and display performance metrics through various formats.
JMeter workflow Diagram:

JMeter Features:
Important Note!: It is prohibited to conduct load testing on production environment or on any
website available over the internet without taking their prior approvals.
Now we will learn How to Download and Install JMeter. But before going to this there are set
of prerequisites.
Prerequisite of JMeter
1) Java Requirements:
JMeter is a 100% pure Java application, it requires a fully compliant JVM 7 or higher. If you do
not have Java installed on your system, you can download and install the latest version of Java
Software Development Kit (SDK) or Java Runtime Environment (JRE) from here or you can
follow the Step by Step Tutorial on Tools QA.
To verify Java installation, run “java -version” command from your command prompt. If Java is
successfully installed on your system, you would be able to see the following output on your
command console. In our tutorials, we are using Java 8.

In case you see the following screen, maybe JDK/JRE is not installed correctly on your system.
Or maybe you need to set system environment variables. Please foolow the tutorial on ToolsQA
for Step by Step process to Set up Java Environment Variable Path.
2) Operating System Requirements:
If your Operating system supports java, then JMeter should run correctly on your system. Below
mentioned operating systems have compliant Java implementation:
For more details on compatibility concerns related to Operating system and JVM, please refer
the following link: http://wiki.apache.org/jmeter/JMeterAndOperatingSystemsTested

How to Download JMeter
1) You can download the latest version of Apache JMeter binaries (tgz or zip) from here.
2) Once it is downloaded, it will by default save to the Downloads folder of your system.

3) Unzip the file on to your desired path. JMeter Directory Structure looks like this:
Point 1 : Bin folder contains templates, .bat, .sh, .jar files to start JMeter. It also contains User
& JMeters properties files.
Point 2 : Lib folder contains all required jar files.
Steps to Launch JMeter
Go to your JMeter bin folder to launch JMeter, in our case it would be
C:UserslsharmDownloadsapache-jmeter-3.0bin and locate appropriate file. You can also
run ApacheJmeter.jar in order to launch JMeter.

Click on Run button to move forward.
You will see a command prompt started as well.
After launching, you will be able to see JMeter main screen after few seconds.

Point 1: This is to Run the test.
Point 2: To save the Test Template.
Point 3: This is to Run/Play the test.
Point 4: Remote Start All
Point 5: Clear All Output Logs
Point 6: Elapsed time of current running test
Point 7: Running Threads and Total No. of Threads
Configuration Element
enable us to declare variables, so Samplers can use data through these variables. Configuration
element is accessible from only inside the tree node where you defined it. Also, if a configuration
element is defined inside a tree node, it will have high precedence than the same configuration
element which is defined in a parent node.
List of available Configuration Elements is as follows:
• Counter
• CSV Data Set Config
• DNS Cache Manager
• FTP Request Defaults
• HTTP Authorization Manager
• HTTP Cache Manager
• HTTP Cookie Manager
• HTTP Header Manager
• HTTP Request Defaults
• Java Request Defaults
• JDBC Connection Configuration
• Keystore Configuration
• LDAP Extended Request Defaults
• LDAP Request Defaults
• Login Config Element
• Random Variable
• Simple Config Element
• TCP Sampler Config
• User Defined Variables

Let’s discuss some important Configuration Elements:
CSV Data Set Config:
CSV Data Set Config element is used to read data from a text or CSV format file. For Example,
If you need to perform load test of login scenario with 100 unique users. Prepare the data in CSV
file with 100 user records with username and password, and you can use this file data in every
thread through variables in your requests/samplers by using this configuration element.

1. Add “CSV Data Set Config” Element where it will be used
2. You can give file path or filename of your text/CSV file. If file is stored in the same
location as your “Test Plan” is, then give only filename.
3. Give variable names for text/CSV file column values, use these variable as “$username”
/ “$password” in samplers
4. Select sharing mode
Following is the sample text file which contains user credentials for login scenario:
HTTP Request Defaults:
HTTP Request Defaults Configuration Element let us set default values to be used in HTTP
Request Samplers.
For Example: You need to send 100 HTTP Requests to the same server, then you can utilize
HTTP Request Default element with your “Server Name or IP”. Now, there is no need to give
“Server Name or IP” in all 100 HTTP Requests explicitly. The requests will get “Server Name or
IP” from the HTTP Request Default, just give the relative path of the web pages in
samplers/requests.
1. Give Server Name or IP without (http://) prefix.

User Defined Variables (UDV):
User Defined Variables Element let us use default variables and values in the test plan. If you
need to use UDV in only one Sampler, then define it under that Sampler. If you need to use UDV
in multiple parts, then define it at the start of Test Plan.
HTTP Cookie Manager
HTTP Cookie Manager is used to store cookies which targeted server sends in the response of
your Http request. The saved cookies can be used in other samplers/requests of the Test Plan.
1. You can also add User Defined Cookies; these cookies will be shared to all the Threads.
2. Cookies can be seen using the “View Results Tree” Listener.
3. Such Cookies usually have Expiration time far in the future.
HTTP Cookies Manager Panel looks like below figure:

Build JMeter Test Plan
A Test Plan can be considered as a root node that has potentially many levels of additional
elements / nodes that forms a hierarchy, which JMeter executes when we run test plan. A test
plan can consist of one or more elements like Thread Groups, Logic Controllers, Configuration
Elements, Timers, Listeners and Assertions. There should be at least one thread group in every
test plan. We can add or remove elements from test plan easily.
Let’s start building test plan by launching JMeter by following these two steps:
• Go to your JMeter bin folder e.g. E:apache-jmeter-3.0bin
• Double click ApacheJMeter.jar file.
Now, you can see the following JMeter GUI after a short break.
1. Rename your test plan
2. User Defined Variables provides flexibility when you have to repeat any value in several
parts of the test plan. You will be able to change the value from a single point, and it will
reflect everywhere.
3. Optional – or you can use according to your needs
4. WorkBench is used to store test elements temporary for copy/paste. It is also used for
Non-Test Elements like HTTP(S) Test Script Recorder, HTTP Mirror Server and

Property Display. If you need to save it along with the test plan, then you should select
the option “Save WorkBench” from WorkBench control panel.
After renaming test plan and defining variable, JMeter will look like as follows:
1. New test plan name will also reflect on left side
2. E.g. Variable name is set to “PATH”
3. E.g. Variable value is set to URL (without http://): “store.demoqa.com”
Now, this variable can be used in any part of the test plan elements like this ${PATH}
Look at the following example.
Add and Remove Test Plan Elements
Once the Test Plan for JMeter is created, the next thing we should be learning is to Add and
Remove Elements to JMeter Test Plan.
Steps to Add Elements to JMeter Test Plan
1. Select test plan node or any element
2. Right click the selected element
3. Mouse hover on “Add” option, then Elements list will be displayed
4. Mouse hover on desired list element, and select appropriate option by clicking it

In our tutorial, we are adding Thread Group element:
After adding Thread Group element, you can see the following screen:
Note : Elements can also be loaded from a file and added by selecting the “merge” or “open”
options.
Steps to Remove Elements from JMeter Test Plan
When you add number of Elements to Test Plan, you may like to remove one which is not
required any more. That can be done by following the below steps:

1. Select the desired element
2. Right click on the element
3. Choose the “Remove” option
Click “Yes” on the remove confirmation popup
Load and Save JMeter Test Plan Elements
Above we learned to add and remove elements. Now it is the time to Load and Save Elements to
JMeter Test Plan.

Steps to Load Elements to JMeter Test Plan Tree
1. Select and right click on any Tree Element, in which you want to add the loaded element
2. Select “Merge” option
3. Choose the .jmx file where you saved the elements
4. Elements will be Merged into the tree
5. Don’t forget to Save test plan / element
Steps to Load Elements to JMeter Test Plan Tree
1. Select and Right click on the element
2. Choose “Save Selection As” option
3. Save file on desired location

JMeter will save the element, and all the child elements beneath it.
Steps to Configure Tree Elements
Elements can be configured by using controls present on JMeter’s right hand side frame. The
controls allow us to configure behaviour of the selected element. The configuration varies from
element to element.
• E.g. Thread Group can be configured for Number of Threads, Ramp-Up Period, and
Scheduler etc., as shown below:

JMeter Actions on Test Plan
Till now we are done with Creating a Test Plan, Adding a Element and Configuring a Tree.
Let’s just move forward with different operations on Test Plan like Save, Run & Stop.
Steps to Save JMeter Test Plan
It’s always better to Save Test Plan before executing it. Test Plan can be saved by choosing
“Save” or “Save Test Plan As” from File menu.
Note: WorkBench will not be saved along with the Test Plan, you should select the option “Save
WorkBench” from WorkBench control panel otherwise your WorkBench data will be lost.

Steps to Run JMeter Test Plan
Test plan can be run from the “Run” menu item or by clicking Green Play button.
1. Green button shows that test plan is running.
2. Number of active threads / Total number of threads.
3. Stop button is enabled when test plan is running.
Steps to Stop to JMeter Test Plan
1. Stop (Control + ‘.’) It stops the threads immediately if possible. Many samplers are
interruptible so active samples can be terminated early.
2. Shutdown (Control + ‘,’) It requests the threads to stop at the end of any ongoing task. It
will not interrupt any active samples.
Steps to Check JMeter Test Plan Execution Logs
JMeter stores test run details, warnings and errors to the jmeter.log file by default, you can
access JMeter logs for debugging purpose.
1. It shows the total number of errors in log
2. Click yellow triangle button to view log panel
3. Logs are displaying in log panel

Now we learn Thread Group in JMeter Test Plan, we will be covering the following topics:
• What is Thread Group
• How to Create a Thread Group
• Component of Thread Group
To understand the JMeter Test Plan, please visit the previous tutorial (Building Test Plan in
JMeter) of this series.
What is Thread Group in JMeter?
A Thread Group is a set of threads executing the same scenario. Set the number of iterations in
the configuration. Thread behavior is defined according to ramp up and destroyed once the
number of iterations per thread has elapsed. This is how a Thread Group Element looks:

Thread Group elements are the initial steps of JMeter Test Plan. A number of threads (users)
can be defined in a Thread Group. Each thread simulates a real user requesting to the server
under a test.
If you set the number of threads as 20; JMeter will create and simulate 20 virtual users during the
load test. A diagram here can help us understand it better

How to Create a Thread Group Element in JMeter Test
Plan?
Previously we learnt that how to create a test plan. Thread Group is a element of test plan. To
create a Thread Group it is required to have the Test Plan created.
• Start JMeter
• Select Test Plan on the tree
• Add Thread Group
Open the thread group panel by Right Click on Test Plan and then going to Add >> Threads >>
Thread Group. As shown in the image below:
Components of Thread Group
The Thread Group Panel holds the following components −
1) Action to be taken after a Sampler Error
If JMeter catch any sampler error during test execution, you can tell it how to react in that
scenario from the following available options.
• Continue, to ignore error and move to the next element in the tree
• Start Next Thread Loop to stop current Thread and Start Next

• Stop Thread, to stop the current Thread execution.
• Stop Test, to stop entire test execution.
• Stop Test Now, the entire test will be stopped abruptly.
Default is Continue.
2) Thread Properties
• Number of Threads (users): Simulates the number of users or connections to your server
application.
• Ramp-Up Period (in seconds): Tells JMeter how long to take ramp-up to the full number
of threads chosen. For Example: If you set “Number of Threads” to “20”, and “Ramp-
Up Period to “40” seconds, then JMeter will wait till 40 seconds to make all threads up
and running. That means each thread will start 2 seconds late after the previous thread
was started.
o Formula: Ramp-Up Period / Number of Threads i.e. 40 / 20 = 2 (seconds)
• Loop Count: the number of times the test to be executed. If you need to run the test
forever, then select the “Forever” check box.
• Scheduler: To schedule test execution. Scheduler Configuration bottom panel will get
enabled when you select this checkbox. The schedule feature is also very helpful in
soak/endurance testing.
3) Scheduler Configuration
You can configure test start time, end time, duration and start up delay of your load test plan
using Scheduler Configuration section. To enable this area of configuration, Scheduler check box
must be selected from the above Section of Thread Properties.

Thread Group configuration panel is as follows:
• Start Time: This plans the test to start at scheduled time. Pre Condition is that the
JMeter should be running on given date and time in “Start Time” field.
• End Time: This command JMeter to end the test at the mentioned time. End time
override and stop execution in between. Means End Time is maximum allowed time to
finish execution of the test plan. JMeter ends the execution immediately as soon as End
Time is occur.
• Duration (seconds): This tell the JMeter to execute the test for the specific duration of
time. If the duration is set to 60 secs, JMeter will keep the execution on for 60 secs and
ends it once the time is elapsed. It also ignores or override the End Time and All threads
has completed its test or not.
• Startup delay (seconds): This tells JMeter to wait for specified time before starting the
test. If the StartUp time is set to 10 secs, JMeter will not start loading the Users till the
time 10 secs are over.
Building a Web Test Plan
In this section, you will learn how to create a basic Test Plan to test a Web site. You will create
five users that send requests to two pages on the JMeter Web site. Also, you will tell the users to
run their tests twice. So, the total number of requests is (5 users) x (2 requests) x (repeat 2 times)
= 20 HTTP requests. To construct the Test Plan, you will use the following elements: Thread
Group, HTTP Request, HTTP Request Defaults, and Graph Results.
For a more advanced Test Plan, see Building an Advanced Web Test Plan.
Adding Users
The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The
Thread Group tells JMeter the number of users you want to simulate, how often the users should
send requests, and how many requests they should send.
Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add → ThreadGroup.
You should now see the Thread Group element under Test Plan. If you do not see the element,
then "expand" the Test Plan tree by clicking on the Test Plan element.
Next, you need to modify the default properties. Select the Thread Group element in the tree, if
you have not already selected it. You should now see the Thread Group Control Panel in the
right section of the JMeter window (see Figure 4.1 below)

Figure 4.1. Thread Group with Default Values
Start by providing a more descriptive name for our Thread Group. In the name field, enter
JMeter Users.
Next, increase the number of users (called threads) to 5.
In the next field, the Ramp-Up Period, leave the default value of 1 seconds. This property tells
JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up
Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So,
if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would
be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will
immediately start all of your users.
Finally enter a value of 2 in the Loop Count field. This property tells JMeter how many times to
repeat your test. If you enter a loop count value of 1, then JMeter will run your test only once. To
have JMeter repeatedly run your Test Plan, select the Forever checkbox.
In most applications, you have to manually accept changes you make in a Control Panel.
However, in JMeter, the Control Panel automatically accepts your changes as you make them. If
you change the name of an element, the tree will be updated with the new text after you leave the
Control Panel (for example, when selecting another tree element).
See Figure 4.2 for the completed JMeter Users Thread Group.

Figure 4.2. JMeter Users Thread Group
Adding Default HTTP Request Properties
Now that we have defined our users, it is time to define the tasks that they will be performing. In
this section, you will specify the default settings for your HTTP requests. And then, in section
4.3, you will add HTTP Request elements which use some of the default settings you specified
here.
Begin by selecting the JMeter Users (Thread Group) element. Click your right mouse button to
get the Add menu, and then select Add → Config Element → HTTP Request Defaults. Then
select this new element to view its Control Panel (see Figure 4.3).
Figure 4.3. HTTP Request Defaults
Like most JMeter elements, the HTTP Request Defaults Control Panel has a name field that you
can modify. In this example, leave this field with the default value.
Skip to the next field, which is the Web Server's Server Name/IP. For the Test Plan that you are
building, all HTTP requests will be sent to the same Web server, jmeter.apache.org. Enter this

domain name into the field. This is the only field that we will specify a default, so leave the
remaining fields with their default values.
The HTTP Request Defaults element does not tell JMeter to send an HTTP request. It simply
defines the default values that the HTTP Request elements use.
See Figure 4.4 for the completed HTTP Request Defaults element
Figure 4.4. HTTP Defaults for our Test Plan
Adding Cookie Support
Nearly all web testing should use cookie support, unless your application specifically doesn't use
cookies. To add cookie support, simply add an HTTP Cookie Manager to each Thread Group in
your test plan. This will ensure that each thread gets its own cookies, but shared across all HTTP
Request objects.
To add the HTTP Cookie Manager, simply select the Thread Group, and choose Add → Config
Element → HTTP Cookie Manager, either from the Edit Menu, or from the right-click pop-up
menu.
Adding HTTP Requests
In our Test Plan, we need to make two HTTP requests. The first one is for the JMeter home page
(http://jmeter.apache.org/), and the second one is for the Changes page
(http://jmeter.apache.org/changes.html).

JMeter sends requests in the order that they appear in the tree.
Start by adding the first HTTP Request to the JMeter Users element (Add → Sampler → HTTP
Request). Then, select the HTTP Request element in the tree and edit the following properties
(see Figure 4.5):
1. Change the Name field to "Home Page".
2. Set the Path field to "/". Remember that you do not have to set the Server Name field
because you already specified this value in the HTTP Request Defaults element.
Figure 4.5. HTTP Request for JMeter Home Page
Next, add the second HTTP Request and edit the following properties (see Figure 4.6:
1. Change the Name field to "Changes".
2. Set the Path field to "/changes.html".

Figure 4.6. HTTP Request for JMeter Changes Page
Adding a Listener to View Store the Test Results
The final element you need to add to your Test Plan is a Listener. This element is responsible for
storing all of the results of your HTTP requests in a file and presenting a visual model of the
data.
Select the JMeter Users element and add a Graph Results listener (Add → Listener → Graph
Results). Next, you need to specify a directory and filename of the output file. You can either
type it into the filename field, or select the Browse button and browse to a directory and then
enter a filename.

Figure 4.7. Graph Results Listener
Logging in to a web-site
It's not the case here, but some web-sites require you to login before permitting you to perform
certain actions. In a web-browser, the login will be shown as a form for the user name and
password, and a button to submit the form. The button generates a POST request, passing the
values of the form items as parameters.
To do this in JMeter, add an HTTP Request, and set the method to POST. You'll need to know
the names of the fields used by the form, and the target page. These can be found out by
inspecting the code of the login page. [If this is difficult to do, you can use the JMeter Proxy
Recorder to record the login sequence.] Set the path to the target of the submit button. Click the
Add button twice and enter the username and password details. Sometimes the login form
contains additional hidden fields. These will need to be added as well.

Figure 4.8. Sample HTTP login request
Building an Advanced Web Test Plan
In this section, you will learn how to create advanced Test Plans to test a Web site.
For an example of a basic Test Plan, see Building a Web Test Plan.
Handling User Sessions with URL Rewriting
If your web application uses URL rewriting rather than cookies to save session information, then
you'll need to do a bit of extra work to test your site.
To respond correctly to URL rewriting, JMeter needs to parse the HTML received from the
server and retrieve the unique session ID. Use the appropriate HTTP URL Re-writing Modifier
to accomplish this. Simply enter the name of your session ID parameter into the modifier, and it
will find it and add it to each request. If the request already has a value, it will be replaced. If

"Cache Session Id?" is checked, then the last found session id will be saved, and will be used if
the previous HTTP sample does not contain a session id.
URL Rewriting Example
Download this example. In Figure 1 is shown a test plan using URL rewriting. Note that the
URL Re-writing modifier is added to the SimpleController, thus assuring that it will only affect
requests under that SimpleController.
Figure 1 - Test Tree
In Figure 2, we see the URL Re-writing modifier GUI, which just has a field for the user to
specify the name of the session ID parameter. There is also a checkbox for indicating that the
session ID should be part of the path (separated by a ";"), rather than a request parameter
Figure 2 - Request parameters
Using a Header Manager
The HTTP Header Manager lets you customize what information JMeter sends in the HTTP
request header. This header includes properties like "User-Agent", "Pragma", "Referrer", etc.

The HTTP Header Manager, like the HTTP Cookie Manager, should probably be added at the
Thread Group level, unless for some reason you wish to specify different headers for the
different HTTP Request objects in your test.
Building a Database Test Plan
In this section, you will learn how to create a basic Test Plan to test a database server. You will
create fifty users that send 2 SQL requests to the database server. Also, you will tell the users to
run their tests 100 times. So, the total number of requests is (50 users) x (2 requests) x (repeat
100 times) = 10'000 JDBC requests. To construct the Test Plan, you will use the following
elements: Thread Group, JDBC Request, Summary Report.
This example uses the MySQL database driver. To use this driver, its containing .jar file (ex.
mysql-connector-java-X.X.X-bin.jar) must be copied to the JMeter ./lib directory (see JMeter's
Classpath for more details).
Adding Users
send requests, and the how many requests they should send.
Start by providing a more descriptive name for our Thread Group. In the name field, enter JDBC
Users.

You will need a valid database, database table, and user-level access to that table. In the example
shown here, the database is 'cloud' and the table name is 'vm_instance'.
Next, increase the number of users to 50.
In the next field, the Ramp-Up Period, leave the value of 10 seconds. This property tells JMeter
how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 10
seconds, JMeter will finish starting all of your users by the end of the 10 seconds. So, if we have
50 users and a 10 second Ramp-Up Period, then the delay between starting users would be 200
milliseconds (10 seconds / 50 users = 0.2 user per second). If you set the value to 0, then JMeter
will immediately start all of your users.
Finally, enter a value of 100 in the Loop Count field. This property tells JMeter how many times
to repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox.
See Figure 6.2 for the completed JDBC Users Thread Group.
Figure 6.2. JDBC Users Thread Group
Adding JDBC Requests
Now that we have defined our users, it is time to define the tasks that they will be performing. In
this section, you will specify the JDBC requests to perform.
Begin by selecting the JDBC Users element. Click your right mouse button to get the Add menu,
and then select Add → Config Element → JDBC Connection Configuration. Then, select this
new element to view its Control Panel (see Figure 6.3).
Set up the following fields (these assume we will be using a MySQL database called 'cloud'):
• Variable name (here: myDatabase) bound to pool. This needs to uniquely identify the
configuration. It is used by the JDBC Sampler to identify the configuration to be used.

• Database URL: jdbc:mysql://ipOfTheServer:3306/cloud
• JDBC Driver class: com.mysql.jdbc.Driver
• Username: the username of database
• Password: password for the username
The other fields on the screen can be left as the defaults.
JMeter creates a database connection pool with the configuration settings as specified in the
Control Panel. The pool is referred to in JDBC Requests in the 'Variable Name' field. Several
different JDBC Configuration elements can be used, but they must have unique names. Every
JDBC Request must refer to a JDBC Configuration pool. More than one JDBC Request can refer
to the same pool.
Figure 6.3. JDBC Configuration
Selecting the JDBC Users element again. Click your right mouse button to get the Add menu,
and then select Add → Sampler → JDBC Request. Then, select this new element to view its
Control Panel (see Figure 6.4).

Figure 6.4. JDBC Request
In our Test Plan, we will make two JDBC requests. The first one is for select all 'Running' VM
instances, and the second is to select 'Expunging' VM instance (obviously, you should change
these to examples appropriate for your particular database). These are illustrated below.
JMeter sends requests in the order that you add them to the tree.
Start by editing the following properties (see Figure 6.5):
• Change the Name to 'VM Running'.
• Enter the Pool Name: 'myDatabase' (same as in the configuration element)
• Enter the SQL Query String field.
• Enter the Parameter values field with 'Running' value.
• Enter the Parameter types with 'VARCHAR'.

Figure 6.5. JDBC Request for the first SQL request
Next, add the second JDBC Request and edit the following properties (see Figure 6.6):
• Change the Name to 'VM Expunging'.
• Change the value of Parameter values to 'Expunging'.
Figure 6.6. JDBC Request for the second request

Adding a Listener to View/Store the Test Results
storing all the results of your JDBC requests in a file and presenting the results.
Select the JDBC Users element and add a Summary Report listener
(Add → Listener → Summary Report).
Save the test plan, and run the test with the menu Run → Start or Ctrl + R
The listener shows the results.
Figure 6.7. Graph results Listener
Building an FTP Test Plan
In this section, you will learn how to create a basic Test Plan to test an FTP site. You will create
four users that send requests for two files on a FTP site. Also, you will tell the users to run their
tests twice. So, the total number of requests is (4 users) x (2 requests) x (repeat 2 times) = 16
FTP requests.
To construct the Test Plan, you will use the following elements: Thread Group, FTP Request,
FTP Request Defaults, and View Results in Table.

Adding Users
Go ahead and add the Thread Group element by first selecting the Test Plan, clicking your right
Start by providing a more descriptive name for our Thread Group. In the name field, enter 'FTP
Users'.
Next, increase the number of users to 4.

Finally, enter a value of 2 in the Loop Count field. This property tells JMeter how many times to
repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox.
See Figure 7.2 for the completed FTP Users Thread Group.
Figure 7.2. FTP Users Thread Group
Adding Default FTP Request Properties
Now that we have defined our users, it is time define the tasks that they will be performing. In
this section, you will specify the default settings for your FTP requests. And then, in section 7.3,
you will add FTP Request elements which use some of the default settings you specified here.
Begin by selecting the FTP Users element. Click your right mouse button to get the Add menu,
and then select Add → Config Element → FTP Request Defaults. Then, select this new
element to view its Control Panel (see Figure 7.3).
Figure 7.3. FTP Request Defaults

Like most JMeter elements, the FTP Request Defaults Control Panel has a name field that you
Skip to the next field, which is the FTP Server's Server Name/IP. For the Test Plan that you are
building, all FTP requests will be sent to the same FTP server, ftp.domain.com in this case. Enter
this domain name into the field. This is the only field that we will specify a default, so leave the
remaining fields with their default values.
The FTP Request Defaults element does not tell JMeter to send an FTP request. It simply defines
the default values that the FTP Request elements use.
See Figure 7.4 for the completed FTP Request Defaults element
Figure 7.4. FTP Defaults for our Test Plan
Adding FTP Requests
In our Test Plan, we need to make two FTP requests.
Start by adding the first FTP Request to the FTP Users element (Add → Sampler → FTP
Request). Then, select the FTP Request element in the tree and edit the following properties
(see Figure 7.5):
1. Change the Name to "File1".
2. Change the Remote File field to "/directory/file1.txt".
3. Change the Username field to "anonymous".
4. Change the Password field to "anonymous@test.com".
You do not have to set the Server Name field because you already specified this value in the FTP
Request Defaults element.

Figure 7.5. FTP Request for file1
Next, add the second FTP Request and edit the following properties (see Figure 7.6:
1. Change the Name to "File2".
2. Change the Remote File field to "/directory/file2.txt".
3. Change the Username field to "anonymous".
4. Change the Password field to "anonymous@test.com".
Figure 7.6. FTP Request for file2
The final element you need to add to your Test Plan is a Listener. This element is responsible
for storing all of the results of your FTP requests in a file and presenting a visual model of the
data.
Select the FTP Users element and add a View Results in Table listener (Add → Listener →
View Results in Table).
Run your test and view the results.

Figure 7.7. View Results in Table Listener
Building an LDAP Test Plan
In this section, you will learn how to create a basic Test Plan to test an LDAP server. You will
create four users that send requests for four tests on the LDAP server. Also, you will tell the
users to run their tests 4 times. So, the total number of requests is (4 users) x (4 requests) x repeat
4 times) = 40 LDAP requests. To construct the Test Plan, you will use the following elements:
Thread Group, LDAP Request, LDAP Request Defaults, and View Results in Table .
This example assumes that the LDAP Server is available at ldap.test.com.
Adding Users
mouse button to get the Add menu, and then select Add → ThreadGroup. You should now see
the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test
Plan tree by clicking on the Test Plan element.

Figure 8a.1. Thread Group and final test tree
Adding Login Config Element
Begin by selecting the LDAP Users element. Click your right mouse button to get the Add menu,
and then select Add → Config Element → Login Config Element. Then, select this new element
to view its Control Panel.
Like most JMeter elements, the Login Config Element's Control Panel has a name field that you
Figure 8a.2 Login Config Element for our Test Plan
Enter Username field to "your LDAP Username",
The password field to "your LDAP Password"
These values will be used by the LDAP Requests.
Adding LDAP Request Defaults
Begin by selecting the LDAP Users element. Click your right mouse button to get the Add menu,
and then select Add → Config Element → LDAP Request Defaults. Then, select this new
element to view its Control Panel.
Like most JMeter elements, the LDAP Request Defaults Control Panel has a name field that you

Figure 8a.3 LDAP Defaults for our Test Plan
Enter DN field to "your LDAP Root Distinguished Name".
Enter LDAP Server's Server name field to "ldap.test.com".
The port to 389.
These values are default for the LDAP Requests.
Adding LDAP Requests
In our Test Plan, we need to make four LDAP requests.
1. Inbuilt Add Test
2. Inbuilt Search Test
3. Inbuilt Modify Test
4. Inbuilt Delete Test
JMeter sends requests in the order that you add them to the tree. Start by adding the first LDAP
Request to the LDAP Users element (Add → Sampler → LDAP Request). Then, select the
LDAP Request element in the tree and edit the following properties
1. Rename to "Add" this element
2. Select the Add Test radio button in Test Configuration group
Figure 8a.4.1 LDAP Request for Inbuilt Add test

You do not have to set the Servername field, port field, Username, Password and DN because
you already specified this value in the Login Config Element and LDAP Request Defaults.
Next, add the second LDAP Request and edit the following properties
1. Rename to "Search" this element
2. Select the Search Test radio button in Test Configuration group
Next, add the Third LDAP Request and edit the following properties
Figure 8a.4.2 LDAP Request for Inbuilt Search test
1. Rename to "Modify" this element
2. Select the Modify Test radio button in Test Configuration group
Next, add the fourth LDAP Request and edit the following properties
Figure 8a.4.3 LDAP Request for Inbuilt Modify test
1. Rename to "Delete" this element
2. Select the Delete Test radio button in Test Configuration group

Figure 8a.4.4 LDAP Request for Inbuilt Delete test
Adding a Response Assertion
You can add a Response Assertion element. This element will check the received response data
by verifying if the response text is "successful". (Add → Assertion → Response Assertion).
Note: A this position in the tree, the Response Assertion will be executed for each LDAP
Request.
1. Select Text Response Radio button in Response Field to Test group
2. Select Substring Radio button in Pattern Matching Rules group
3. Click on Add button and add the string "successful" in Pattern to Test field
Figure 8a.5 LDAP Response Assertion

storing all of the results of your LDAP requests in a file and presenting a visual model of the
data. Select the LDAP Users element and add a View Results in Table (Add → Listener → View
Results in Table)
Figure 8a.6 View Results in Table Listener
Building an Extended LDAP Test Plan
In this section, you will learn how to create a basic Test Plan to test an LDAP server.
As the Extended LDAP Sampler is highly configurable, this also means that it takes some time to
build a correct Testplan. You can however tune it exactly up to your needs.
You will create four users that send requests for four tests on the LDAP server. Also, you will
tell the users to run their tests one time. So, the total number of requests is (1 users) x (9
requests) x repeat 1 time) = 9 LDAP requests. To construct the Test Plan, you will use the
following elements:
Thread Group, Adding LDAP Extended Request Defaults, Adding LDAP Requests, and Adding
a Listener to View/Store the Test Results
This example assumes that the LDAP Server is available at ldap.test.com.
For the less experienced LDAP users, I build a small LDAP tutorial which shortly explains the
several LDAP operations that can be used in building a complex Testplan.
Take care when using LDAP special characters in the distinguished name, in that case (e.g. you
want to use a + sign in a distinguished name) you need to escape the character by adding an ""

sign before that character. Extra exception: if you want to add a character in a distinguished
name (in an add or rename operation), you need to use 4 backslashes.
Examples:
cn=dolf+smits
to add/search an entry with the name like cn=dolf+smits
cn=dolf smits
to search an entry with the name cn=dolf smits
cn=c:log.txt
to add an entry with a name like cn=c:log.txt
Adding Users
Go ahead and add the Thread Group element by first selecting the Test Plan, clicking your right
mouse button to get the Add menu, and then select Add→Threads (Users)→Thread Group. You
should now see the Thread Group element under Test Plan. If you do not see the element, then
"expand" the Test Plan tree by clicking on the Test Plan element.
Figure 8b.1. Thread Group with Default Values
Adding LDAP Extended Request Defaults
Begin by selecting the LDAP Ext Users element. Click your right mouse button to get the Add
menu, and then select Add→Config Element→LDAP Extended Request Defaults. Then, select
this new element to view its Control Panel.
Like most JMeter elements, the LDAP Extended Request Defaults Control Panel has a name
field that you can modify. In this example, leave this field with the default value.

Figure 8b.2 LDAP Defaults for our Test Plan
For each of the different operations, some default values can be filled in. In All cases, when a
default is filled in, this is used for the LDAP extended requests. For each request, you can
override the defaults by filling in the values in the LDAP extended request sampler. When no
value is entered, which is necessary for a test, the test will fail in an unpredictable way!
We will not enter any default values here, as we will build a very small testplan, so we will
explain all the different fields when we add the LDAP Extended samplers.
Adding LDAP Requests
In our Test Plan, we want to use all 9 LDAP requests.
1. Thread bind
2. Search Test
3. Compare Test
4. Single bind/unbind Test
5. Add Test
6. Modify Test
7. Rename entry (moddn)
8. Delete Test
9. Thread unbind
JMeter sends requests in the order that you add them to the tree.
Adding a request always start by:
Adding the LDAP Extended Request to the LDAP Ext Users element (Add→ Sampler→LDAP
Ext Request). Then, select the LDAP Ext Request element in the tree and edit the following
properties.
Adding a Thread bind Request
1. Rename the element: "1. Thread bind"
2. Select the "Thread bind" button.

3. Enter the hostname value from the LDAP server in the Servername field
4. Enter the portnumber from the LDAP server (636 : ldap over SSL) in the port field
5. (Optional) Enter the baseDN in the DN field, this baseDN will be used as the starting
point for searches, add, deletes, etc.
take care that this must be the uppermost shared level for all your request, e.g. when all
information is stored under ou=Users, dc=test, dc=com, you can use this value in the
basedn.
6. (Optional) Enter the distinguished name from the user you want to use for authentication.
When this field is kept empty, an anonymous bind will be established.
7. (Optional) Enter the password for the user you want to authenticate with, an empty
password will also lead to an anonymous bind.
8. (Optional) Enter a value for the connection timeout with LDAP
9. (Optional) Check the box Use Secure LDAP Protocol if you access with LDAP over SSL
(ldaps)
Figure 8b.3.1. Thread Bind example
Adding a search Request
1. Rename the element: "2. Search Test"
2. Select the "Search Test" button.
3. (Optional) enter the searchbase under which you want to perform the search, relative to
the basedn, used in the thread bind request.
When left empty, the basedn is used as a search base, this files is important if you want to
use a "base-entry" or "one-level" search (see below)
4. Enter the searchfilter, any decent LDAP search filter will do, but for now, use something
simple, like (sn=Doe) or (cn=*)
5. (Optional) Enter the scope in the scope field, it has three options:
1. baseobject search
only the given searchbase is used, only for checking attributes or existence.
2. onelevel search
Only search in one level below given searchbase is used

3. subtree search
Searches for object at any point below the given basedn
6. (Optional) Size limit, specifies the maximum number of returned entries,
7. (Optional) Time limit, specifies the maximum number of milliseconds, the SERVER can
use for performing the search. It is NOT the maximum time the application will wait.
When a very large returnset is returned, from a very fast server, over a very slow line,
you may have to wait for ages for the completion of the search request, but this parameter
will not influence this.
8. (Optional) Attributes you want in the search answer. This can be used to limit the size of
the answer, especially when an object has very large attributes (like jpegPhoto). There are
three possibilities:
1. Leave empty (the default setting must also be empty) This will return all
attributes.
2. Put in one empty value (""), it will request a non-existent attributes, so in reality it
returns no attributes
3. Put in the attributes, separated by a semi-colon. It will return only the requested
attributes
9. (Optional) Return object. Checked will return all java-object attributes, it will add these
to the requested attributes, as specified above.
Unchecked will mean no java-object attributes will be returned.
10. (Optional) Dereference aliases. Checked will mean it will follow references, Unchecked
says it will not.
11. (Optional) Parse the search results?. Checked will mean it gets all results in response
data, Unchecked says it will not.
Figure 8b.3.2. search request example

Adding a Compare Request
1. Rename the element: "3. Compare Test"
2. Select the "Compare" button.
3. enter the entryname form the object on which you want the compare operation to work,
relative to the basedn, e.g. "cn=jdoe,ou=Users"
4. Enter the compare filter, this must be in the form "attribute=value", e.g.
"mail=jdoe@test.com"
Figure 8b.3.3. Compare example
Adding a Single bind/unbind
1. Rename the element: "4. Single bind/unbind Test"
2. Select the "Single bind/unbind" button.
3. Enter the FULL distinguished name from the user you want to use for authentication.
E.g. cn=jdoe,ou=Users,dc=test,dc=com When this field is kept empty, an anonymous
bind will be established.
4. Enter the password for the user you want to authenticate with, an empty password will
also lead to an anonymous bind.
Take care: This single bind/unbind is in reality two separate operations but cannot easily be
split!
Figure 8b.3.4. Single bind/unbind example

Adding an Add Request
1. Rename the element: "5. Add Test"
2. Select the "Add" button.
3. Enter the distinguished name for the object to add, relative to the basedn.
4. Add a line in the "add test" table, fill in the attribute and value.
When you need the same attribute more than once, just add a new line, add the attribute
again, and a different value.
All necessary attributes and values must be specified to pass the test, see picture!
(sometimes the server adds the attribute "objectClass=top", this might give a problem.
Figure 8b.3.5. Add request example
Adding a Modify Request
1. Rename the element: "6. Modify Test"
2. Select the "Modify test" button.
3. Enter the distinguished name for the object to modify, relative to the basedn.
4. Add a line in the "modify test" table, with the "add" button.
5. You need to enter the attribute you want to modify, (optional) a value, and the opcode.
The meaning of this opcode:
add
this will mean that the attribute value (not optional in this case) will be added to the
attribute.
When the attribute is not existing, it will be created and the value added
When it is existing, and defined multi-valued, the new value is added.
when it is existing, but single valued, it will fail.
replace

This will overwrite the attribute with the given new value (not optional here)
When the attribute is not existing, it will be created and the value added
When it is existing, old values are removed, the new value is added.
delete
When no value is given, all values will be removed
When a value is given, only that value will be removed
when the given value is not existing, the test will fail
6. (Optional) Add more modifications in the "modify test" table.
All modifications which are specified must succeed, to let the modification test pass.
When one modification fails, NO modifications at all will be made and the entry will
remain unchanged.
Figure 8b.3.6. Modify example
Adding a Rename Request (moddn)
1. Rename the element: "7. Rename entry (moddn)"
2. Select the "Rename Entry" button.
3. Enter the name of the entry, relative to the baseDN, in the "old entry name"-Field.
that is, if you want to rename "cn=Little John Doe,ou=Users", and you set the baseDN to
"dc=test,dc=com", you need to enter "cn=John Junior Doe,ou=Users" in the old entry
name-Field.
4. Enter the new name of the entry, relative to the baseDN, in the "new distinguished
name"-Field.
when you only change the RDN, it will simply rename the entry
when you also add a different subtree, e.g. you change from cn=john doe,ou=Users to
cn=john doe,ou=oldusers, it will move the entry. You can also move a complete subtree
(If your LDAP server supports this!), e.g. ou=Users,ou=retired, to ou=oldusers,ou=users,

this will move the complete subtree, plus all retired people in the subtree to the new place
in the tree.
Figure 8b.3.8. Rename example
Adding a Delete Request
1. Rename the element: "8. Delete Test"
2. Select the "Delete" button.
3. Enter the name of the entry, relative to the baseDN, in the Delete-Field.
that is, if you want to remove "cn=John Junior Doe,ou=Users,dc=test,dc=com", and you
set the baseDN to "dc=test,dc=com", you need to enter "cn=John Junior Doe,ou=Users"
in the Delete-field.
Figure 8b.3.7. Delete example
Adding an unbind Request
1. Rename the element: "9. Thread unbind"
2. Select the "Thread unbind" button. This will be enough as it just closes the current
connection. The information which is needed is already known by the system

Figure 8b.3.9. Unbind example
storing all of the results of your LDAP requests in a file and presenting a visual model of the
data. Select the Thread group element and add a View Results Tree (Add→Listener→View
Results Tree)
Figure 8b.4. View Result Tree Listener
In this listener, you have three tabs to view, the sampler result, the request and the response data.

1. The sampler result just contains the response time, the return code and return message
2. The request gives a short description of the request that was made, in practice no relevant
information is contained here.
3. The response data contains the full details of the sent request, as well the full details of
the received answer, this is given in a (self defined) xml-style. The full description can be
found here.
Building a WebService Test Plan
In this section, you will learn how to create a Test Plan to test a WebService. You will create five
users that send requests to One page. Also, you will tell the users to run their tests twice. So, the
total number of requests is (5 users) x (1 requests) x (repeat 2 times) = 10 HTTP requests. To
construct the Test Plan, you will use the following elements: Thread Group, HTTP Request, and
Aggregate Graph.
If the sampler appears to be getting an error from the webservice, double check the SOAP
message and make sure the format is correct. In particular, make sure the xmlns attributes are
exactly the same as the WSDL. If the xml namespace is different, the webservice will likely
return an error.
Creating WebService Test Plan
In our Test Plan, we will use a .NET webservice. We won't go into the details of writing a
webservice. If you don't know how to write a webservice, google for webservice and familiarize
yourself with writing webservices for Java and .NET. It should be noted there is a significant
difference between how .NET and Java implement webservices. The topic is too broad to cover
in the user manual. Please refer to other sources to get a better idea of the differences.
Start by using menu File → Templates… and select template "Building a SOAP Webservice
Test Plan". Then, click "Create" button.

Figure 9.1.0. Webservice Template Change the following:
1. In "HTTP Request Defaults" change "Server Name of IP"
2. In "Soap Request", change "Path:"
Figure 9.1.1 Webservice Path

Next, select "HTTP Header Manager" and update "SOAPAction" header to match your
webservice. Some webservices may not use SOAPAction in this case remove it.
Currently, only .NET uses SOAPAction, so it is normal to have a blank SOAPAction for all
other webservices. The list includes JWSDP, Weblogic, Axis, The Mind Electric Glue, and
gSoap.
Figure 9.1.2 Webservice Headers
The last step is to paste the SOAP message in the "Body Data" text area.
Figure 9.1.3 Webservice Body
Adding Users
The Thread Group tells JMeter the number of users you want to simulate, how often the users
should send requests, and the how many requests they should send.

Select the Thread Group element in the tree, if you have not already selected it. You should now
see the Thread Group Control Panel in the right section of the JMeter window (see Figure 9.2
below)
Start by providing a more descriptive name for our Thread Group. In the name field, enter
JMeter Users.
Finally, clear the checkbox labeled "Forever", and enter a value of 2 in the Loop Count field.
This property tells JMeter how many times to repeat your test. If you enter a loop count value of
0, then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select
the Forever checkbox.
See Figure 9.2 for the completed JMeter Users Thread Group.

Figure 9.3. JMeter Users Thread Group
storing all of the results of your HTTP requests in a file and presenting a visual model of the
data.
Select the JMeter Users element and add a Aggregate Graph listener
(Add → Listener → Aggregate Graph). Next, you need to specify a directory and filename of the
output file. You can either type it into the filename field, or select the Browse button and browse
to a directory and then enter a filename.

Rest WebService
Testing a REST WebService is very similar as you only need to modify in HTTP Request
• Method: to select the one you want to test
• Body Data: which can be JSON, XML or any custom text
You may also need to modify "HTTP Header Manager" to select the correct "Content-Type"
Building a JMS Point-to-Point Test Plan
Make sure the required jar files are in JMeter's lib directory. If they are not, shutdown JMeter,
copy the jar files over and restart JMeter. See Getting Started for details.
In this section, you will learn how to create a Test Plan to test a JMS Point-to-Point messaging
solution. The setup of the test is 1 threadgroup with 5 threads sending 4 messages each through a
request queue. A fixed reply queue will be used for monitoring the reply messages. To construct
the Test Plan, you will use the following elements: Thread Group, JMS Point-to-Point, and
Graph Results.
General notes on JMS: There are currently two JMS samplers. One uses JMS topics and the
other uses queues. Topic messages are commonly known as pub/sub messaging. Topic
messaging is generally used in cases where a message is published by a producer and consumed
by multiple subscribers. A JMS sampler needs the JMS implementation jar files; for example,
from Apache ActiveMQ. See here for the list of jars provided by ActiveMQ.
Adding a Thread Group

Start by providing a more descriptive name for our Thread Group. In the name field, enter Point-
to-Point.
In the next field, the Ramp-Up Period, leave set the value to 0 seconds. This property tells
Clear the checkbox labeled "Forever", and enter a value of 4 in the Loop Count field. This
property tells JMeter how many times to repeat your test. If you enter a loop count value of 0,
then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select
the Forever checkbox.

Adding JMS Point-to-Point Sampler
Start by adding the sampler JMS Point-to-Point to the Point-to-Point element
(Add → Sampler → JMS Point-to-Point). Then, select the JMS Point-to-Point sampler element
in the tree. In building the example a configuration will be provided that works with ActiveMQ
3.0.
Name Value Description
JMS Resources
QueueConnectionFact
ory
ConnectionFactory This is the default JNDI
entry for the connection
factory within
ActiveMQ.
JNDI Name Request
Queue
Q.REQ This is equal to the
JNDI name defined in
the JNDI properties.
JNDI Name Reply
Queue
Q.RPL This is equal to the
JNDI name defined in
the JNDI properties.
Message Properties
Communication Style Request Response This means that you
need at least a service
running outside of
JMeter and that will
respond to the requests.
This service must listen
to the Request Queue
and send messages to
the queue referenced by
the
message.getJMSReply
To()
Content test This is just the content
of the message.
JMS Properties Nothing needed for
ActiveMQ.
JNDI Properties
InitialContextFactory org.apache.activemq.jndi.ActiveMQInitialContext
Factory
The standard
InitialContextFactory
for ActiveMQ
Properties
queue.Q.REQ example.A This defines a JNDI
name Q.REQ for the
request queue that
points to the queue
example.A
queue.Q.RPL example.B This defines a JNDI
name Q.RPL for the

reply queue that points
to the queue example.B
Provider URL
Provider URL tcp://localhost:61616 This defines the URL
of the ActiveMQ
messaging system.
storing all of the results of your JMS requests in a file and presenting a visual model of the data.
Select the Thread Group element and add a Graph Results listener (Add → Listener → Graph
Results). Next, you need to specify a directory and filename of the output file. You can either
type it into the filename field, or select the Browse button and browse to a directory and then
enter a filename.

References:
All the articles mentioned in the book are described by Author itself. Some images are taken
from http://jmeter.apache.org/ for reference.
Author wants to thank for all the support provided by Apache JMeter Organization, without there
guideline this book can’t be completed.
Best regards,
Prince K. Raman Kinth
COO, Testing Manager
Noida, India

Automation testing with J-Meter

More Related Content

Similar to Automation testing with J-Meter (20)

Recently uploaded (20)

Automation testing with J-Meter