Introduction

In this article, I will talk about two test tools for the enterprise web services tuning and testing. These tools can be used to test performance, simulate heavy loads, test functional behavior, monitor servers, as well as find problems and troubleshoot issues with the servers by simulating client requests. Both tools are written in Java. They are free and open source.

The first tool Apache JMeter, is very powerful and has a very generic pluggable architecture which can be used to test a lot of technologies besides web services, such as Java Servlets, CGI scripts, Java objects, FTP servers , JMS, Databases, etc. But for the purposes of this article I'll concentrate on the Web (SOAP) Web services testing aspect of the tool. The second tool, SoapUI is now fully mature and stable tool designed primarily for testing web services. It is also open source, but has a pro (paid) version as well. Both tools are very popular and I'll cover some of the best features on both.

I should also mention that both tools are designed for tuning and testing SOAP based web services, which means they document literal requests that can be sent to the server in the form of XML, and schema or canonicals which needs to be already defined.

Install and Setup

Installation of both tools is very straight forward, but JMeter requires an additional step due the fact that it uses Apache SOAP for service invocation, and that package needs mail.jar and activation.jarwhich are not supplied with the JMeter installation.

Since both tools are Java based you will also need JRE to be installed on the system as well. SoapUI comes with the installation package for various operating systems and is self contained.

JMeter comes as an archive for different operating systems. Download and extract the latest JMeter, separately download and place mail.jar and activation.jar into the JMeter lib folder.

You can also set up environment variables for JMeter, which the program will use if its started from the command line without GUI mode.

  • JMETER_HOME/lib - used for utility jars
  • JMETER_HOME/lib/ext - used for JMeter components and add-ons

To run SoapUI launch the executable from the windows shortcut (ex bin/soapUI-3.0.1.exe)

To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file also in the bin directory.



Click here for larger p_w_picpath
The SoapUI

JMeter

JMeter was originally developed by Stefano Mazzocchi of the Apache Software Foundation. He wrote it primarily to test the performance of Apache JServ (a project that has since been replaced by the Apache Tomcat project). Since then the tool was enhanced with a more robust GUI and redesigned to add functional-testing capabilities.

Out of the box JMeter can currently test: Web - HTTP, HTTPS, SOAP based Web services, Databases via JDBC, LDAP, JMS and Mail - POP3(S) and IMAP(S) interfaces, and can be extended to test other technologies as well. It is sort of a Swiss army knife of application testing, and it is indeed a very robust and flexible tool. Note, if you want to do JDBC testing, you will need to add your database vendor's JDBC driver to the JMeter's classpath.

Setting up test case in JMeter is more involving then in the SoapUI, and I can say that the learning curve with the application is overall higher than with other tools, but thankfully there is a very good documentation online and once you learn the tool, you will appreciate its flexibility.

The first step in making Web services test case, is to set up a test plan, which is a series of steps JMeter will execute when run. A complete test plan will consist of one or more Thread Groups, logic controllers, sample generating controllers, listeners, timers, assertions, and configuration elements. Out of the box, JMeter comes with the sample comptrollers for FTP, HTTP, JDBC, Java object, LDAP, SOAP/XML-RPC Requests and WebService (SOAP) Requests. This means that there is GUI which you can configure to run the test case.



Click here for larger p_w_picpath
Figure 2: Example of the test case for different operations on one SOAP service end point.

A web server HTTP test case plan can be something like this:

  • Test Plan
    • Thread Group
      • Interleave Controller
        • Some Operation (HTTP Sampler)
        • HTTP default request (Configuration Element)

You should add listeners in your Test Plan in JMeter. Listeners provide access to the information JMeter gathers about the test cases while it runs. For instance, the Graph Results listener plots the response times on a graph, or the "View Results Tree" Listener shows details of sampler requests and responses, and can display basic HTML and XML representations of the response. Other listeners provide summary or aggregation information. All Listeners work on the same data; the only difference is in the way the data is presented on the screen. For more information on listeners in JMeter, please see online reference.

To validate something in the response from the Sampler, you can use Assertions. For example, to check for a presence of a particular XML tag in the SOAP response indicating valid response, or in stress testing a web application. You can add assertions to check for certain HTML/XML tags, common error strings, and so on. You can use regular expressions in JMeter to create these assertions.

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 p_w_picpath
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 p_w_picpath
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 p_w_picpath
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 p_w_picpath
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 p_w_picpath
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 p_w_picpath
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 p_w_picpath
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.

原文地址：http://www.developer.com/net/article.php/3839476/Tuning-and-Testing-Enterprise-Web-Services-with-SoapUI-and-JMeter.htm。