soapUI: Creating a Test Suite and Test Step

In my last post I provided a brief overview of soapUI, a popular tool for testing web services. In this post I'll go into a little more detail and cover some basic soapUI procedures and concepts.

As I mentioned in my previous post, soapUI can build a basic test suite from a WSDL.  For this mini-tutorial, I'll be using a web service based on the periodic table of elements that allows users to retrieve symbols, atomic weights, etc.  In soapUI, select File - New soapUI Project and enter a Project Name and the following Initial WSDL/WADL:

http://www.webservicex.net/periodictable.asmx?WSDL

Check the box to generate a test suite and click OK. You'll see soapUI automatically load definitions for our web service, after which it prompts the user for test suite creation options, which include selecting which operations you'd like to include and how you'd like them grouped in test cases. Just accept the defaults here (you may be prompted twice-- soapUI is building test suites for SOAP 1.1 and 1.2 bindings; you can use either for the following examples).

On the left-hand side of the window you'll see the workspace navigator; after a successful import you'll see interfaces and generated test suites for the web service.


soapUI Workspace Navigator
Using the default options, each operation will have its own test case consisting of a single SOAP request test step.  Let's actually build a test request and send it to the web service.  Drill down into the test suite for the periodic table web service and double-click on the GetElementSymbol test step to launch the test step editor.  The GetElementSymbol operation takes a single input parameter, an element name, and returns its symbol in the periodic table.  Modify the test request in the left pane of the editor so the ElementName parameter is "Silver" (replace the "?" between the ElementName tags with "Silver").  Then click the Submit Request button at the top of the window-- the leftmost button that looks like a Play button.  The test request is sent to the web service and you should see the response in the right pane.


SOAP Request Test Step
Now that we have a working SOAP request test step we'll want to create some assertions to validate our response data.  Click the Assertions button at the bottom of the soapUI window to expand the Assertions panel (displayed across the lower part of the window).  Click the Add Assertions button (leftmost button at the top of the Assertions panel) to launch the Add Assertion dialog-- here you can look through some of the different Assertion types that are available.


Add Assertion dialog
From the SLA section, select the Response SLA assertion type and click Add.  This assertion type confirms that the given test request receives a response within a specified period of time; you'll be prompted to specify the acceptable response time (in milliseconds) before the assertion is added.  Enter 10000 (10 seconds) here.

Add a Not SOAP Fault assertion (from the Compliance, Status and Standards section) to verify that the test response is not a SOAP Fault, and finally, add a Contains assertion from the Property Content section to validate response data.  Since this particular SOAP request is pretty straightforward with only one piece of data returned in the response (the element's symbol), the Contains assertion should be adequate.  You'll be prompted to enter a string to look for in your test response; enter text matching the response's Symbol element: "Ag" (the quotation marks should not be included).

For any subsequent runs of your test step, your SOAP response will be validated automatically against the added assertions with the pass/fail status of each indicated by "green light"/"red light" icons in the Assertions panel.


Assertions panel with pass/fail statuses indicated
The SOAP Request test step is just one test step type-- in the next post, we'll look at some of the others.

soapUI: An Overview

One of my favorite test apps I've encountered over the last few years is soapUI, a tool for testing SOAP web services. While it's also available in a Pro version for a fee, the freeware version is still pretty feature-rich with support for customization via Groovy, a Java-like scripting language. It's just a well-made program; when I first started working with it I'd frequently find myself wondering if there was an easier way to do X or Y-- and usually there was. It's almost spooky how well soapUI's makers have anticipated what users might want to do with it, and they're constantly adding meaningful functionality.

Setting up your basic test framework in soapUI is as easy as pointing it toward your web service's WSDL.  Using the provided WSDL information, it can generate a test suite with test requests built on available operations.


The main soapUI window
To test each request, you can define a set of pass/fail assertions.  SoapUI provides an impressive number of assertion types-- you can validate against response codes, confirm that responses are received within a set number of seconds, etc.  Data validation includes simple Contains/Not Contains tests that check for the presence (or absence) of specific data in responses or more flexible XQuery and XPath assertions that allow you to parse and analyze response XML data to ensure it matches expected results. 

I've found XQuery assertions particularly useful, especially when dealing with a mix of static and dynamic data in responses-- you can set up XQuery assertions in such a way that the static data (which is more suitable for automated verification) is isolated from the dynamic data and verify large data sets all at once.

It's also worth noting that a sister application for soapUI called loadUI was introduced within the last few years.  As you might guess, loadUI is a tool for performing load tests against a web service.  One of the selling points of loadUI is that you can use the same functional test requests developed in soapUI as your loadUI test requests.

Over the next few posts, I'll dig a little deeper into soapUI, including XQuery and XPath syntax for those who may not have worked with it before.

Introduction

With agile development methodologies growing in popularity, knowledge of some test automation tools and techniques is a useful thing for a software tester to have in his or her bag of tricks. In this blog I plan to cover some of the tools I've found useful and hopefully help software testers with little experience in automation get up and running quickly.

In the spirit of full disclosure, I'm not a developer by trade. Some of my scripting solutions may lack the elegance of a professional programmer-- but hopefully they should be good enough to get a job done when results are your main concern. As a software tester, I started out primarily using manual techniques but found myself wanting and needing to learn about automation as "agile" and "automation" became organizational buzz words-- I suspect many other software testers have found themselves in the same boat. The good news is that (in my opinion) learning about and implementing automation can be an interesting and rewarding exercise.

Presently, I don't envision any overarching organizational structure to the blog posts; basically, I hope each post by itself might provide some information that's useful to somebody. Over time, though, I'll probably revisit certain topics; I may group these blogs together as appropriate as they accumulate.