These days, with so many people using the Internet in their day-to-day activities, the web sites are becoming more and more complex, with a lot of content coming from other sources/3rd parties.
One example of a 3rd party that offers its data to other sites is the Weather Channel site that has several web service APIs through which its data can be used on other sites or even mobile applications. Most of the APIs are based on web services these days due to their ease of use, security and performance. It is also important that the information is exposed to public through web services without exposing anything else from the 3rd party business.
This crash course will focus on a tool that makes the testing of a web service manageable and easy.
Without a proper testing tool and using either the default web service test page or an in-house test application, the testing of web services is difficult, takes a very long time and is very error-prone. The regression and load testing for a web service are impossible in these cases. All testing will need to be repeated manually again and again without any chance for automation.
For all these issues, there is a testing tool called SOAP UI.
A developer from the company I work for introduced me to it as a better way of running manual tests for web services.
SOAP UI is a free testing tool based on open-source standards as XML, XPATH and GROOVY (java). It is very stable and robust even if it is offered for free.
I purchased the commercial version as well hoping that it comes with significant additional functionality but I discovered that the difference between the free and commercial versions is very small. The only thing that the commercial version adds is a few templates for common assertions and a more visually oriented way of creating and executing test cases.
Figure 1 – SOAP UI interface
SOAP UI works very well with SOAP and REST web services.
It requires a little bit of training but it is extremely effective for:
- Web service regression testing
- Web service test automation
- Web service load testing
It does not use any proprietary technology so if you used before XML, XPATH and web services, the training for SOAP UI may be minimal and you can start creating test cases and assertions within hours.
The main functionalities of SOAP UI are:
- Creates a new project using only the web service WSDL link; from the WSDL link, SOAP UI will get the details of all methods and import them automatically
- Creates test cases directly from the web method request; just right click on the request and a test case will be created and added to a test suite
- Tests web methods separately or in combination; the tool has a very useful capability that allows data and parameters to be passed from one method to another; it also allows data to be saved in variables so other methods can access it
- Allows creating validations on the web method results through assertions; the assertions can be created either in XPATH or XQUERY; the assertions can verify the values of a field of a result or the values of a field for all results
- Allows creating many other types of validations like for response time, schema compliance, soap fault, etc
- Allows organizing the test cases in test suites
- Allows running all test cases from a test suite and getting pass/fail results for each test case
- Allows parameterization of the test case’s request fields so that a test case can use different values from a table or database
- Allows creating complex validation scripts using groovy (useful when a validation cannot be done with xpath)
- Has some support for web service load testing
- Has some support for test coverage and requirements management
Figure 2 – SOAP UI test case
The test automation works properly especially when both the method request and response do not change too much during the testing phase. The web method implementation can change however.
Some of the types of tests that can be automated with SOAP UI are:
- Verify that the web method returns results
- Verify that each result has all proper fields
- Verify that each field has proper data (check data type, data templates, etc)
- Verify that some fields are calculated properly from other fields
- Verify that the response has correct error messages if
- Mandatory fields have no values
- Incorrect data is passed to fields
Figure 3 – Automated Regression Testing results
I used SOAP UI in a few projects so far and for me it is as important for web service testing as Excel for creating spreadsheets.
The only disadvantage I found for the tool is the lack of a proper user guide. The vendor site has however a lot of details and examples on how different tool components can be used. The vendor’s forum is another good resource for technical information.
Refer to http://university.utest.com/soap-ui-web-service-testing-a-practicum/ for details on how to create a project, test cases and assertions.
For more details, see www.soapui.org
There are other tools on the market for testing web services like QTP and Parasoft SOATest. My presentation focused on SOAP UI for the reasons above and also because this is the only tool I used so far for testing web services.