API Regression Testing Process
API Regression Testing Process
Apache JMeter is a 100% pure Java desktop application designed to load test client/server
software (such as a web application). It may be used to test performance both on static and
dynamic resources.
It Help us to do the regression testing. It helps to validate the expected values.
Here is the Following link to download the Apache Jmeter.
Link: http://jmeter.apache.org/usermanual/get-started.html
As you know the apache JMeter is also used for testing the load on the server.
Pre-requisites:
Elements of JMeter:
After Downloading the Zip file unzip the folder.
TAG TEAM
Apache-jmeter-2.10>bin>ApacheJMeter.jar
The main objective of API testing
Verifying and validating the output in different system is little difficult for testers
TEST PLAN:
All the work flow will be under Test Plan directory
Thread Group:
The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread
Group tells JMeter the number of users you want to simulate, how often the users should send requests,
and the how many requests they should send.
TAG TEAM
Thread Group GUI, you can control the number of users simulated (num of threads), the ramp up time
(how long it takes to start all the threads), the number of times to perform the test, and optionally, a
start and stop time for the test.
HTTP Request:
If you need to test dozens of http urls, then instead of adding the web servers hostname or proxy details
etc in all HTTP Request Samplers, you can put these in The Config Element HTTP Request Defaults. This
will avoid repetition of data and also make the config manageable. Let's see an HTTP Config Element in
action
Config Element is a convenience element where you can store the common configuration values of all
samplers like web servers hostname or database url etc.
If your API needs Headers then we can configure those headers in JMeter for that we need to add config
element Http Header Manager. To add Http Header Manager config element to our Thread group, right
click on thread group go to Add > Config Element > Http Header Manager. As shown in below screen
shot.
TAG TEAM
In the Header manager page we can create Dynamic values which are used in over all application
TAG TEAM
After Executing the samplers ctrl+R for clearing pervious Results in the Results Tree Ctrl+E.
The Hot coded Value will be generated in response Data. Here its in Json.
TAG TEAM
I have taken only two variables username and password in same sequence.
If you want to use more than set config element in your thread group then it is possible but you need to
make sure that the variable names should not repeat in your thread group.
Now to access the variable in your Http Request, you can simply access these variable using syntax: $
{Variable_Name}.
TAG TEAM
TAG TEAM
Server Name or IP: Here we have to type the web server name. In our case it is www.example.com
Path: We will type path as / (slash). This means we want the root page of the server.
Path: //jmetertest/api/login.do
Listeners:
Listeners are the elements where you actually see the results of your test. There are various listeners
available with JMeter. But for API we actually need View Result Tree Listener, Graph Result, Aggregate
Graph, Aggregate Result. To add listener right click on thread group go to Add > Listener
1. View Result Tree Listener
If you are interested to see the input provided and output of each request sent to server then View Result
In Tree Listener is best.
Have a look at View Result In Tree Window. In left side of window you will see the APIs executed if they are
in green color then API executed successfully and if they are in red color then API execution had some
problem, you can see the reason in the right frame of window.
In Sampler result tab you can see all the details of http response by server. In Request tab you can see
http url hit and data posted with the request, and in response tab you can see the response data of
request. All these are shown in below screen shots.
TAG TEAM
Here in the sampler result we can actually verify the response code
Status codes:
1XX- Indicates informational messages only.
2XX- Indicates Success of some Kind.
3XX-Redirects the client to another URL.
4XX-Indicates an error on the client side.
5XX-Indicates an error on the Server Side.
TAG TEAM
In the Request tab we can verify the actual payload and request headers.
TAG TEAM
Some test plans need to use different values for different users/threads.
For example, you might want to test a sequence that requires a unique
login for each user. This is easy to achieve with the facilities provided
by JMeter.
For example: site name is used throughout the application, so we can create a
variable fpr the same.
Path to create: Test Plan>Add>Config element>User defined varaialble.
TAG TEAM
TAG TEAM
In the above figure a variable called CONTEXT_ROOT had created and its value is
given as symphony.
If you observe form the above picture, symphony is replaced with ${CONTEXT_ROOT}
.
Reference: http://community.blazemeter.com/knowledgebase/articles/65146-using-userdefined-variables-in-jmeter-2-6
Logic Controllers:
JMeter gives us far more control on our test plan through test elements called Logic Controllers.
TAG TEAM
Assertions:
Assertions are nothing but responses that we received from the server while
testing. Generally we use Response Assertion. Some of the assertions that we
regularly use are given below:
200 - Success
TAG TEAM
Timer
By default, a JMeter thread sends requests without pausing between each
request. We recommend that you specify a delay by adding one of the available
timers to your Thread Group. If you do not add a delay, JMeter could overwhelm
your server by making too many requests in a very short amount of time.
The timer will cause JMeter to delay a certain amount of time before each
sampler which is in its scope .
If you choose to add more than one timer to a Thread Group, JMeter takes the
sum of the timers and pauses for that amount of time before executing the
samplers to which the timers apply. Timers can be added as children of samplers
or controllers in order to restrict the samplers to which they are applied.
To provide a pause at a single place in a test plan, one can use the Test
Action Sampler.
Timers are processed before each sampler in the scope in which they are found.
TAG TEAM
To apply a timer to a single sampler, add the timer as a child element of the
sampler. The timer will be applied before the sampler is executed. To apply a
timer after a sampler, either add it to the next sampler, or add it as the child of
aTest Action Sampler.
There are different timers available
Constant Timer
Gaussian Random Timer
Uniform Random Timer
Constant Throughput Timer
Synchronizing Timer
BeanShell Timer
BSF Timer
JSR223 Timer
Poisson Random Timer
Please find the below given example which is configured for 2000 milliseconds
Configuration element
A configuration element works closely with a Sampler. Although it does not send
requests (except for HTTP(S) Test Script Recorder ), it can add to or modify
requests.
TAG TEAM
A configuration element is accessible from only inside the tree branch where you
place the element. For example, if you place an HTTP Cookie Manager inside a
Simple Logic Controller, the Cookie Manager will only be accessible to HTTP
Request Controllers you place inside the Simple Logic Controller (see the below
figure). The Cookie Manager is accessible to the HTTP requests "Web Page 1"
and "Web Page 2", but not "Web Page 3".
Also, a configuration element inside a tree branch has higher precedence than
the same element in a "parent" branch. For example, we defined two HTTP
Request Defaults elements, "Web Defaults 1" and "Web Defaults 2". Since we
placed "Web Defaults 1" inside a Loop Controller, only "Web Page 2" can access
it. The other HTTP requests will use "Web Defaults 2", since we placed it in the
Thread Group (the "parent" of all other branches).
Please go through the following data regarding API testing and with respective response
codes:
CRUD:
Request methods map to the basic CRUD operations. They are as follows:
1 Create => POST
2 Read => GET
3 Update => PUT
4 Delete => DELETE
JSON Format & Style:
TAG TEAM
OK
20
1
Created
20
4
No Content
40
0
Bad Request
TAG TEAM
Unauthorized
40
3
Forbidden
40
4
Not Found
40
5
Method Not
Allowed
40
9
Conflict
41
0
Gone
41
5
Unsupported
Media Type
42
2
Unprocessable
Entity
50
0
Internal Server
Error
The API Test scenarios should be written as shown below where it is easier to
understand
TAG TEAM
For example:
Server IP api.qa.tagcmd.com
Endpoint: /mailservices/mail/sendmail
Method: POST
---------------------------------------------------------------------------------------------------------Mail Services to support both xml and JSON (mention title of the scenario)
---------------------------------------------------------------------------------------------------------Test Scenario_01:
Request the url for the 'POST' method with valid payload
Verify that, proper Response code-201 and Response Message: Created is received
----------------------------------------------------------------------------------------------------------