In the previous tutorial of Getting familiar with JMeter GUI we got to know about JMeter GUI and it’s Menu bar. In this tutorial we will move ahead and learn more about Test Plan Elements and its Execution Order. Although we will not get in to the details of each of it and just covering the high level understanding of the different Elements of a Test Plan. But we will cover these in depth in the later tutorials. So as of now, just focus on how many are they and their purpose.
Thus, we will be covering following topics in this tutorial.
- Jmeter Test Plan Elements
- Thread Group
- Logic Controllers
- Configuration Elements
- Post Processor
- Execution Order of Test Plan Elements
What is a Test Plan in JMeter?
Test plan consists of all actions and components you need to execute your performance test script. You can add sampler, listeners, preprocessors and many other components in your test plan as per the scenario under test. All these components are explained in detail in later lectures. It can be viewed as a container for running tests. It defines what to test and how to go about it. Everything which is included in a test plan is executed in a sequence which is top to bottom or as per the defined sequence in the test plan.
As we all know that JMeter measure performance by generating Virtual Users or Threads which hits server under test as if real users are sending requests to a server. Therefore, every Test Plan should have virtual users or Thread Group as we call them in JMeter’s terms.
Important things to remember:
- The test plan should be saved before running
- Jmeter files or test plans are saved in form of. JMX extension files
- You can also save parts of Test Plan as the different selection. For example, If you want to save a Thread Group Element, you can save it as Test Fragment so that it can be used in other test scenarios as well.
What are the Different Test Plan Elements in JMeter?
JMeter Test Plan consists of hierarchical structure and components. These components are known as elements of a Test Plan. As mentioned above, we will now learn about the elements of a test plan and their use.
A thread is the request that is sent to the server. A Thread Group is number of virtual users that are used to hit the server/application under test. It is a set of threads executing the same scenario i.e. the group of requests sending the same requests to the server. It is a child element of a Test Plan. Thread Group simulate the real user by sending request to the server under test. Without a thread group JMeter will not be able to send request to the server. Thus, every Test Plan has at least one thread group. Hence, you can say a thread group is a backbone of any Test Plan.
This is how a Thread Group Element looks:
Samplers tell JMeter to send requests to a server and wait for a response. JMeter supports testing HTTP, FTP, JDBC and many other protocols. Thread Groups simulate user request to the server but with the help of Sampler it send the specific type of request for example HTTP Request.
As Thread Groups need to use a Sampler to send a request to server, Samplers can only be added to Thread Group and not directly under the Test Plan.
Sampler Responses are saved by the listeners and hence, results are obtained. They are processed in the order they appear in the Test Plan tree (Tree is nothing but the Test Plan and its components in the left pane in JMeter).
For every protocol there is a need of separate sampler. Thus, JMeter has many samplers and the list includes:
As described above, samplers are processed in the order they appear in tree structure by JMeter. But, while working on samplers in a Test Plan there could be some scenarios when you want to customize the order of execution of your requests. There could also be a scenario when you would like to send the same request multiple time, just to simulate the real time scenario. Thus, Logic Controllers let you customize the logic that JMeter uses to decide when to send requests. Logic Controllers can change the order of requests coming from their child elements.
Logic Controllers that JMeter provides include:
A Pre-Processor executes some action prior to a Sampler Request being made. If a Pre-Processor is attached to a Sampler element, then it will execute just prior to that sampler element running. This element is mostly used to alter the settings of Samplers in their scope. As per requirement, the results of pre-processors works as data for samplers and then request is sent to server. Thus, this way depending upon the results obtained by pre-processors it changes the setting of the sampler request. It will always execute before the actual sampler request. Pre-Processors are often used to fetch data or timeout setting between sampler requests.
Below is the list of all the Pre-Processors in JMeter:
A Post-Processor executes some action after a Sampler Request has been made. If a Post-Processor is attached to a Sampler element, then it will execute just after that sampler element runs. Like Pre-Processors, post processors are also applicable to all the samplers in the same scope. Therefore, to restrict the post-processor to a particular sampler it has to be the child of that sampler. Response from the post-processor are used to process the server response and modify the component settings or to retrieve the variables for later use.
Below is the list of Post- Processor in JMeter:
Assertions allow you to assert facts about responses received from the server being tested. Using an assertion, user can test that if application is returning the results as per the expectations or not. With Assertions you can verify status code and text in response. Adding an assertion as a child of the sampler restricts it to a single sampler. Otherwise, assertions will apply to all samplers that are in scope.
You can view assertion results by adding Assertion Listener to the Thread Group. Failed assertions will be displayed in other listeners as well. (We will be discussing about Assertion Listeners in detail in our upcoming tutorials).
Below is the list of assertions that JMeter provides:
The timers allows JMeter to delay the execution by a certain amount of time before each Sampler. Because By default, a JMeter thread sends requests without pausing between each sampler. This may not be what you want. You can add a timer element which allows you to define a period to wait between each request. Timers are added as child elements of a sampler or logic controller.
If you do not add a delay, JMeter could overwhelm your server by making too many requests in a very short amount of time. Thus, use of timers is recommended to specify a delay to your Thread Group.
Delay in between sampler requests can be needed for the following reasons:
- To simulate the time that the user takes to perform the next action on the web page.
- Delay is needed to simulate load distribution on server.
Available JMeter timers are:
Requests sent to the server can be further parameterize using some config elements which are executed before the actual request. As the name suggests, these are the basic configurations which can be set for the various tests. It stores common configuration settings/values in their element. Thus, Configuration elements can be used to set up defaults and variables, so that Samplers may use data through them.
These elements are processed at the start of the scope in which they are found i.e. before any sampler in the same scope. They are accessed from inside the branch in which they are placed.
List of Configuration Elements in JMeter is:
Performance testing is all about analyzing server responses in various form and then presenting the same to the client. Listeners provide access to the information JMeter gathers about the test cases while JMeter runs. There are around 15 listeners in Jmeter but mostly used ones are table, tree, and Graph.
It provides visual access to the information JMeter collects while running the test. You can see requests, responses, plot results to a graph or even aggregate the results. No need to say but these results can be saved, so that it can be compared.
List of Listeners in JMeter is as follows:
Execution Order of a Test Plan
Like Every programming language has its certain set of rules for execution JMeter also follows certain set of rules while executing a Test Plan. As you know, every Test Plan has at least one thread group. Therefore, execution starts with the execution of a thread group. As mentioned in the above section, if a Test Plan consists of more than one thread group then, they are executed in the order in which thread group appears in the tree structure. Within the Thread Group the order of execution of components follows as seen in figure.
Therefore, execution starts with the Thread Group. After that, Configuration Elements if any are executed followed by pre-processor elements. After pre-processor elements timers are executed to delay the sampler requests by certain amount of time. Then, logic controllers if exists are executed followed by samplers. After execution of samplers post-processors are executed and assertions are done. Ultimately, listeners are executed to provide you end result. Hence, test plan results can be seen as per the listener that has been used in the execution.
Summarizing the above tutorial, you have learned about the various elements of a Test Plan and their execution order. In the upcoming tutorial, we will follow each element closely and dive deep into them explaining their working in detail. So don’t worry if anything went over your head, you will learn them eventually.
Test Plan Elements, Test Plan Elements, Test Plan Elements, Test Plan Elements,Test Plan Elements