Posted by
SmartBear
on
Thursday, September 15, 2011
Customer Guest Blog
Pradeep Bishnoi, Quality Analyst (API Test Automation), Thomson Reuters, Bangalore
A few days back, in one of my recent blog posts published on learnsoapui.wordpress.com, I shared the simplest way to perform load testing using the soapUI tool. I was happy performing the API load test using soapUI/loadUI until the day one of my colleagues asked me about my approach for performing these tests. I happily shared the information and in response he got me thinking by asking a very genuine question [and a flaw in the approach] about the approach being used to perform the load test.
"Are my tests parameterized? If not, then this is not the actual load test scenario since the DB is returning the data from the cache for each new request."
After this question, I realized that my approach to perform these API load tests is wrong :( so I started seriously thinking along the same lines and the answer to this problem was not far from my reach. ;-) Now you might have already started thinking, "What if I parameterize my request input and perform the load test instead of using a static request? Would this solve the problem?" Well not completely. How?
As you know, the web service request can be parameterized from xls, txt or any other source and the response would vary as per the input. I was using a simple TXT as the source with a script reading the input values, storing them as a custom property and passing the property value with each request run. Now having this approach, the only drawback is that when you perform the load test, the script will reach EOF (end of file) and the custom property will contain that (last value) as input value. Now this value would be passed as the input parameter for each request run during my load test and resulting in an INVALID load test scenario.
I have used profiler and HTTP data packet monitoring tools to verify the request data being sent from my local machine to Webserver and found it is sending the same request data multiple times during the load test.
How do you deal with this limitation/challenge with the soapUI tool? I searched a lot on the Internet, however with no success. Then I started analyzing the other load testing tools available in the market for performing such tests and found HP LoadRunner as one of the completive tools to achieve this.
Being a gigantic fan of open source tools like soapUI, loadUI and Groovy, I was not overly excited about introducing another load testing tool such as LoadRunner (another hefty licensed software). However, the feature it provided (randomly passing input parameter) was one that was attractive to me because by using that it was just matter of a few clicks to simulate actual load test scenario.
However, if I did introduce another load testing tool for the job, I would have to do a lot of extra stuff, and it was like an extra "load," in and of itself, such as if I created the new load test in LoadRunner, had to select individual request data and parameterize the input and provide a list of input values and so on.
This headache was avoided by using the existing soapUI tool, with an already created parameterized input request and an input TXT file.
As I have mentioned many times before (in my blog and to other people) you can do "wonders with Groovy" and "almost everything can be achieved with Groovy in soapUI." So going by those words, I wrote a couple of Groovy code lines to achieve what I was looking for - "Parameterized load testing".
The approach is no different from what "load runner" is actually using and also the way our parameterized test works. The only difference is, now it will randomly read an input value from the list (in my case a TXT file) and set it to custom property instead of reading in a sequence (which leads us to End Of File and resulting into static input data). Let everything remain the same - your parameterized test request, all test steps, and the file from where you read input values. And just add one new Groovy test step (in your testcase) and a new custom property “inputValue” at testcase level.
/*
@Author : Pradeep Bishnoi
@Description : Randomly read the input value from the input file. Each input value is entered in a new line. So, my file now contains 11 lines/input values.
*/
def myTestCase = context.testCase
File tempFile = new File("d:/my_Input_File.txt")
List lines = tempFile.readLines()
def x = Math.random()*10 // multiplying random with 10 so the resulting value would be <= 10.
i = String.valueOf(x).getAt(0)
i = i.toInteger()
myTestCase.setPropertyValue("inputValue", lines[i])
inputValue = context.expand( '${#TestCase#inputValue}' )
log.info inputValue
On running the load test each virtual user (thread) will also call this script teststep – because this teststep belongs to the same testcase (or group of my parameterized test steps). And with every run of this test step my custom property value would be updated resulting in request data with a different input value. This can be verified using a profiler or HTTP monitoring tool. Mission accomplished :) Leave your comments and thoughts and don’t forget to visit my blog at http:// learsoapui.wordpress.com. Till next blog - Happy reading and sharing!!
Snapshot for ready reference, how it will look after adding this Groovy teststep:
Note : In soapUI Pro you can use Data Source, etc. instead of scripting.