J Meter Introduction

J Meter is a Java based automation framework which is used for the load test functional
behavior and measure the performance of the application. It is based on open-source
technology. J Meter can be used for the performance testing of web-based applications as
well as a variety of other services. It was developed by Stefano Mazzocchi. When J Meter
was first developed, it was used only for the testing of Web applications. However, now it
is used for testing almost any kind of system and can also be used for the functional
testing of applications. J Meter offers multiple parameters to mimic the actual system,
configure different loads and perform the performance as well as stress testing of the
underlying systems and protocols.

J Meter is a Java based desktop application and as such It supports multiple platforms and
can run on any kind of machine which has Java virtual machine installed, e.g., Windows,
Linux, Mac. J

Meter framework allows concurrent execution and hence the execution of several
Threads and Threads Groups are possible by design. Being open-source technology, J
Meter is extensible, and also it supports a very large list of plugins available. J Meter is
part of the Apache software foundation and is completely free and open source. Its UI is
implemented using the Swing Java API.

Types of performance test:

● Performance tests: These tests are used to check how the system website server,
database or the network behaves in terms of performance, that is, how the system
responds and how is its stability for a specific workload. Performance testing
checks for the responsiveness, stability, scalability, reliability, speed and resource
usage of the software.
● Load testing: Load test is a type of performance testing. It is usually conducted to
understand the behavior of the system under a specific load. Load testing helps us
identify the number of users which can be handled by the system.
● Stress tests: Stress tests are another form of performance testing and are used to
determine the breakpoint or the maximum limit of the system. This is done by
increasing the load till a point is reached when the system reaches its maximum
threshold and then breaks.
● Spike Test -When a stress test involves a sudden high ramp up in the number of
users it is referred to as Spike test which is another form of performance testing.
Features of J Meter
Listed below are the features of J Meter:

● J Meter is a free tool and does not involve any license cost
● Supports multiple platforms – It is platform-independent tool. On Linux/Unix, J
Meter can be invoked by clicking on the J Meter shell script. On Windows the J
Meter.bat file will start J Meter.
● J Meter is an open-source tool.
● J Meter provides record and playback features.
● Easily available resources
● Supports an array of testing like FTP performance, database performance apart
from load testing.
● Extensive reporting is available
● Non-GUI mode is available when we need to test high level load on servers to test
performance.
● Can do performance test on multiple server type like Web - HTTP, HTTPS
○ SOAP
○ Database via JDBC
○ LDAP
○ JMS
○ Mail - POP3(S) and IMAP(S)

● J Meter uses XML format to save test cases. This implies that one can generate a
test plan using a text editor.

How J meter Works

J Meter mimics user actions on the application by sending requests to the server,
Database or to the network. As soon as the user request is sent by J Meter, J Meter starts
capturing the response sent. J Meter saves all the response received from the target
server, analyzes the response and shares the report. This report tells us about the
performance behavior of the application under test.

Limitations of J Meter

● Scripting in J Meter requires some level of expertise and understanding of

different components of J Meter like test plan elements, regular expressions,
session handling, etc.
 ● J Meter does not support the network visualization feature which is provided by
LoadRunner.
● To carry out large tests with a huge number of users a single normal configuration
machine is insufficient. To test such cases, a very high configuration cloud
machine is required or distributed testing is performed.
● J Meter has not support for ajax or JavaScript
● It provides very limited real-time test monitoring capability as compared to other
tools.

Advantage of J Meter over Load Runner

LoadRunner is another popular tool used for Performance testing and is a completion of J
Meter. There are few abilities of J Meter which make it more powerful than LoadRunner.

● Load runner is a licensed tool and is expensive.

● LoadRunner provides limited capacity to generate load as opposed to J Meter
which provides unlimited load generating capacity.
● The record and play feature of J Meter allows anyone without J Meter scripting
knowledge to use the tool as well. This feature is not available in Load runner.

Installation/Environment:

J Meter is a Java based framework. JDK 1.6 or higher versions should be installed on your
machine.

Windows:

● Install the java package suitable to your system from here.

● Set the JAVA_HOME environment variable to point to the base directory
location, where Java is installed: JAVA_HOME=C:\\Program
Files\\Java\\jdk1.8.0_20 Use applicable java version
● Append Java compiler location to System Path. C:\\Program
Files\\Java\\jdk1.7.0_25\\bin to the end of the system variable Path
● Check that Java is installed in your machine by going to the command line and
typing java -version
● Below message should be displayed:
● java version "1.8.0_20" Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
● Download the latest version of J Meter from here
○ Extract it to the folder C:>J Meter for example
○ The structure of this folder should be something like below: (where a.b
is the version number)

apache-J Meter-a.b

apache-J Meter-a.b\\bin

apache-J Meter-a.b\\docs

apache-J Meter-a.b\\extras

apache-J Meter-a.b\\lib

apache-J Meter-a.b\\lib\\ext

apache-J Meter-a.b\\lib\\junit

apache-J Meter-a.b\\printable_docs

● Launch J Meter by starting the J Meter.bat programme

● J Meter GUI should launch as shown in figure 1 below.The GUI mode should only
be used for creating the test script.CLI should be used for load testing
● J Meter.bat -To run J Meter in GUI mode. This is default J Meter mode.
● J Meterw.cmd – To run J Meter without the windows shell console (in GUI mode
by default)
● J Meter-n.cmd – Used to drop a JMX file on this to run a CLI mode test
● J Meter-n-r.cmd – Used to drop a JMX file on this to run a CLI mode test remotely
● J Meter-t.cmd – Used to drop a JMX file on this to load it in GUI mode
● J Meter-server.bat – Used to start J Meter in server mode
● mirror-server.cmd – Used to run the J Meter Mirror Server in CLI mode
● shutdown.cmd – Used to Run the Shutdown client to stop a CLI mode instance
gracefully
● stoptest.cmd – Used to Run the Shutdown client to stop a CLI mode instance
abruptly
TEST PLAN
Test plan is a test case in J Meter. It is a sequence of steps which J Meter will execute upon
running. Each test plan is made up of several test elements along with the desired
configuration as needed for the performance test. Each element in a test plan is used for a
specific operation. J Meter GUI is used to add, remove and configure test plan elements.
The left pane of J Meter is used to add a test plan while the right side is used to configure
it. A complete test plan consists of one or more components like Thread Groups, logic
controllers, sample generating controllers, listeners, timers, assertions, and configuration
elements. A minimum of one thread group should be present in every test plan.

Building a Test Plan

● Add an Element: Right click test plan →Add →select element to add ( for eg thread
group)
● Add test element from a file /Load elements - An element can also be added by
loading it from a file and choosing the merge or open option .The loaded element
will not be saved by default by J Meter.One has to explicitly save the loaded
element by choosing the option “Save selection as”.
● Remove an element: To remove an element, select the element, right click on it and
select remove.
● Configure Test Elements: Test elements can be configured after adding them using
controls which are present in the right-side panel. Figure – Configure a thread
group using 10 users with ramp up time 100 sec, loop count 1 and to continue
execution upon error.
● Save test plan: Test plan can be saved as below: File → Save or File →Save test plan
as. Run the test plan: (Control+R)

We can run a test plan by choosing any of the two options from below.

● Click on the play button from the top menu. We can also choose to start a test and
ignore pauses by selecting the “play no pauses” button.

● Click Start from the Run menu item. Figure – Start a test from the Run menu.

When a test starts to run it shows a green button at the right end. The numbers to the left
of the green button indicate active threads and total threads respectively when run
locally. This does not display threads which have been started on a remote machine using
client server mode.
 ● Stop a test plan: Test can be stopped by below ways:
● a) Stop – (Control +.) will stop the thread immediately.
● b) Shutdown- (Control+,) will stop at the end of the current work. This does
not interrupt active samples.
● Disable a test plan – it is possible to disable the test plan from execution.
● Right click on test plan name →Click disable

Test Plan Elements

Each J Meter test plan consists of test elements. Test plan must have a minimum of one
thread group. Within a thread group we can have a combination of one or more elements.
Listed below are popular test plan elements.

● Thread Group
● Controllers
● Listeners
● Timers
● Configuration Elements
● Pre-Processor elements
● Post processor elements

Thread Groups

Thread group is a group of threads J Meter will use during the test. Thread group element
is the starting point of a J Meter test. Thread Groups are used to simulate user action in a
performance test. We can have multiple thread groups simulating different types of
operations performed by users on an application. Thread group panel is used to configure
a thread group.

Name – it is the name of the thread group which suggests the action performed by the
users.

Comments – it is an optional text box to add any notes or comments specific to the thread
group.

● Number of threads: this is used to simulate the number of users or connections

to be made to the server
● Ramp-up period (In seconds): Time that J Meter will need to start all the threads.
● Loop count: Number of iterations, that is, the number of times a test is going to be
executed.
 ● Error behavior: What to do in case of an error: Stop current thread, stop the
whole test, or continue.
● Scheduler checkbox − Once selected, the Scheduler Configuration section
appears at the bottom of the control panel where we can configure the start and
end time of the test
● Scheduler Configuration – it is used to configure the start and end time of
running the test.
● Thread Group also allows us to specify the lifetime of the thread. Duration
(seconds) and Startup Delay (seconds) to manage the duration of each thread
group and after how many seconds it starts can also be configured. When the test
is started, J Meter will wait till the time as defined in Startup Delay (seconds)
before starting the Threads of the Thread Group and run for the configured
Duration (seconds) time.
Once the thread group is configured, other test plan elements can be added to
the created Thread group like samplers, listeners and timers.

● Figure -Thread group screen in J Meter

● Create a thread group in J Meter:Right click Test plan → Add →Threads (Users)
→thread Group
● Name a thread group: Create a thread group as above and add names in the right
panel.

Controllers

J Meter supports 2 types of controllers, which are samplers and Logic Controllers.

Samplers

Samplers are used to send requests to a server and wait for a response. Samplers allow J
Meter to send specific types of requests to a server. Samplers execute requests based
upon the configuration provided. Samplers are executed in the order in which they are
defined in the tree. Controllers can be used to define the number of times a sampler
request should be repeated. A sampler has different properties which can be set up.
Samplers can be modified further by adding configuration elements to the test plan. If we
want to send the same request to the same server multiple times for testing, then it is
recommended to use the default configuration element in such scenarios. We can also add
assertion to the sampler if we wish to perform basic validations on the response. These
requests then produce responses, which are analyzed later. Commonly used samplers are
as below:
HTTP Request: HTTPS request is the most popular sampler used for web-based
applications. We use this sampler to send HTTP/HTTPS requests to the server.

JDBC Request: This sampler is used to send SQL queries to a database server.

SOAP/XML-RPC Request: This sampler is used to send SOAP requests to a SOAP web
service.

Test Action :This is a special type of Sampler, which is used to introduce pauses in a test .

This sampler does not send a request to the server

FTP Request :This sampler is used to send file put and get requests to an FTP server.

Below is a list of other samplers provided by J Meter apart from the ones listed above.

● AJP/1.3 Sampler
● Access Log Sampler
● BSF Sampler
● Bean Shell Sampler
● Debug Sampler
● JMS Point-to-Point
● JMS Publisher
● JMS Subscriber
● JSR223 Sampler
● JUnit Request
● Java Request
● LDAP Extended Request
● LDAP Request
● Mail Reader Sampler
● OS Process Sampler
● SMTP Sampler
● TCP Sampler
● Test Sampler
● Web Service (SOAP) Request

Configuration of each sampler depends upon the request that it executes. Samplers are
added to thread group as below:

Add sampler to a thread group: Right click Thread Group →Add →Sampler →(as
necessary)
Example of the Sampler - an HTTP Request sampler can be added whenever we need to
make a POST, GET, or DELETE on an HTTP service.

Logic Controllers

Logical controllers help to control the processing order of samplers in a thread group.
They help customize the logic that J Meter uses to determine when to send requests to
the server. The order of the incoming request can be changed by the Logic Controllers
from their child elements. Different logical controller provided by J Meter are:

Critical Section Controller – It ensures that the child elements are accessed by only one
thread at a time.

For Each Controller - This controller is used to perform the requests in a loop.

Include Controller - Include controller is used to add an external test to the existing test
case. This is done by loading the jmx file in the Include Controller’s control panel.

Interleave Controller - This Controller is used to select and execute a single child element
among multiple children in each iteration of the loop. For example- if there are 3 samplers
added as child to an Interleave Controller then in the first iteration it will pick the first
sampler request, in the next iteration it will pick the subsequent one and so on. Once the
child elements are over, it again starts iteration from the first element.

Loop Controller -This is used to execute the operations specified in a loop. We define the
iteration value as specified in its control panel.

Module Controller -This is used to reuse a test fragment (e.g., a sampler) into our script
again. This is done by selecting the module from the Module Controller’s control panel.

Once Only Controller-The once only controller is used in cases where we wish to perform
an operation only once, even if the operation is part of a loop.

Random Controller - it is similar to a random controller and picks a single child element in
each iteration but unlike the Interleave controller it picks the child element randomly.

Random Order Controller - Random Order controller is used to execute each child
element at least once in a random order.

Recording Controller -Recording controller is used as a placeholder where the scripts

recorded using HTTP Proxy Server are saved by default
Runtime Controller -Runtime controller is used to limit the execution time of its child
elements.

Simple Controller-This controller is used for grouping and ordering the different
elements in a test plan.

While Controller-The While controller runs the child elements inside it until the condition
specified turns false.

Add a Logical controller: Right click Thread Group →Add →Logic Controller → (as
necessary)

Logical controller example: Logic Controller is a Loop controller which makes a request
multiple times to the server.

Listeners

Listeners are test plan elements which are used to view and analyze the result of a
performance test. Listeners results can be viewed in the form of tables, trees, graphs or
log files. Listeners can be added anywhere in a test plan. They only parse and collect result
data from the samplers at their level or in levels below them. Listeners are processed in
the end. Listener results are default stored in XML files and saved with a. jlt format.

Different Listeners provided by J Meter:

Aggregate Graph-The Aggregate Graph listener displays test results in tabular

form(reports) as well as bar graphs, and permits to save the results in the form of a png
file.

Aggregate Report -The Aggregate Report listener displays and stores test results in the
form of reports.

Assertion Results-The assertion results listener displays the assertion result when the
sampler response has an error. This listener is resource intensive and must be avoided
during performance testing. It is useful for debugging and for functional testing purposes.

Backend Listener-The backend listener is a special type of asynchronous listener used to

customize the backend client.

Bean Shell Listener-The Bean Shell listener is used to enable Bean Shell for processing
samplers in J Meter.
Comparison Assertion Visualizer-The Comparison Assertion Visualizer provides
comparison between assertion results in UI.

Generate Summary Results - The Generate Summary results listener stores and displays
summary of test results into log files.

Graph Results -The Graph results listener displays each sampler’s response time in a
graphical manner by displaying average, median, deviation, and throughput.

JSR223 Listener-The JSR223 Listener is used to enable JSR223 scripting in J Meter

results.

Mailer Visualizer-The Mailer Visualizer sampler is used to send an email when the test
run some specific error threshold.

Response Time Graph-The response time graph is used to provide the graphical or chart
representation of response time with time elapsed during the test run.

Save Response to a file-The save response to a file listener is used to create a file of the
sampler response and save it. This listener is used while functional testing or debugging
the test script. It is also used where the response is too large to be displayed in the view
results tree listener.

Simple Data Writer-The simple data writer listener is used to save the sampler response
to a file.

Summary Report-The summary report stores and displays the test result in tabular form.
It is similar to an aggregate report listener but consumes less memory

View Results Tree-This listener shows details of each and every sampler request and
response in the form of a tree. It also displays the results in HTML and XML form.

View Results in Table -The view results in a table listener displaying the sampler response
header and response body in table format. This listener uses a lot of memory.

Timers

By default, J Meter samplers are executed in order without any intervention. Timers are
introduced to add wait to a thread group. Without delay, there will be too many requests
made to the server within a very short span of time, causing the server to choke. The timer
will cause J Meter to pause for a certain amount of time before each sampler. If there are
more than one timer added, J Meter will add up the time and will wait for the total time
before executing, the sampler to which the timer was applied. J Meter supports a number
of timers like:

Constant Timer:This is one of the most popularly used timers in J Meter. This is used when
we want each thread to wait for the same amount of time.

Uniform Random Timer:The uniform random timer causes each thread to wait for a
random time.

Constant Throughput Timer:The constant throughput timer is a special type of timer

used to create pauses with variable amounts of time while maintaining the overall
throughput i.e., samples/minute.

Bean Shell Timer:The Bean Shell timer is used to generate the delays using Bean Shell
scripting.

BSF Timer:The BSF timer is used to generate delays using BSF scripting.

Gaussian Random Timer:The Gaussian random timer is used to generate delays using
Gaussian distribution.

Synchronizing Timer:The Synchronizing timer is used to insert delay by blocking a certain

number of threads. Once the blocked thread count reaches a specified number then the
threads are released simultaneously thereby creating a large load. As this timer generates
a large amount of instant load hence, it is favorable for spike testing.

Poisson Random Timer:The Poisson random timer is used to generate delays with most of
the delay time interval occurring near a particular value.

JSR223 Timer:The JSR223 timer is used to generate the delays using JSR223 scripting.

Add a timer:Right Click on Thread Group → Add → Timer → Select the required Timer

Assertions

Assertions are Test plan elements in J Meter used to test the response received from the
server. Assertions assist in testing that the value returned is matching the expected value.
If the assertion fails, the sampler is marked as filed and is displayed in the listener.
Assertions are applicable to all samplers which are in scope. To limit an assertion to a
single sampler, we need to add it as a child element.
Add an assertion: Right Click on Thread Group → Add → Assertion→ Select the required
Assertion

J Meter supports different types of assertions like:

1) Response Assertion
The response assertion is used to validate a pattern in the response. Different pattern
matching rules to validate the response are as below:

● Contains – validates if the response text contains the regular expression to be

matched
● Matches –validates If the whole response text matches the regular expression
● Equals – validates If the whole response text matches the pattern (not regular
expression but the pattern string)
● Substring –validates If the response text contains the pattern (not regular
expression)
● Not – Validates that the pattern is not present in the response text
● HTML Assertion -Validates the HTML syntax of a response

2)Size Assertion -The size assertion is used to validate the response in bytes against a
specified value.

3)Compare Assertion -The Compare Assertion is used to compare sampler results.

4)BSF Assertion -The BSF Assertion is used to validate the sampler result using BSF
scripting.

5)Duration Assertion -The duration assertion is used to validate that the sampler
request gets processed within a specific time limit.

6)XML Assertion- It is used to validate that the server response has a valid XML
syntax.

7)XML Schema Assertion- It is used to validate the response against a specified XML
schema.

8)XPath Assertion -It is used to validate the response using XPath expressions.

9)JSR223 Assertion -It is used to validate the sampler result when using JSR223
scripting.
Configuration Nodes:

Configuration is a test plan element in J Meter using which we can declare variables such
that samplers can use data using these variables. Configuration nodes are executed at the
beginning of the node in which they are defined. A configuration element in a tree branch
has a higher precedence than the same element in the parent branch.

Add a Config element:

Right Click on Test Plan/Thread Group/Logic Controller → Add → Config Element →
Select the required Config Element

Listed below are available Configuration nodes available in J Meter.

● CSV Data Set Config – this configuration helps to read data in the form of a csv
file .For e.g. when we want to login using different set of unique users we can
store the username, password in a CSV file and use this file data in each thread via
variables.
● HTTP Request Defaults: We can set default values for HTTP requests using this
configuration element.
● User defined Values: This configuration element is used in defining user variables
in the form of key value pairs which can be used in tests.
● Counter – This allows a variable to increase count after every iteration.

List of other configuration nodes available in J Meter are as below:

● FTP Request Defaults

● HTTP Authorization Manager
● HTTP Cache Manager
● HTTP Cookie Manager
● HTTP Proxy Server
● HTTP Header Manager
● Java Request Defaults
● Keystore Configuration
● JDBC Connection Configuration
● Login Config Element
● LDAP Request Defaults
● LDAP Extended Request Defaults
● TCP Sampler Config
● Simple Config Element
● Random Variable
Pre-Processor

Pre-processor are J Meter test elements used to modify sampler requests before their
execution. Pre-processor attached with a sampler always executes before the sampler.

Add a Config element: Right Click on Thread Group/Logic Controller → Add →

Pre-Processors → Select the required Pre-Processors

Listed below are all Pre-processor test elements provided by J Meter:

● JDBC Preprocessor
● JSR223 Preprocessor
● RegEx User Parameters
● Bean Shell Preprocessor
● BSF Preprocessor
● HTML Link Parser
● HTTP URL Re-writing Modifier
● HTTP User Parameter Modifier
● User Parameters

Post - Processor

Post processors are J Meter test elements used to modify sampler requests after its
execution. Post-processor attached with a sampler always executes after the sampler.

Add a Config element: Right Click on Thread Group/Logic Controller → Add →

post-Processors → Select the required post-Processors

Post-Processor elements list is as follows:

● BeanShell PostProcessor
● BSF PostProcessor
● CSS/JQuery Extractor
● Debug PostProcessor
● JDBC PostProcessor
● JSON Path PostProcessor
● JSR223 PostProcessor
● Regular Expression Extractor
● Result Status Action Handler
● XPath Extractor
TEST PLAN ELEMENT ORDER OF EXECUTION
Test plan elements are always executed according to the below order.

1. Configuration nodes

2. Pre-processors

3. Timers

4. Sampler

5. Post processors (only executed if there are results available)

6. Assertions (only executed if there are results available)

7. Listeners (only executed if there are results available

J Meter WEB TEST PLAN:

We will design a web test plan to test a webpage.

We will create five users that send requests to two pages on the J Meter Website. Also, we
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. We will be using the following elements
to create the test plan: Thread group, HTTP request, HTTP request defaults and results.

Rename test plan name to “WebTestplanDemo”.

Add thread group (users) - Context Menu over Test Plan → Add → Thread
→ThreadGroup
Configure the thread group created in step 2 above. We will edit the default values at the
section to the right of the thread group control panel in the J Meter window.

Name – Add a name like “Users”

Number of Threads -Set number of threads to “5”. This will increase the number of users
to 5.

Ramp-Up Period -Default it to 1 second. Ramp up period tells the user the delay between
each user. Here J Meter will finish starting all users by the end of the defined ramp up
period which is 1 second. When the ramp up period is set to 0, J Meter will start all users
simultaneously.
Loop count – This property is used to define the number of times the test should be
repeated.

Action to be taken after sampler error – we can also select the action upon error
depending upon the test case.

We can also configure if we wish to use the same user for each iteration or different user.

Add HTTP Request sampler- Context Menu over Test group (users) → Add → Sampler →
HTTP request.
An empty HTTP request sampler will be created under the thread group with name users.

● Configure the sampler to create in step 4 above.

● Name – enter a name suitable to the request for e.g. – homepage
● Protocol-default value of protocol is HTTP, as such we will leave it blank.
● Server name /Ip – Set the server’s name to the name of the server we want to
test: www.wikipedia.org (without the http or https protocol) in this case.
● You should modify the connection values for port, protocol, method to execute in
the server, etc. if needed.
● HTTPS request type – GET
● Path: set to / which implies that we want the root page of the server.
● Add Listener: Listeners help to view results of the sampler node later.
Context Menu over Test group (users) → Add → Listener → View results Tree
option.

● Save and run the test plan.

File →Save (or click "Control + s")

Run →Start (or click play as explained before)

Apache J Meter asks us to save the test plan in a disk file before actually starting
the test. This is important if you want to run the test plan multiple times. You can
opt for running it without saving too by selecting “NO”

● View results:

We can see that all the requests have been done as expected and all of them
provide meaningful responses, so it seems that the
The web page that we are testing works fine (if this is the expected behaviour).
We can play around with the results and check all the
returned data.
Details of the above result are −

● Green color against the name Home Page indicates success.

● J Meter has stored all the headers and the responses sent by the web server and
is ready to show us the result in many ways.
● The first tab is Sampler Results. It displays J Meter data as well as data returned
by the web server.
● The second tab is Request, which displays all the data sent to the web server as
part of the request.
● The last tab is Response data. In this tab, the listener displays the data received
from the server in text format.
Add timer –

Context Menu over Test group (users) → Add → Timer → Constant timer

Update thread delay (millisecond) to 500. This will ensure that every request will wait 500
milliseconds after the last one is finished.

Add assertion: Context Menu over Test group (users) → Add → Assertions →Duration
assertion we configure it to assert false if the response takes longer than 100 milliseconds

Database test plan

We will design a database test plan that will help us test a database server. We will create
50 users which will send 2 SQL requests to the database server. Additionally, we will tell
the users to run their tests 100 times. So, the total number of requests will be (50 users) x
(2 requests) x (repeat 100 times) = 10'000 JDBC requests. We will use the following
elements to construct the database plan: Thread Group, JDBC Request, Summary Report.

● Add users/Thread group: Context Menu over Test Plan → Add → Thread
→Thread Group
● Configure the thread group created in step 1 above. We will edit the default
values at the section to the right of the thread group control panel in the J Meter
window.
● Name – Add a name like “JDBC Users”
● Number of Threads -set this field value to “50”. This will increase the number of
users to 50.
● Ramp-Up Period -Set ramp up period to 10 seconds. Ramp up period tells the
user the delay between each user. Here J Meter will finish starting all users by the
end of the defined ramp up period which is 10 seconds. So for 50 users having 10
second Ramp-Up Period, then the delay between starting users would be 200
 milliseconds (10 seconds / 50 users = 0.2 second per user). When the ramp up
period is set to 0, J Meter will start all users simultaneously.
III. Loop count –We will set it to “100” indicating that the test should run 100
times.

● Add JDBC Requests sampler -Context Menu over Test group (users) → Add →
Config element → JDBC Connection Configuration. Add the values
corresponding to below fields related to the database which you will be using.
● Variable name 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 Driver class
● Username: the username of database
● Password: password for the username
● Add JDBC Request sampler- Context Menu over Test group (users) → Add →
Sampler → JDBC request.
● Configure JDBC sampler - select this new element to view its Control Panel
● Change the Name to 'VM Running'.
● Enter the Pool Name: 'My Database' (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'.
● Add Listener: Listeners help to view results of the sampler node later.
Context Menu over Test group (users) → Add → Listener → Summary Report

Save the test plan, and run the test with the menu Run → Start or Ctrl + R

J Meter FUNCTIONS

J Meter functions are special values which can display fields of any sampler or any

J Meter test element within the test.

Syntax of a function in J Meter: ${__functionName(var1,var2,var3)}

Where function name is the name of the function followed by parameters in parentheses.
To add a function parameter with a comma, then we must use it along with the escape
character "\", else J Meter will treat it as a parameter delimiter. Functions and variables in
J Meter are case-sensitive.
Below is a list of functions supported by J Meter.

Regular Expressions:Regular expressions are used to search for a pattern in a test plan.
Regular expression help in fetching useful information from the server response easily. A
popular use case would be to fetch the value of session id from the server response using
regular expression. Regular expression can be added to any component in a test plan.
Regular expression is added to test plan via Regular expression extractor.

Add regular expression:

1)Right-click on the thread group → Add →Post Processor → Regular Expression

Extractor.

2)From the view result tree

J Meter BEST PRACTICES:

● J Meter UI is a very powerful tool to create and configure test plans. J Meter also
provides a non-UI /CLI mode for running test cases and saving results. It is
recommended to use J Meter in CLI mode for execution as it is much faster than
UI mode.
● Listeners consume a lot of memory space and resources. It is recommended to
use a few listeners. After using listeners, it is recommended to disable or delete
them.
● Use samplers in a loop by defining variables instead of using multiple samplers
with different parameters.
● Use CSV output as opposed to XML.
● Use minimal assertions
MOBILE APPLICATION TESTING USING J Meter

Follow the steps below for Android or iOS mobile apps.

1. Launch your J Meter.

2. Right-click the Test Plan >> Add >> Threads (Users) >> Add Thread Group.

3. Right-click the Thread group >> Add >> Logic Controller >> Add Recording
Controller

4. Right-click the Threads>>Add>>Listener>>View Results Tree(To view the

outcome of your script).
5. Add > Non-Test Elements > Add HTTP’s test script recorder.

6. Go to HTTP(s) Test Script Recorder and set port to 8888 (or any available port).
 7. Click on the Start button displayed on HTTP(S) Script Recorder
8. Dialog box gets opened to allow Root CA Certificate and just click the “OK” button.

How to locate your IP Address

● To locate your IP Address, launch the Command prompt and type ipconfig for
Windows / ifconfig for Linux, and press ENTER button to get the IP address.
● We will use this IP address on our mobile device- iOS or Android phone to set
up the proxy.
● Firstly, you will need an appropriate Apache J Meter Temporary Root CA
Certificate to save it to your phone.
● Download the zip file for the certificate for your required operating system
and store it in the mail.
● Install the certificate by mail on your mobile device. It will ask to apply the
lock. Then a notification pop-up displaying the network can be monitored.
● Now, let’s start the actual configuration process for the mobile.

Android device proxy configuration

1. On Android Mobile devices, go to Settings > Wi-Fi option (Shared Wi-Fi network
should be the same for both mobile and PC where J Meter is installed).
2. Long tap on your current network connection and click the ‘Modify Network’
Option.
3. Check the checkbox for ‘Advanced Options’

4. This will open the advanced settings, from which we can modify the proxy
manually. For this, set the ‘Proxy’ option to ‘Manual’.

5. Now, set ‘Proxy Hostname’ as your PC IP address and ‘Proxy Port’ to 8888 as we
have set up in the J Meter proxy server.
 6. Save the changes you made, Now, you can start running the application on your
mobile device and its requests will be automatically recorded in J Meter.

IOS device configuration:

1. On iOS devices, go to Settings > Wi-Fi option (Shared Wi-Fi network should be the
same for both mobile and PC where J Meter is installed).
2. Click on the connected network.
3. Select the ‘Manual’ option as HTTP Proxy.
4. Set the ‘Server’ as your PC IP address and ‘Port’ to 8888 (or any available port) as
the J Meter proxy server.
5. Install the downloaded certificate for iOS.

Start Recording Your Mobile Web Application

By now, you must have understood the mobile configuration process. Now, it’s time to
open the web application you usually need to test and use.

1. Launch the application on mobile and every request will be recorded in J Meter.
2. Before running any application on the device, make sure you click the ‘Start’ button
on the HTTP(S) Test Script Recorder in J Meter.
3. Open the mobile application for which you want to do the load test, and play with
the functionality the way you want to record functionality in J Meter.
 4. Since we have set the mobile connection to J Meter’s proxy, thus all the test flows
are recorded in J Meter’s test plan.
5. Once you have recorded all the test flow of your application, stop recording by the
‘Stop’ button on the ‘HTTP(S) Test Script Recorder’ in J Meter and save the test
plan.

6. Now run your test plan by clicking the ‘Play” button displayed in green at the top.
This will run the recorded script as per your thread setup.
7. After playing the test plan, you can see the response of each request in the ‘view
result tree’ listener.

Your script is ready to run the load. You can further refine it by adding correlation,
parameterization, etc.