Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Requirements
Knowledge of Performance Testing concepts
Basic understanding of Web Applications, browser features, HTTP(S) communication
Basic Idea on XML (to read the JMX script using an editor), Java Script
Test Plan
Config Thread
Listeners
Elements Groups
Config
Controllers Listeners Samplers
Elements
Post Config
Assertions Timers Listeners
Processors elements
From the above diagram, it is clear that Listeners and Config elements can be configured at any level,
thus defining the scope for them. If the listeners are defined at the Sampler level, they work only for
that sampler. If they are defined at the thread group level, they can work with all the samplers under
the thread group. If they are defined at the Test Plan level, they are applicable to all the thread groups
and all the samplers under the thread groups.
However, this works a little different for the Config elements. Each of the config elements have their
own scope which would be explained in detail at the Config Elements section.
Test Plan
A test plan contains the overall settings of the performance test. A test plan can have multiple Config
elements, listeners and Thread Groups. The test plan can control the execution (parallel or sequential) of
thread groups and can also be used to save the responses.
Thread Group
A thread group is where the number of threads (users), ramp-up rate and the start times of the thread
group are defined. All the items under a thread group are executed by multiple threads/users. A thread
group can have multiple samplers, config elements, controllers etc.
Samplers
These are the actual requests made from the JMeter tool. These samplers can be a HTTP Request, Web
Service request or JDBC request or can be even a java request. For performance testing the web
applications using JMeter, each thread group will have several HTTP requests which will be executed by
multiple threads concurrently and thus causing the load on the web application
Config Elements
Config elements are the ones to needed / can be configured the way the samplers /thread groups / test
plan are executed. The most commonly used HTTP config elements are HTTP Cookie Manager, HTTP
Cache manager, HTTP Auth Manager. Similarly to run a JDBC sampler, the JDBC config element has to
be specified.
Controllers
Controllers are used to control the flow of a thread through the thread group. All the conditions like If,
for, while etc. are the examples of Controllers
Assertions
Assertions are to validate the response that is received when a request (a sampler is executed) is made
to the application. The assertions can be text assertions, XML assertions, Xpathetc
Post Processors
Post processors are used to perform actions once a response is received for a particular sampler
request. The most commonly used post processor is the regular expression extractor
Timers
Timers are used to delay the execution of the thread or to make the thread wait for the specified time.
The commonly used timers are constant timer, Gaussian random timer etc
Listeners
Listeners are the reporting entity of JMeter which can be configured at the sampler / thread group /test
plan level. The most commonly used listeners are View results tree, View results summary and
aggregate report.
Script Recording
Script recording in JMeter can be done by sniffing all the communication that is happening on a proxy.
Below are the steps involved in recording a sample web application.
2. Add a thread group to the test plan. Right click on Test plan Add threads thread Group
3. Add Http(s) script recorder to workbench. Right click on Work Bench Add Non-Test
Elements HTTP(S) Test Script Recorder
4. Configure HTTP(S) Test Script Recorder. Specify the proxy port (8080 is default). Choose Target
Controller as Test Plan > Thread Group and Grouping as “Put each group in a new transaction
controller”, click on Add suggested Excludes
5. Click on Start. Click OK on the pop-up. Now JMeter is configured to listen to all the
communication happening on port 8080.
6. Launch your browser and go to network settings and configure the browser to run on proxy. In
IE, the navigation is: Tools Internet options connections LAN Settings Use a proxy
server for your LAN. Below is the screenshot:
In case of Firefox, the navigation is Tools Options Advanced Network Settings
Manual Proxy configuration. Screenshot is as below:
7. Launch the application in the browser which is running on the proxy. Under thread group a new
transaction controller should be created as seen below:
8. Click on Transaction controller and change the Name of the transaction to make more
meaningful.
9. Perform the next user action and rename the transaction controller name. If you see more than
one transaction controller being recorded for the same user action, move all the requests under
the transaction controller to one and rename the controller.
10. Repeat this for the complete navigation to be automated. Once the complete navigation is
recorded, go to HTTP(S) Test Script Recorder and click on Stop Button.
11. Save the JMeter script. The script would be save as a JMX file and can be viewed in any editor as
an XML file. When loaded in JMeter, the script is seen as UI controls. Each element of the
JMeter script is explained in detail in the coming sections.
Note: Ensure to change the browser settings to normal.
Script customizations
Once a JMeter script is recorded, it cannot be played back or it cannot be used directly for the
performance test. Any Performance test script should be customized to implement the below to
simulate the realistic user behavior on the application:
1. Parameterization – To send different user inputs to the script. This is to simulate the real
user inputs like the user name and passwords, search criteria, billing and shipping address etc. In
JMeter, the most common way of implementing parameterization is through CSV data set
config, which is a part of Config Elements. CSV Data Set Config is used to read the values from a
CSV file and store the values into JMeter variables.
2. Correlation – Handling the dynamic data in the user request. This is to simulate the real user
behavior of user selections either check boxes, radio buttons or dropdown picks etc.
Correlations involve in identifying the dynamic data of a request and capture the dynamic data
from the any of the previous responses and pass on to the current request. Regular Expression
extractor which is a part of Post processors is used for correlation.
3. Page Verification: This is to ensure that the correct response is received during the
performance tests. A text which is static, specific to that request would be searched. If the text
is not found, the tool assumes that the response received is not a valid response. Response
Assertion which is a part of Assertions is commonly used for Page verification with the Web
based applications
4. Transactions: The objective of this customization is to measure the response time for each
user action. An user action can contain more than one request and to measure the end user
experience all the such requests which belong to one user action are clubbed together in JMeter
as Transaction Controller, which provides the overall response time of the all the requests
5. Think times: To simulate the real user wait times between the requests (to enter the inputs
/ think / reading the content), think times should be included in the scripts. In JMeter, Timers
are used to wait between the user requests.
Samplers
HTTP Request
Http Request belongs to the Sampler category. The core of a Web based JMeter script is the HTTP
Requests. An Http request (HTTP Sampler) in JMeter looks as below:
The most important attributes in a HTTP request are:
BSF Sampler
This sampler allows you to execute a piece of code written in any BSF scripting language. By default
JMeter supports the below languages in a BSF sampler:
Java Script
Jexl
Xslt
Attributes:
Debug Sampler
The Debug sampler is used to debug the script, especially to ensure all the JMeter variables has got the
right data in them. This is added during the debug phase of the script and should be deleted / disabled
while executing the performance test. The Debug Sampler can be configured to control the list of things
to be displayed response data Pane in the View Results tree listener. Usually the JMeter Variables is the
only one set to true with the debug sampler.
Usually the header management is taken care by the performance tools automatically. However, if
the application has some customized headers, those have to be handled in the request explicitly.
HTTP Header Manager is always added as a child to HTTP Request sampler. The scope of Http
Header Manager is usually at the sampler level because each request can have different request
headers. If most of the request headers are the same for all the Http requests, this can be defined at
the thread group level so that it is applied for all the Http request samplers. The additional headers
can be added through another Http Header manager at the sampler level. For example the below
screenshot highlights the way additional headers are added.
The default headers are added at the thread group level and the additional headers are added at the
sampler level.
When the request is executed, the View results tree listener’s Request pane shows that all the seven
(7) headers are sent as part of the request. Please find below the screenshot:
1. Store and send the cookies similar to that of a web browser - If you have an HTTP Request and
the response contains a cookie, the Cookie Manager automatically stores that cookie and will
use it for all future requests to that particular web site. Each JMeter thread has its own "cookie
storage area". So, if you are testing a web site that uses a cookie for storing session information,
each JMeter thread will have its own session. Note that such cookies do not appear on the
Cookie Manager display, but they can be seen using the View Results Tree Listener.
2. Manually add a cookie to the Cookie Manager - However, if you do this, the cookie will be
shared by all JMeter threads.
The scope of the Http Cache Manager is usually at the thread group level.
Attributes
Sharing Mode:
Sharing Mode Number file instances created
All Threads One instance for the entire test plan and every
thread reads a line from the file and is updated
every round. The file scope is global. All the thread
groups and threads read from the same file.
Current thread group One instance created per thread group. If there
are 2 thread groups 2 instances of the file is
created one for each thread and the thread group
reads the values from their own instance and is
updated every round. The scope is local to thread
group. Each thread group will have its own
instance and all the threads under the thread
group will read a line from the file.
Current thread One instance per thread is created. If there are
total of 10 threads, then 10 instances of the file
are created. The scope is local to each thread and
reads a value from the file every round.
Below is the pictorial representation of how the file is being read with various sharing mode options:
Transaction Controller
The transaction controller is used to group all the samplers that make a transaction. This is used to
measure the overall response time of a transaction instead of an individual sampler. When transaction
controller is added, in the summary report or Aggregate report, the transaction controller would also be
seen and its response times are measured.
Example: When the user enters the user name and password in a web application, internally the
application may have 5 – 6 requests. However, from the end user point of view it is just logging into the
application. In this case, the overall response time for these 5 – 6 requests would make more sense to
the end users than the individual request’s response time. Hence, all these 5 – 6 requests are grouped
using a transaction controller.
Attributes
If Controller
This is similar to any other If condition in any other language. If some requests are to be made based on
condition, this controller is used. The condition is usually evaluated as a java script code and based on
the condition the child samplers would be executed.
Attributes
While Controller
The While Controller runs its children until the condition is "false".
Attributes:
Timers
Constant Timer
A constant Timer will introduce a fixed delay between consecutive requests of the same thread. . This is
used as Think Times between two transaction controllers to emulate real time traffic.
Parameters
Attributes
Pre Processors
User Parameters
User parameters work exactly the same way as user defined variables, except that they are executed
only at their designated position. All the user defined variables are executed at the beginning of the test
plan and hence no JMeter variables that are captured or created during the execution cannot be used in
User defined variables. User Parameters are helpful to serve this purpose. The JMeter variables created
or captured before user parameters can be used in the user parameters. Below is the screenshot of a
simple user parameter:
There is a provision to send different values to different threads instead of the same value. This can be
achieved by clicking on Add User and corresponding value as seen below:
Now in the above example, thread 1 will read the value Test1, thread 2 will read the value Test2, thread
3 will read Test 3, and thread 4 will read the value 4. If there are more threads, then thread5 will read
the value Test1, thread 6 will read Test2 and so on.
There is also provision to add multiple variables by click on Add Variable button.
Post Processors
Match No. Use a value of zero to indicate JMeter should choose a Yes
random match.
A positive number N means to select the nth match.
If the regular expression does not match, then the reference No, but
Default Value
variable will be set to the default value. recommended
Examples:
Response Assertion
Response Assertions are used to validate if the response received is valid or not. This can be done
either by searching for the response code or searching for some static text which is specific to that
request. The most commonly used response assertion is as below:
Listeners
Listeners are the reporting entities in JMeter that gather some details from the test. Each listener serves
a purpose and below is the most important listeners that are used with any JMeter tests:
The aggregate report can be written to a file so that the data can be used later.
The same data can be exported to a CSV file which can be used later. Configure button enables to
control what has to be written to the file.
View Results summary
View Results summary stores the information about every sampler, which will be helpful in analyzing a
sampler’s trend. Again this data can be written to a file for future use.
Summary Report
The additional information that summary report provides the std. deviation of the response times from
their average values.
Other listeners
All the listeners that start with jp@gc are the graphical representation of the corresponding data. To
have them listed under the listeners, all the standard plugins should be imported. They can be imported
from the URL: http://jmeter-plugins.org/
Running Performance Test
Thread pool has to be configured to specify the user load, duration of the test. Once this information is
verified, click on Run button to start the test. This will be running the test with the specified users for
specified duration. However, to ensure that the script is running without errors, please check the log by
clicking on the Warning Icon to the top right. Monitor the machine’s CPU and memory utilization during
the test to figure out the maximum user load that can be generated from a single machine.
1. Configure jmeter.properties file to add the host name or IP address of the Load Generators:
Once the above steps are completed, close JMeter and open again (to take the properties change
reflected) and navigate to Run Remote start choose one of the LG and click. This will launch the
test from the chosen load generator. The most important point to be remembered is the thread
pool settings are transferred to the LG and each LG will generate the same number of threads. For
example if a thread pool has 25 threads and distributed testing is in place, the final user load would
be 25* number of LGs configured.
Conclusion
This document is to provide a basic understanding of JMeter for Web Application automation.
Considering the features provided by JMeter, this document may not be useful for other protocols
like Web services, JDBC etc. To automate such protocols, the individuals should have at least the
basic idea on how the corresponding protocols work. The detailed documentation would be
available at the URL: http://jmeter.apache.org/usermanual/index.html