September 17, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Tuning and Testing Enterprise Web Services with SoapUI and JMeter

  • September 25, 2009
  • By Vlad Kofman
  • Send Email »
  • More Articles »

Building a Web-Service Test Plan in JMeter

First create a Thread Group element, this will tell JMeter the number of users you want to simulate and number of requests to send. Next, you need to modify the default properties. Select the Thread Group element in the tree.



Click here for larger image

Figure 3. Thread Group with Default Values

Next you need to add some web service requests. To do so add a new Sampler for Soap invocation You can also add a timer to put some delay into the invocation operation and some other controller to change the invocation flow. Finally, after configuring the Web Service Request you should add a Listener to see the result of the invocation.



Click here for larger image

Figure 4. Adding Sampler for WebService(SOAP) Request invocation

Enter name for the endpoint, and a valid WSDL location. If the WSDL file was loaded correctly, the "Web Methods" drop down will be populated. Next, select the web method and click "Configure". The sampler should populate the "URL" and "SOAPAction" text fields. Assuming the WSDL is valid, the correct soap action should be entered. If you already have sample Soap Request you can enter it in the Soap Data field, or use a message folder. The sampler will randomly select files from a given folder and use the text for the soap message. This is what I'm using in this example.

A big difference from the SoapUI here is that you should have SOAP requests already to be supplied to JMeter, where as in SoapUI you can generate them.



Click here for larger image

Figure 5. Configuring WebService(SOAP) Sampler

Now you can invoke the test case, but you will not see any results, to see the results you need to add a final element - Listener. (Add --> Listener --> ).

For this article I chose a Graphical Listener, but you may use any one of the default listeners provided. They will all work with the same response data, just display or analyze it differently.

Note: If you do not want JMeter to read the response from the SOAP Webservice, uncheck "Read Soap Responses." If the test plan is intended to stress test a webservice, the box should be unchecked. When "Read Soap Responses" is unchecked, no result will be displayed in view result tree or view results in table.



Click here for larger image

Figure 6. Graph Results Listener

Building a Web-Service Test Plan with SoapUI

The learning curve of SoapUI is shorter then the JMeter, mostly because SoapUI automates a lot of tasks related to the creation of the Web services test plans. SoapUI lets you auto generate test cases by discovering the operations and required (and optional) elements that are available on the web service request endpoint. The first step is to create a new Project (Ctrl+N) ) and set up some endpoint information. This is fairly simple, and after you provide a valid WSDL location, SoapUI should show you the list of all available operations on that endpoint (see figure 8)



Click here for larger image

Figure 7: setup of new project in SoapUI


Figure 8: Auto discovered operations on the SOAP web service in SoapUI

SoapUI can pre-generate all the requests for you as well, or let you generate only requests without optional parameters. You can then fill in the values that you need.

Note: A good idea is to save your project after you set up all the values, as SoapUI only saves on exit, and if something crashes you may loose your work.



Click here for larger image

Figure 9: Auto discovered operations on the SOAP web service in SoapUI

After the tool generated the required message, you can start generating Test Plans, or as SoapUI calls them - TestSuites.

You need to right click on the endpoint and choose generate TestSuites. After that the tool will generate Load Test for each operation, and you can drag them to group into one Test Step to run as a single load test.


Figure 10: Auto discovered operations on the SOAP web service in SoapUI

From the Load Test UI, you can choose the duration of the test and from seven different load strategies. Such as Simple or Burst invocation of the services from the simulated multi-users. The tool comes with these out of the box:

Simple: TestCase execution with a configurable delay
Variance: TestCase execution varying the number of threads over time
Burst: TestCase execution in "bursts"
Thread: TestCase execution with a fixed thread count modification
Grid: Defines a custom variation of thread count (soapUI Pro only)
Script: Lets a groovy script control the number of threads (soapUI Pro only)
Fixed-Rate: Execute a TestCase at a fixed rate (soapUI Pro only)

All strategies have a thread-count allowing the specification of how many TestCases should be run in parallel. Some strategies also allow interactive changing of the thread count while executing the LoadTest.



Click here for larger image

Figure 11: Auto discovered operations on the SOAP web service in SoapUI

You will see the results (ex. response duration) of the test case in the same window, but you can also graph the results or save them to a file.

Conclusion

In this article I have discussed two tools for SOAP web services testing and tuning. Both tools are very powerful and offer similar functionalities such as load testing, multi-user simulation and various tuning options. As a tool, JMeter is a more versatile then the SoapUI, because it allows for extendibility and testing of other technologies besides web services, but it is harder to use and requires more time to learn. Both tools have excellent documentation online and big user communities. In terms of pure web services testing, both tools have pros and cons. For instance you need to have SOAP requests in JMeter, but SoapUI can generate them for you.

I should also mention that if you need to send hundreds of different requests to the same operation with different data it is cumbersome in both tools as there is no easy way to add hundreds of different request values. In SoapUI you need to tweak XML project file itself and in JMeter you need to create hundreds of different request files. Overall the tools are very helpful in stress testing web services and in tuning server performance. If you like the all GUI approach and shorter learning curve you may choose SoapUI, but if you like more flexibility and raw power, you may choose JMeter.

References

SoapUI
JMeter
Java Activation Framework - needed for JavaMail
Java Mail - needed for Mail Visualiser, Mail Reader and WebService(SOAP) sampler

About the Author

Vlad Kofman is working on the enterprise-scale projects for the major Wall Street firms. He has also worked on the defense contracts for the U.S. government. His main interests are web related programming methodologies, UI patterns and SOA.


Tags: Web services



Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel