Wednesday 15 February 2017

JMeter Logic Controllers

In our previous JMeter post, we have learned how to reuse and maintain our scripts. So far we have learned enough to create a simple performance scripts for any application but what about the control over the requests and order of execution of requests. Logic Controllers provide the feature to do that.

As we have already learned how to create performance scripts in our previous post (Creating first JMeter script), now we will directly see how to add logic controller and their use.

Follow the steps to add logic controllers:

Test Plan >> Thread Group >> Add >> Logic Controller















You can see there are multiple types of logic controllers available in JMeter. 

Simple Controller: This controller just provides the storage for samplers and other logic controllers and this controller has no extra functionality except storage.












In the above image you can see how simple controller is being used to separate the different transactions; it makes the performance scripts much understandable and manageable.

Loop Controller: This controller allows JMeter to iterate any sampler or controller added to loop controller to a certain number of times.











You can set the Loop Count as Forever or number. There is a loop count field in Thread Group as well but it behaves slightly different. Unless set to Forever, it stops the test after the number of iterations have been done.

Once Only Controller: This controller tells JMeter to execute only once. All the controllers inside the once only controller will execute only once for all the threads. It is helpful when you need to run your scripts for a fixed duration and you don’t want to repeat the login transaction again and again. You can simply put the login transaction under the Once only controller and the controller will take care of it (It will only execute once for each thread). See the below image which is showing how to use a login transaction controller inside a Once Only Controller:














Throughput Controller: The Throughput controller allows the user to control how often it is executed. There are two modes to control the execution:

1. Percent Execution: Percent execution causes the controller to execute a certain percentage of the iteration throughout the test plan. User can define the percentage in test plan user defined variable area and use those variables in throughput controller.

2. Total Execution: Total execution causes the controller to execute it for a certain number of iterations. It will stop just after the defined numbers of executions are done.










See the above image in which a transaction is kept under Throughput Controller and execution mode is set to Percent Execution with a value of 40. It tells JMeter to execute this particular transaction 40% of the total test plan.


Runtime Controller: The runtime controller controls how long its children are allowed to run. Just enter the time in seconds to which elements of the controller will execute.













If Controller: The ‘If controller’ allows the user to control whether the test elements below it will run or not.









Here in the above image you can see the condition field, in which the value of count variable will be evaluated and decision will be made. If the condition returns true, it will execute the inside part of If block else will exit the If block.

Module Controller: As the name is self-explanatory, it provides modularity to the JMeter. It provides mechanism for substituting the test plan fragments into the current test plan at run-time. The module controller then can be used to switch between multiple test cases simply by choosing the appropriate controller from the tree. This provides executing many alternate test plans quickly and easily.


























As you can see in the above screenshot that module controller shows the complete test plan except the module controllers. Now you can easily select the desired controller to execute. For example: Login and Logout actions are selected respectively.

This controller is very helpful in case you have to test different scenarios, you can quickly and easily select the alternate test cases and execute.

All of these controllers are most commonly used controllers.

Please like or comment if you liked the post. Stay tuned to see more posts.


Friday 22 July 2016

Reuse and Maintain JMeter Scripts

So far, we have seen some important components of JMeter which are required to start with the performance script creation. But, just recording the actions and generating the script will not solve the purpose of creating a robust and reliable performance script. We would need to analyze all the dynamic values which may change in each fresh session of the application. So in order to maintain the consistency in each and every execution of the scripts, we need to get our hands dirty. Following are the few things we should do; whenever we plan to use the recorded scripts for future use:

Follow the previous post “Creating First JMeter Script” for recording of the scripts

After recording the scripts we have something like the below image:

















In the above image you can see that I have highlighted the ‘HTTP Header Manager’ inside a request. This node will be added by default in each and every recoded request. So, your first step will be removing all these ‘HTTP Header Manager’. After removing this node, we will add three new components under the Thread node. You can see the highlighted components at the bottom of the tree.

>> HTTP Request Defaults
>> HTTP Cookie Manager
>> HTTP Cache Manager

We will discuss each of these components in detail, but before that see the changes done in Test Plan:















See the highlighted area in the above image, which is showing the added user variables. All these added variables in the Test Plan can be used as global variable for the complete suite.

Now, come back to the added components. 

HTTP Request Defaults: This element lets you set default values that your HTTP Request controllers use. This makes life too easier, if your all request are going to the same server. You could add a single HTTP Request Defaults with the ‘Server Name or IP’ field filled in, instead of using same detail for every request. Now, see the details filled in below image of HTTP Request Defaults:















Notice all the highlighted fields in the HTTP Request Defaults area, all of these are defined in the Test Plan as user variables. Using this technique will help you in maintaining your scripts. You will have to change it all only at one place, hence saving your time and effort.

HTTP Cookie Manager: It stores and sends cookies just like a web browser. If you have a HTTP Request and the response contains cookie, the cookie manager automatically stores that and will use it for all future request to that particular web site. Select ‘Clear cookies each iteration’ checkbox, it will clear all server-defined cookies each time the main Thread Group loop is executed. By default ‘Hc3CookieHandler’ is selected, If you have a web site to test with IPv6 address, choose ‘HC4CookieHandler’.












HTTP Cache Manager: While preparing for performance testing of any web application, we try to mimic exactly the same environment as in the real world. For the best and near to actual performance data, it is very important to consider as many things we can. As we know that every browser has some mechanism that reduces the traffic over the internet/network and Cache is one of them. A cache is just like a repository, which stores data and used to expedite the process of retrieving the data. HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope to simulate the browser caching feature. Select the ‘Clear cache each iteration’ checkbox. You can also set the number of elements stored in cache, by default it is 5000.











Till now, we have discussed only the configuration part of this suite; which is mostly the one time task. Now we will see the actual scripts and the changes need to be done, so that those scripts could be used as many times we want without any major changes. So let’s do it.

Following images in sequence will show a simple example of how to extract some data at runtime and use in subsequent requests.

In the below image the ‘Add to cart’ is a POST request with some data being sent to the server. See the highlighted ‘token’ field in parameters section where a hexadecimal value is being used and that might change every time client request the server. So in order to find the token value from the active session of the web site; we need to extract the data at run time. But before that, we need to identify the request from where we can get this value.















In this particular example, I have found that value in Launch request. See the highlighted area in below image where that value is in the response body of the Launch request.















We found the location from where we have to extract the value at runtime. But the question is how to do that? The answer is ‘Regular Expression Extractor’. To add a regular expression extractor, follow the steps mentioned below:

Do a right-click on the desired component and follow the displayed image.
















Once Regular Expression Extractor added to the node, we need to write regular expression syntax to extract the desired value from it. See the below image, how regular expression is being used to extract the token value from the response body of the Launch request.
















Notice the highlighted group of fields and specifically the ‘Regular Expression’ field. I have written regular expression syntax to fetch the token value from the Launch request. There are other fields as well which we will discuss in detail in a separate post. To use the extracted value we have a reference name in here, let’s see the below image:









See the difference here, ${staticToken} has been used to assign the extracted value to the parameter token.

Now our suite is ready to execute as many times you need to. This is a simple example for ‘How to make your scripts reusable’. Further we will discuss many more components which will be required/would help to make performance test scripts reusable, robust and reliable.


Please like and comment if you liked the post. Stay tuned to see more posts.



Friday 27 May 2016

Creating First JMeter Script


In our previous and third post of JMeter, we have discussed about two main component required for creating a JMeter script. Follow the previous post first, if you are new to JMeter and have not seen that post.

So now I can hope that you have setup the JMeter on your machine to start with this session.

There are two default components you will see, when you will start the JMeter:

  1. Test Plan, and
  2. WorkBench

Test Plan describes the series of steps JMeter will execute when run whereas Work Bench is a temporary space provided to store test elements not in use, for copy/paste option or any other purposes you desire. While saving the test plan, workbench elements are not saved with it until you select the ‘Save Workbench’ option.

To start with creating your first JMeter script, follow the following steps:

  1. Add a ‘Thread Group’ to the ‘Test Plan’
  2. Now add ‘HTTP(S) Test Script Recorder’ to the ‘WorkBench’
  3. Set the browser and ‘HTTP(S) Test Script Recorder’ to one free port
  4. Also select the ‘Target Controller’ before starting the ‘HTTP(S) Test Script Recorder’
  5. Now perform the user actions and all the requests will be recorded under the selected target controller

See the following screenshot for better understanding:















You can see that I have selected ‘CrazzyGig Thread Group’ in the ‘Target Controller’, so all the recorded requests will be saved under the ‘CrazzyGig Thread Group’. 

This is just the simple recording of the steps performed by the user, In next we see the script recording in more detail that way we can reuse the same scripts without any modification in scripts.

Please like and comment if you liked the post.  Stay tuned to see more posts.



Thursday 12 May 2016

Thread Group and HTTP(S) Test Script Recorder

In the next post we will see how to create JMeter Script, but I thought; it would be good to explain the ‘Thread Group’ and ‘HTTP(S) Test Script Recorder’ first. In order to create a script; you will need to add these two components. So, let’s begin with it.

Thread Group

Open JMeter, you will see the following screen:


Now, right click on ‘Test Plan’ and add a Thread Group.  Follow the flow to add the same: “Add >> Threads (Users) >> Thread Group”


Following are the components of the Thread Group:


  • Name: Name of the thread group, which user can set as desired.
  • Comments: Comments related to the thread group. Comments can help any new user to understand the work designed to perform by thread group.
  • Action to be taken after a sampler error: Option given under section will execute based on the user selection, in case any sampler error occurs.
          Continue - ignore the error and continue with the test
          Start Next Loop - ignore the error, start next loop and continue with the test
          Stop Thread - current thread exits
          Stop Test - the entire test is stopped at the end of any current samples.
          Stop Test Now - the entire test is stopped abruptly. Any current samplers are interrupted if                   possible.
  • Number of Threads (users): This parameter defines the number of virtual users you want to test on the application.
  • Ramp-up period (in seconds): This parameter defines the duration in which the user will be ramped up until the total numbers of VUs are up and running.
  • Loop Count: This parameter defines the number of iteration you need to run. There is a ‘Forever’ checkbox which can be ticked to run it infinitely.
  • Delay Thread creation until needed: If selected, threads are created only when the appropriate proportion of the ramp-up time has elapsed.
  • Scheduler: This parameter is used to enable the scheduler. It provide the start time, end time, total duration for which test should run and startup delay; which can be used to delay the startup defined in start time parameter.


HTTP(S) Test Script Recorder

HTTP(S) Test Script Recorder allows JMeter to intercept and record all your actions while you browse your web application on your browser. JMeter creates test sample objects and store them directly into selected target controller.

To add the HTTP(S) Test Script Recorder follow the steps mentioned below:

Add the http(s) recorder into workbench. Do right click on workbench and add ‘HTTP(S) Test Script Recorder’. Follow the flow, Add >> Not-Test Element >> HTTP(S) Test Script Recorder






After adding the HTTP(S) recorder:


There are few important attributes of HTTP(S) recorder, which a user should know about before creating the performance script. Following are the mandatory attributes which will be required to set before recording:

Under ‘Global Settings’ one can see the ‘port’ attribute. Actually recorder is implemented as HTTP(S) proxy server. You need to set up your browser and tool on the same port. 8080 is the default port, you can change it.

Under ‘Test plan content’, there is an attribute called ‘Target Controller’. It defines the controller where the recorder will place the generated samples.

Now we are good to start recording, leave other attributes as it is. To start the recording, start the recorder by clicking the start button at the bottom.

You will see a certificate prompt like:


Click ok and start recording.

Stay tuned to see more updates on JMeter.


Thursday 3 December 2015

Configuring JMeter

As we already discussed in previous and first post of JMeter is that JMeter is 100% pure Java application, hence it is required to have installed JVM on your system.

Following are the minimum requirement before you try to run JMeter :

Java Environment
  • Minimum Java Version 1.6 or higher is best. Follow the instructions on Oracle's official website to see how to set the JAVA_HOME environmental variable.
Operating System
  • Any operating system which has Java compliant implementation should be able to run JMeter without any problem.
Running JMeter
  • Once the JVM is set and running, download the JMeter release or nightly build and unzip in local drive.
  • If you are running JMeter on Windows. Go to JMeter's unzipped directory and navigate to bin directory and run jmeter.bat file.
  • If you are running JMeter on Linux/Unix system. Go to JMeter's unzipped directory and navigate to bin directory and run jmeter.sh file using terminal.
  • If you are running JMeter on Mac. Go to JMeter's unzipped directory and navigate to bin directory and run jmeter.sh file using terminal.
 JMeter UI
This is the view of JMeter you will see after launching it:
 












Stay tuned to see more updates on JMeter.

Facebook Page : https://www.facebook.com/crazzzygig 

References : http://jmeter.apache.org/

Saturday 28 November 2015

Introduction To JMeter

JMeter is an open source software by Apache Software Foundation, a 100% pure Java application designed to measure performance. Initially it was designed to test Web Application but later expanded to test other test functions.

The protocols supported by JMeter are:
  • Web – HTTP, HTTPS.
  • SOAP / REST
  • FTP
  • Database via JDBC
  • LDAP
  • Message-oriented middleware (MOM) via JMS
  • Mail – SMTP(S), POP3(S) and IMAP(S)
  • MongoDB (NoSQL)
  • Native Command or Shell Scripts
  • TCP

Following are the features of JMeter:
  • As it is open source software, it is available for free.
  • JMeter is a platform-independent software. On Windows it can be invoked by starting the jmeter.bat file and on Linux it cab be invoked by clicking the JMeter shell script.
  • JMeter stores its test plans in XML format.
  • JMeter is a multi-threading framework allows concurrent sampling by many threads and simultaneous sampling of different functions by separate threads group(Users).
  • JMeter can also be used to test automated and functional testing of the application.

Following are the terms you will encounter frequently while using JMeter:
  • Test Plan – A test plan describes a series of steps JMeter will execute when run. A test plan can consist of one or more Thread Groups, Controllers, Samplers, Listeners, Timers, Assertions and Configuration elements.
  • Thread Group – Thread Groups is a collection of groups.Basically each thread represents one user running against the Application Under Test(AUT). It is the starting point under the test plan.
  • Samplers – Samplers are the way to send all types of requests to server supported by JMeter.
  • Controllers – Controllers allows you to control when to send a user request to a server. There are various type of controllers such as logic controller etc., we will discuss those in detail in later posts.
  • Listeners – Listeners are nothing but way to show the results of samplers in form of tables, graphs, trees or in simple text format.
  • Timers – While sending requests JMeter thread sends request without any pause between each sampler. Timers allows you to define a period to wait between each request.
  • Assertions – As it is self defined word provides the capability to include some validation on the response of the request sent. By using different assertions we can assure that sent request is returning correct or expected data.
  • Configuration Elements – There are various configuration elements in JMeter, it works very closely with samplers and can only be accessed inside the three branch where it is placed. It allows to create defaults and variables to be used by samplers.
Stay tuned to see more updates on JMeter.



References: http://jmeter.apache.org/

Sunday 16 August 2015

TestNG-XSLT Report Using Maven


An effective communication is the key to success. The knowledge and skills you acquire are of no use to others if it is not conveyed well. You will have to be able to gather information, organize it, and present it in a logical and concise form to convey the exact meaning you intend.

In the same way Reporting is the most important and critical part of any automated test execution, as it helps users and stakeholders to understand the exact result of the execution, reasons for the failures and also helps to determine the next steps.

As we have already seen TestNG default report in previous post (TestNg Link), so in this post we will focus on how to make reporting more presentable using XSLT. XSLT or Extensible Stylesheet Language Transformations is a language for transforming XML documents into other XML or other formats. It is intended to perform complex styling operations, like generation of tables of contents and indexes.

In this post we will see how to implement XSLT report using TestNG and Maven. Following are the tools being used for this post:

Maven: A Build Management Tool

TestNG: A Test Automation Framework

Selenium WebDriver: A Web Test Automation Tool

Setup all these tools in choice of your IDE; in this post we are using Eclipse IDE. Now, create a maven project and open the auto-generated pom.xml. Edit your pom.xml as written below:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
       
       <modelVersion>4.0.0</modelVersion>

       <groupId>com.blogger</groupId>
       <artifactId>xsltreport</artifactId>
       <version>0.0.1-SNAPSHOT</version>
       <packaging>jar</packaging>

       <name>xsltreport</name>
       <url>http://maven.apache.org</url>

       <properties>
              <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       </properties>

       <dependencies>
              <dependency>
                     <groupId>org.seleniumhq.selenium</groupId>
                     <artifactId>selenium-java</artifactId>
                     <version>2.45.0</version>
              </dependency>


              <dependency>
                     <groupId>org.testng</groupId>
                     <artifactId>testng</artifactId>
                     <version>6.8.21</version>
              </dependency>

       </dependencies>

       <build>
              <sourceDirectory>src/test/java</sourceDirectory>
              <plugins>
                     <plugin>
                           <groupId>org.apache.maven.plugins</groupId>
                           <artifactId>maven-surefire-plugin</artifactId>
                           <version>2.14.1</version>
                           <configuration>
                                  <testFailureIgnore>true</testFailureIgnore>
                                  <skipTests>false</skipTests>
                                  <suiteXmlFiles>
                                         <suiteXmlFile>testng.xml</suiteXmlFile>
                                  </suiteXmlFiles>
                           </configuration>
                     </plugin>
                     <plugin>
                           <artifactId>maven-compiler-plugin</artifactId>
                           <configuration>
                                  <encoding>iso-8859-1</encoding>
                                  <source>1.6</source>
                                  <target>1.6</target>
                           </configuration>
                     </plugin>
              </plugins>
       </build>

       <reporting>
              <plugins>
                     <!-- TestNG-xslt related configuration. -->
                     <plugin>
                           <groupId>org.reportyng</groupId>
                           <artifactId>reporty-ng</artifactId>
                           <version>1.2</version>
                           <configuration>
                                  <!-- Output directory for the testng xslt report -->
                                  <outputDir>/target/testng-xslt-report</outputDir>
                                  <sortTestCaseLinks>true</sortTestCaseLinks>
                                                        <testDetailsFilter>FAIL,SKIP,PASS,CONF,BY_CLASS</testDetailsFilter>
                                  <showRuntimeTotals>true</showRuntimeTotals>
                           </configuration>
                     </plugin>
              </plugins>
       </reporting>

       <pluginRepositories>
              <pluginRepository>
                     <id>reporty-ng</id>
                     <url>https://github.com/cosminaru/reporty-      ng/raw/master/dist/maven</url>
              </pluginRepository>
       </pluginRepositories>

</project>

In the above pom.xml we have added following components:

Selenium and TestNG Maven dependencies

build block containing Surefire plugin and maven-compiler plugin.

reporting block containing configuration of Testng-XSLT report.

pluginrepository block containing location of the reporty-ng.

Now we are done with the pom.xml configurations and it’s time to move further. Following the structure of the project created for this post:



As you can see we have two test classes along with three more xml files except pom.xml. In which testng.xml is being used to define the suite files and suiteA.xml and suiteB.xml are separate files for each test classes. We have separated these two test classes in different xml files just to show how the report will look like when we have multiple test suites.

suiteA.xml








suiteB.xml











testng.xml













Now we are ready to execute to the test and generate TestNG-XSLT report. To execute the test we will use maven command.

Navigate to workspace directory where pom.xml is present and run the following command:

mvn clean test -fae site org.reportyng:reporty-ng:1.2:reporting

After successful completion of the execution you will see BUILD SUCCESS information on command prompt.










Now go through the reporting block of pom.xml and see the mentioned path for XSLT report. In our case it is: <outputDir>/target/testng-xslt-report</outputDir>


Navigate to the mentioned directory and you will see the index.html file.

Index.html


















In this view you can see complete summary of passed, failed and skipped tests. The pie chart shows the percentage of all passed, failed and skipped tests. With this view a user can easily understand the status of the build and can decide the further steps to take.

For detailed status of the different suites, click on each of the link from the sidebar.

In sanity suite all the test cases have been passed.












In Regression suite one test failed, one passed and one skipped.











Please like and comment if you liked the post.  Stay tuned to see more posts.