Threads, http requests, assertions, listeners

This article is all about practice.

The most important components of a JMETER test plan are:

- thread groups

- samplers (requests)

- assertions

- config elements

- logic controllers

- listeners


There are lots of good info on each of them on the JMETER user manual.

I don't intend explaining what they do but how they can be used in a simple project.


The load test will cover one of the pages of the autotrader.ca website with the URL

http://wwwa.autotrader.ca/cars/on/toronto/?prx=100&prv=Ontario&loc=toronto&sts=New-Used&hprc=True&wcp=True

The page purpose is to display car ads that belong to sellers from Toronto and 100 kms around Toronto and have the status used or new.

The following load test plan is for educational purposes only and since it uses a live site, it will include a small number of concurrent users (maximum 5).


This is what the test plan will try to achieve:

- use a few concurrent users

- create a HTTP request for the page

        1. add delay after the HTTP request

        2. follow redirects for the HTTP request

        3. get embedded requests; filter embedded requests by the host name

        4. add a few assertions; apply them to the request, redirects and embedded requests


- display the load test results in a viewer

        1. view the request header

        2. view the response header

        3. view the response data

- save the load test results in a file

- parameterize the HTTP request by using variables for most of the parameters from the query string; read the values of the variables from a text file

- troubleshoot the load test results by writing request information to the log


VIDEO link

Please download the video on your computer if the quality is not good when viewing through the browser.


Browser request/server response, GET & POST requests

Some of the most important concepts in JMETER are 

- HTTP request
- request header
- response header
- response data

Before using them in a project, a few details for each is needed.

Browser Request - Server Response 

Most of the user interactions with a website through a browser results into a HTTP request sent to the web server.

Example:

     1. open the browser

     2. open a web page

     3. interact with the web page

     4. the page changes:

- a part of the page changes

- the page is reloaded

- a new page is loaded


Every time the page changes, the browser sends a HTTP request to the server.

The server generates the new page and sends the new page as a response to the browser.

The browser renders the new page for the user.










A HTTP request has the following template:







HTTP request types: GET and POST


Two commonly used HTTP methods are:

GET request   - Used for requesting data from the web server

POST request - Submits data to be processed to a web server


The GET Method

Query strings (name/value pairs) are sent in the URL of a GET request:

       GET /test/demo_form.asp?name1=value1&name2=value2

Characteristics of GET requests:

1. GET requests can be cached

2. GET requests remain in the browser history

3. GET requests can be bookmarked

4. GET requests should never be used when dealing with sensitive data

5. GET requests have length restrictions

6. GET requests should be used only to retrieve data






The POST Method

Query strings (name/value pairs) are sent in the HTTP message body of a POST request:

        POST /test/demo_form.asp HTTP/1.1
        Host: demo.com
        name1=value1&name2=value2

Characteristics of POST requests:

1. POST requests are never cached
 
2. POST requests do not remain in the browser history

3. POST requests cannot be bookmarked

4. POST requests have no restrictions on data length




BROWSER REQUEST


The following info is included in a browser request in the request header:

- request type: GET/POST

- protocol type and version (HTTP)

- URL: hostname + URI 

        http://wwwa.autotrader.ca/cars/bc/vancouver/?prv=BC&loc=vancouver&prx=100

request type = GET
protocol type = HTTP
port = 80
hostname = wwwa.autotrader.ca
URI = cars/bc/vancouver/?prv=BC&loc=vancouver&prx=100
        Query String = prv=BC&loc=vancouver&prx=100


- client:

accept: text/html, application /xhtml+xml, .....
accept encoding: gzip, deflate, .....
accept language: en-US, en
user agent: Mozilla/5.0, apple webkit, chrome, safari

        The user agent depends on the browser type and device type:
  1. FirefoxMozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
  2. Internet ExplorerMozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
  3. ChromeMozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko  Chrome/38.0.2125.104 Safari/537.36
  4. Nexus 7 tabletMozilla/5.0 (Linux; Android 4.3; Nexus 7 Build/JSS15Q) AppleWebKit/537.36 (KHTML, like Gecko)   Chrome/29.0.1547.72 Safari/537.36
  5. Iphone 6 smartphoneMozilla/5.0 (iPhone; CPU iPhone OS 8_0 like Mac OS X) AppleWebKit/600.1.3 (KHTML, like Gecko) Version/8.0 Mobile/12A4345d Safari/600.1.4


- cookies info

- transport:

connection info: keep alive
host name



WEB SERVER RESPONSE

The web server response has 2 parts:


Response Data

       Page content sent by the web server to the browser


Response Header

HTTP/1.1 200 OK

Server: nginx/1.1.19

Date: Wed, 22 Oct 2014 18:21:19 GMT

Content-Type: text/html;charset=utf-8

Cache-Control: max-age=0, private, must-revalidate

Set-Cookie: agency_id=BC-VANCOUVER; path=/

Set-Cookie: language=en-CA; path=/; expires=Tue, 22-Oct-2019 18:21:18 GMT

Set-Cookie: page_size=10; path=/; expires=Thu, 22-Oct-2015 18:21:18 GMT

Set-Cookie: SRV=app09; path=/; domain=.bibliocommons.com

Cache-control: private

Age: 1

Connection: close



PRACTICE BY YOURSELF



The easiest way of getting familiar with the concepts from this post is through a web proxy 
like FIDDLER 2.

You can download it from http://www.telerik.com/fiddler.

After downloading it, install the app and start it.

You will see in FIDDLER2 all web requests captured from all open browsers.

You can get access to lots of information about web requests in FIDDLER 2 in just a few 
minutes:

- requests embedded in the web page that corresponds to a web request (URL)






- request header





- response header and response data



JMETER introduction

JMETER is a tool that can used for load testing various types of applications:

  1. web sites
  2. database servers
  3. ftp servers
  4. web services
  5. other apps

It is an open source project born as an Apache project. 

The application is written in Java and can be run on Windows, Mac and Linux.

It has a multi-threaded architecture so that it can run requests on concurrent threads.

The interface is GUI based but it is not very user friendly because the app was created with the focus on technical functionality and not so much on user experience.


JMETER is not a browser since it  operates at the HTTP protocol level.

JMETER does not do the following:
  1. it does not open a browser (most of the time :); it is possible to run Web Driver scripts in JMETER but that's a different discussion))
  2. it does not perform actions supported by a browser
  3. it does not render html pages
  4. it does not execute JAVASCRIPT code embedded in html pages


Because it works at the HTTP protocol level, it simulates almost everything that a browser does because most of the browser actions generate HTTP requests.

It does not generate real users (like Web Driver) but virtual users.


JMETER works with requests (HTTP requests for web sites):

- a request is created in JMETER

- the request is sent to the server





- the server sends the request response back




- JMETER uses the request response by running different assertions






The requests can be sent directly from JMETER to the target system or a master - slave architecture can be used where:

- the master JMETER server creates the requests
- the master JMETER server sends the requests to the slave JMETER server
- the slave JMETER server sends the requests to the target server





Some of the functionality that make JMETER very different from other tools (Load Runner) are

  1. the plug-in interface: Java plug-ins can be added to Jmeter
  2. extensive API (lots of classes and methods that can be used in load test plans)
  3. can run Selenium Web Driver test scripts


The test plans can either be created manually from scratch or be started using the recording module. 

When using the recorder, the browser needs to be configured with JMETER acting as proxy so that all web requests executed in the browser are recorded.









The weak points of JMETER are the reporting and the lack of enterprise support.

There are multiple reporting components out of the box but they are not sophisticated enough.

Great reporting and enterprise features are available from Blazemeter which implements JMETER in the cloud.