Let’s assume that you want to implement performance testing on one of your projects, but what can…

Introduction to JMeter

Let’s assume that you want to implement performance testing on one of your projects, but what can you use for this particular job? Suffice to say that JMeter is perfect for the job. JMeter was “designed to load test functional behavior and measure performance” and was “originally designed for testing Web Applications”. But starting out with JMeter could be quite a challenge if you have never used it before. This article is for you to have a grasp of the different terminologies.

What you will need

Your computing environment needs to meet some requirements in order to be able to use JMeter. You will have to install the compatible Java version (Java 8 or Java 9 for JMeter 4.0) and it is recommended to have the latest release of those versions because of the security and performance reasons. You will need to have a JDK. With those, as long as your OS has a compliant Java implementation, JMeter surely will run correctly on your system.

Overview

JMeter is so advanced that it has a user-friendly interface that people usually use JMeter in GUI mode and follow an easy process. After running JMeter in GUI Mode, you can choose to record the application from a browser or a native application. For that, you will need to use the above menu, and click on File > Templates… > Recording. After you have recorded your test plan, you will also debug it using 3 techniques: Run > Start no pauses, Run > Start, and Validateon Thread Group. There is also one other way you can build your test plans, and that’s manually building it. To be able to build the test plans on your own, you must first be able to comprehend the parts of a test plan.

Elements of a Test Plan

The most basic test will be comprised of the Test Plan, a Thread Group, and one or more Samplers. But what exactly are they, and what else can be in it?

A Test Plan is a series of events that are to be executed when JMeter is running. A complete Test Plan is likely to consist of one or more Thread Groups, logic controllers, sample generating controllers, listeners, timers, assertions, and configuration elements.

• JMeter Controllers are separated into two types: Samplers (sample generating controllers) and Logical Controllers. These elements are the driving forces of the processing of tests. Samplers command JMeter to send requests to servers. JMeter Samplers include:

o FTP Request

o HTTP Request (can be used for SOAP or REST Webservice also)

o JDBC Request

o Java object Request

o JMS Request

o Junit Test Request

o LDAP Request

o Mail Request

o OS Process request

o TCP request

You can also customize samplers by adding Configuration Elements to Test Plans.

Logic Controllers

Logic Controllers have the ability to change the order of requests coming from their child elements, they can decide when a request will be sent, change requests and also make JMeter repeat them.

You can see several controllers and other elements in the above test tree. To understand the effects of Logical Controllers, we could consider this example. For instance, “Once the Only Controller makes it so that the Login Request only happens one time at the first time. Assume that after you load the search page on a web application, you want to search for 2 different words. You can simply load the search page, search “A”, load the search page again, then search “B” and that takes 4 different requests. Instead, we can use an Interleave Controller to search “A” and “B” consecutively. This does not make too much difference in this example, but in actual testing processes there may be 100 words to search and using Interleave Controller will not be overkill.

• Listeners are the agents that provide access to the information risen from the test cases run with JMeter. All listeners save the same data, but the way they present them differently. Graph Results Listener can plot the response times on a graph, View Results Tree Listener can provide details of sampler requests and their responses. There are also other listeners to provide summaries. They can also save data to a file if required so. Listeners are only able to provide access to data from an element at their level, or below it.
• Without Timers added to your tests, JMeter could cause traffic to your server in a short amount of time. Therefore, to not have too many requests made, you should add timers to your tests. They will JMeter to delay for the specified amount of time before every sampler in its own scope.
• Assertions, as you might know from unit testing frameworks like JUnit if you’ve used them before, are what you would call checkpoints where you make sure your application is doing what it is supposed to be doing. It essentially tests your application. To get the data on the assertion results, you should not forget to add an Assertion Listener to the Thread Group.
• Configuration Elements are created to enable more elasticity to Samplers. These elements are not designed for sending requests (with the only exception being HTTP(S) Test Script Recorder), however, they are able to add to the requests, or modify them. Where you place a Configuration Element matters a lot because they are only accessible to the elements inside the same tree branch.
• If a Pre-Processor is included in a Test Plan, it executes a required action before a Sampler Request is made. If it is attached to a Sampler, it will execute the action just before that sampler is running. This element is mostly used to modify the settings of a Sample Request before it runs, or to update variables that aren’t extracted from response text.
• Post-Processor works exactly like a Pre-Processor, except it only executes the action after the Sampler Request is made. These are used to process the response data, often to extract values from it.

Thread Group

After the Test Plan and the various elements of a Test Plan, it is time to explain what a Thread Group is. A Thread Group, like its name, is a thread group all the elements inside. It is the starting point to any test plan. All controllers and samplers must be under a thread group, but others, such as listeners can be placed directly under test plans, which means they are applied to all the thread groups in a test plan.

The controls for a thread group will allow you to decide on the number of threads, the ramp-up period and the number of times to execute the test. Each thread in a test plan is completely independent of the others. The ramp-up period is the period of time after which all used threads should be running. Each thread is started one by one, each time waiting for an amount of time that can be calculated by “ramp-up period/number of threads”.

There is also a checkbox at the bottom of the Thread Group Panel to enable further fields to set other parameters. This is basically a scheduler. You can enter the duration of the test, the initial delay length, the starting and the ending times of the test run.

Order of Execution

After all these clarifications, you must be confused as to what the order of execution is. In general, considering there is one of each element in a Thread Group and they are all direct children of the Thread Group, the order of execution is as follows:

Of course, the order of execution is normally like this considering all elements are direct children to the Thread Group; but if there was more depth to the tree, meaning if there were grandchildren or grand-grandchildren to the Thread Group, the order of execution for that specific Test Plan would be different. This list is basically for their priorities.

You may be as confused as a homeless man on house arrest because you are new to JMeter; but after trying it out considering this article, you will surely understand these concepts. To go on to read further about how to design Test Plans, you can check out this article, or you can check this article to read about distributed load testing using JMeter on the Cloud. You can also check here to learn how to use CSS Selectors in JMeter Scripts.