Load Testing: Logic Controllers in JMeter (Include, Interleave, Loop, Module, Once Only)

This is a continuation of my previous post (Load Testing: Logic Controllers in JMeter (Transaction, ForEach, If)). Here I show some other useful logic controllers

1.     Include Controller: This helps using same steps across test plans. Suppose you save several test plans and each of them requires you to login to the system. Adding login steps in each test plan is not worthy. Rather you can use include controller as described below.

a.      Create a test plan that contains a Test Fragment and all the steps related to login within it as shown below

c.     Open a different test plan where you want to use this login steps. And add an include controller in place of login steps and provide the file name of the login test plan that you have created in previous steps.

That’s it. Steps from the file as mentioned here will be execute as part of this test plan.

2.    Loop Controller:  As the name suggests, it allows you to loop through steps. Use of it is pretty straight forward. Just add you steps within a loop controller and asks the loop controller how many times it needs to loop through the steps.

  

3.    Interleave Controller: This is not used very often but can be useful sometimes. It allows you to execute alternate steps within a loop. Suppose you have 3 pages that user visits. And you want your test to tool 10 times for these pages. Additionally you want your test to execute only one of those three pages in every loop. You can use Interleave controller in this context as shown below

4.     Module Controller: This allows you to reuse logic controllers within a test plan. Suppose you are visiting a page in your test plan. And it comprises of some HTTP requests, assertions etc. And all these are consolidated with a logic controller. And suppose during the course of load testing you are visiting the same page again within the same test plan. You may not want to repeat the same steps here again. So you can take the help of module controller to refer to that logic controller here. Shows below how you can accomplish that

a.       Get all the steps, you think will repeat, in a single logic controller.

b.    Add a Module Controller to a place where you want the above steps to repeat. And select the logic Controller from ‘Module To Run’ dropdown in module controller.

 

 

5.    Once Only Controller: This, when applied within a loop, executes the associated steps only once across the loops. Suppose, you have a loop and it consists of several steps. You want one of the steps to execute only once when the test is looping across. This is pretty simple. Just add once only controller within the loop and add the steps in it.

Here the steps associated with ‘Transaction Controller: Home Page’ will be executed only once within the loop.

Load Testing: Logic Controllers in JMeter (Transaction, ForEach, If)

A simple way to describe JMeter is a tool that captures the way your web application interacts with the web and assesses performance of your web application. Like other testing tools, it has steps that in a combination carry out a particular test. JMeter offers logic controllers to group your steps so that you can ascertain the way the steps behave. One you get along with JMeter, using some of those logic controllers will be inevitable. Here I will try to show how to use some of the logic controllers I often use.

1.    Transaction Controller: This helps you to group steps. Suppose you want to assess the performance of a successful login action. And a successful login action requires more than one HTTP requests. So you can group them in a transaction controller as shown below.

Then add a Summary Report listener to the thread group. Now if you run the test you will notice that a separate assessment is being shown for transaction controller.

2.    ForEach Controller: ForEach controllers are very helpful to loop through an array. Suppose, you are visiting a page that contains a list of some objects. You want to delete some objects with names having a common prefix. And the delete operation requires ID of an object being deleted. Now you can do the followings:

a.    Identify the HTTP request that loads list of the objects. Add a Regular expression extractor (post processors) that extracts IDs of the objects you want to delete. You can configure the extractor as shown below

1.       Give a  name of the variable/array

2.       Enter regular expression that extracts the ID

3.       Add template to refer to group 1 within the regular expression

4.       Add -1 to consider all values returned by the regular expression

5.       Add a default value of the variable

b.      Add ForEach controller and place the delete step within as shown below

1.       Give the reference name of previous step as ‘Input variable prefix’ here

2.       Enter an ‘Output variable name’. This variable will be referred in delete step.

c.       Refer to the ‘Output variable name’ as given above in delete step as shown below

If you run the test now, you will notice that the steps mentioned under ForEach Controller is executed as many times as the IDs the regular expression extractor returns. You can check this in a View Results Tree listener.

3.     If Controller: As the name suggests, it allows you to apply if else condition to your tests. Suppose you have two different sets of steps to create two different types of users. And you want your test to decide which set of steps to execute depending on the value of a variable. You can do the followings

a.    Group the sets of steps as mentioned above in two different If Controllers. And add a ‘User Defined Variables’ config element as shown below

b.    Configure the If Controller  as shown below

Here the Condition asks If Controller to execute the steps only if value of the variable is "Type 1". Similarly you can configure the 2^nd If Controller as shown below.

I will show how to use  the following controllers in my next post

• Include Controller
• Interleave Controller
• Loop Controller
• Module Controller
• Once Only Controller

Load Testing: Use of Assertion (Response and BeanShell) in JMeter

A common mistake in software development is we emphasize so much on functionality that we sometimes disregard the importance of performance of web applications. The end-result is the web application, in spite of having exciting features and fascinating UI, is turned down by client. Therefore, load testing is no more a secondary priority. I use JMeter, a very well-known open source tool, for load testing. Unlike Selenium, which is a functional testing tool, JMeter works at the HTTP requests and responses level. Therefore, when running a test in JMeter, we don’t see what’s happening in the browser. This is why assertions are very important to ensure that the test passes at every level and the browser is doing what it is supposed to do. Here are few examples of how to use assertions. I mostly use Response Assertion and BeanShell Assertions. I am going to show their usage here.

1.    Response Assertion: This is pretty simple yet very affective. And this is probably the most commonly used assertion.

Example 1: From Main Sample

Suppose you login to a site and upon successful login you are redirected to the home page. At this point of your load testing you want to ensure that the login was successful during load testing and the response to login HTTP request is the homepage. Consider the following example

Suppose “John Miller” is signing in to the site. And the welcome page greets him by his name. Now the assertion here would be to check if the text “John Miller” exists in the response of login HTTP request. You can do the following

Step 1: Identify the Login HTTP request. This would probably look like the following

Step 2: Add a Response Assertion as a child of this request a shown below.

i.                    Give it a name for better reference

ii.                  Select “Main sample only”

iii.                Select “Text Response”

iv.                 Select “Contains”

v.                   Use Add button to add one or more verification text

Step 3: Run the test. If things goes wrong you will see an error in “View Result Tree” listener as shown below

Example 2: From JMeter Variable

Consider the above example. Suppose you do not want to verify the homepage by the user name rather you want to verify by its title. Suppose title in home page looks like this

You can follow the following steps to accomplish this.

Step 1: Identify the Login HTTP request.

Step 2: Add a Post Processor Regular Expression Extractor as a child of this request. Add this before the response assertion as added in previous example.

 

Step 3: Change the response assertion as shown below

i.                     Select JMeter Variable

ii.                   Add the reference name of the variable added in previous step

iii.                  Provide the title

Step 4: Run Test.

2.   BeanShell Assertion: This is not as simple and straightforward as response assertion. But it offers more flexibility to add customized assertions. I personally use this quite often.

Example:

Consider the same example we used above. Suppose you have successfully logged in and you are visiting homepage. The homepage contains 4 meta-tags that you want to ensure are present every time a user visits the page.

(This is just an example to keep it simple. You may find a better usage in real life.)

Step 1: Add a BeanShell assertion as a child of the login HTTP request. And add the following code there

If you notice, it’s a simple java code that does the followings

i.        Get the entire response text

ii.      Looks for appearances of “<meta” text in the response text and counts the appearances

iii.    Finally fails the test if count does not match 4.

Step 2:  Run the test.

Of course, the above can be accomplished without using BeanShell assertion. However, this is an example of how flexible BeanShell assertions can be and how you can use it at your will.

Try this. There are other assertions as well. Once you get started, you may want to explore them as well. Thanks for reading.