How to Test Web Services

How to Test Web Services

API Testing Tools

I often get asked the question “How do I go about testing web services?” and the answer I always give may surprise you – the same way you would test any other application!

In general, the best approach to normal functional testing is the same for web services (except for the fact that unlike most other applications, web services don’t have GUI user interfaces). So take comfort in knowing the functional testing techniques that you have always used still apply. Simply think of a web service as a business process without a UI, and write your test case accordingly.

Because web services can be used by many different clients and used in multiple ways, performance testing and negative testing do become more critical. I would suggest you make sure there is good test coverage in those areas. Some good question to ask when automating a web service is:

  • Does the service respond with the correct values?
  • How quickly does the service send a response to the user?
  • Can the service handle expected and unexpected user loads?
  • Can the service handle invalid values and exceptions caused by bad data?

Web Service Testing Terminology

The biggest hurdle for most testers is acclimating to the terminology used when talking about web services. For instance:

  • WSDLs – an XML format that tells you how to access a web service. WSDL is using that is automatically generated for you. Most test tools read in a WSDL and present all the information you need to interact with it.
  • SOAP (Simple Object Access Protocol) – a protocol that uses XML format to exchange info to and from a Web service.
  • SOA (Service-oriented architecture) – a way in which companies can organize software that can be quickly changed to respond to the requirements of the marketplace.
  • Web Service – units of software that run in a network. Typically written to handle a specific business process. Web services can be strung together in multiple ways and used by different applications to create desired functionality.

I believe that once the above terms are demystified, the job of testing web services is pretty straightforward. I also feel that the best way to demystify something is to break it down into simple, hands-on examples.

In this series, I hope to present some simple hands-on examples that break down what a web service actually is, and how one works in general. Hopefully, knowledge plus know-how will equal automation awesomeness!

What about Rest Services?

REST (Representational State of Transfer) is a lightweight option for developing web services the uses the HTTP protocol –a fact that makes is simpler with less overhead than a web service that uses the SOAP protocol.

Most folks have moved from this older method of using a WSDL bad web service to using REST instead.

For this post we’ll be looking at WSDL based services not REST.

How To Create a Web Service

Ok to get started – let’s create our very own web service. We will then use the web service we created as the bases for the rest of this series. When we start testing and looking at the WSDL and the services request, and response the information should make more sense since we will be able to map the values back to the source where they came from.

Why create a web service?

If you’re anything like me, the best way for you to learn is by actually doing. I’ve found that to understand how something works it sometimes helps to actually try it yourself –so I devised a simple example of how to create a web service to help teach some of the concepts of web service testing.

Create a Web Service

Now we will create a simple service that contains one method that adds two numbers together. Okay… I admit it’s not the coolest web service, but it will serve our purpose. Before you start, make sure you have the following setup:

  • Microsoft’s Internet Information Services (IIS) is up and running on your machine
  • The latest.Net Framework SDK is installed
  • Create a directory under your C:\Inetpub\www.root named WebServices (wwroot image)

Next go ahead and copy the following code into notepad:

Basically, the first line s saying that this a web service and the language used is C#. Then we import two namespaces System and System.Web.Services.

Next, we create our class DEMOAddNumbers and add our method named AddThis that accepts two parameters of type integer — x and y. Finally, we add the values together and return an integer value mySum that contains the sum of the passed parameters.

Save the file as DEMOAddNumbers.asmx and place it under your wwwroot/WebServices directory. FYI asmx is the file extension used for ASP.NET.

Create a web.config file

To get this to work on my machine I also had to add a web.config file to my C:\Inetpub\wwwroot directory. Open notepad and copy the following:

Name the file web.config and save it under C:\Inetpub\wwwroot

Verify that the web service works

Next, open up your browser and enter the following address:

http://localhost/WebServices/DEMOAddNumbers.asmx/AddThis?x=40&y=2

The page should return the value of 42 (Which by the way is also the answer to the meaning of life – hehe)


Sweet – we now have a working web service! In Part 2 of this series, we will use this web service to help answer the question of what is a WSDL?

It’s All About the WSDL

We’re now going to take a look at what is WSDL is. A WSDL is an XML document that describes the methods, method parameters, namespace and handling URL for a web service. WSDLs, along with some other forms of documentation, are generated automatically whenever an HTTP-GET request is received by a .asmx file. For an example, navigate to:

http://localhost/WebServices/DemoAddNumbers.asmx


This should bring up an HTML page that describes the methods of the DEMOAddNumbers web service along with some other info. Clicking on the link for the AddThis method from this page will bring up another HTML page that allows you to test the operations of the service. Pretty cool, huh?!? And now, let’s take a look at the actual WSDL.

Looking at a WSDL

For our web service, enter the following URL into your browser:

http://localhost/Webservice/DEMOAddNumbers.asmx?WSDL

The WSDL for our web service (DEMOAddNumbers) should appear. Notice, once again, that we didn’t do anything special to generate the WSDL — it was created for us automatically. As you can see, a WSDL document is really just an XML document that contains information about a web service.

The four main sections of a WSDL

A WSDL is broken up into four main sections: elements types, messages, portType and binding.

types element – Is the data types that are used by the web services.
Notice how the information in the WSDL matches the code in our web services.

message element – This section describes the messages used by the web service and defines the data elements of an operation:

<wsdl:message name="AddThisSoapIn">
  <wsdl:part name="parameters" element="tns:AddThis" /> 
  </wsdl:message>
<wsdl:message name="AddThisSoapOut">
  <wsdl:part name="parameters" element="tns:AddThisResponse" /> 
  </wsdl:message>
 <wsdl:message name="AddThisHttpGetIn">
  <wsdl:part name="x" type="s:string" /> 
  <wsdl:part name="y" type="s:string" /> 
  </wsdl:message>
 <wsdl:message name="AddThisHttpGetOut">
  <wsdl:part name="Body" element="tns:int" /> 
  </wsdl:message>
<wsdl:message name="AddThisHttpPostIn">
  <wsdl:part name="x" type="s:string" /> 
  <wsdl:part name="y" type="s:string" /> 
  </wsdl:message>
- <wsdl:message name="AddThisHttpPostOut">
  <wsdl:part name="Body" element="tns:int" /> 
  </wsdl:message>

– the binding element describes the communication protocols used by the web service:

<wsdl:binding name="DEMOAddNumbersSoap" type="tns:DEMOAddNumbersSoap">
<wsdl:binding name="DEMOAddNumbersSoap12" type="tns:DEMOAddNumbersSoap">
<wsdl:binding name="DEMOAddNumbersHttpGet" type="tns:DEMOAddNumbersHttpGet">
<wsdl:binding name="DEMOAddNumbersHttpPost" type="tns:DEMOAddNumbersHttpPost">

portType element – The fourth element, portType, is generally considered to be the most important element because it describes the web services and all the operations that can be performed, as well as all the messages of the service:

<wsdl:portType name="DEMOAddNumbersSoap">
 <wsdl:operation name="AddThis">
  <wsdl:input message="tns:AddThisSoapIn" /> 
  <wsdl:output message="tns:AddThisSoapOut" /> 
  </wsdl:operation>
  </wsdl:portType>
<wsdl:portType name="DEMOAddNumbersHttpGet">
 <wsdl:operation name="AddThis">
  <wsdl:input message="tns:AddThisHttpGetIn" /> 
  <wsdl:output message="tns:AddThisHttpGetOut" /> 
  </wsdl:operation>
  </wsdl:portType>
<wsdl:portType name="DEMOAddNumbersHttpPost">
<wsdl:operation name="AddThis">
  <wsdl:input message="tns:AddThisHttpPostIn" /> 
  <wsdl:output message="tns:AddThisHttpPostOut" /> 
  </wsdl:operation>
  </wsdl:portType>

In the section above, the portType element defines DEMOAddNumbersSoap, DEMOAddNumbersHttpGet, and DEMOAddNumbersSoapPost as the name of the ports, and “AddThis” as the name of the operation. Also notice that the ports are a Request-Response operation, meaning that our web service can receive a request and will return a response. For example:

Request a request called AddThisHttpGetIn
wsdl:input message=”tns:AddThisHttpGetIn”
Return a response called AddThisHttpGetIn
wsdl:output message=”tns:AddThisHttpGetOut”

Next, let’s look at the process for sending and receiving a request from a web service using a test tool.

Web Service Testing Response and Requests

Now that we have a working web service and understand a basic WSDL, let’s take a look at a web service’s request and response.

First, let’s import our WSDL into our test tool of choice. I will be using SOAPUI (a free open source tool), but you can use whatever tool you like.

In SoapUI, click on ‘File\New soupUI project’. In the New soapUI project, enter the Project Name: AddNums, and for Initial WSDL/WADL enter:

http://localhost/Webservice/DEMOAddNumbers.asmx?WSDL

SoapUI should import the “AddThis” method under projects AddNums\DEMOAddNumbersSOAP. Double clicking on the AddThis ‘Request 1’ will show the following:

*Remember — the WSDL should include all the info needed to interact with a web service. That’s why soapUi was able to read in the WSDL and automatically generate a request with the correct inputs for you.

rest-assured

Web Service Request/Response

Our DEMOAddNumbers web service is the most typical kind, in that, a requester (in this case our test tool) sends a request to the service and waits.

The service then processes the request and sends a reply. Let’s see this in action:

For our request, let’s do a positive test by sending the service valid values:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:AddThis>
         <tem:x>5</tem:x>
         <tem:y>10</tem:y>
      </tem:AddThis>
   </soapenv:Body>
</soapenv:Envelope>

This is the response I get back when I send the request from SOAPUI:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Body>
      <AddThisResponse xmlns="http://tempuri.org/">
         <AddThisResult>15</AddThisResult>
      </AddThisResponse>
   </soap:Body>
</soap:Envelope>

What does SOAP have to do with Web Services

How does this communication take place? Basically, SOAP — which is an XML based protocol used for communicating with a Web Service — sends info to the request over HTTP. SOAP stands for Simple Object Access Protocol. If we look at our request, we will see soap elements such as SOAP Envelope, Header, and Body.
This is what a typical SOAP XML message contains.

SOAP Faults

For a Negative Test — if we send bad data in the request, a SoapFault should occur. So, if we send:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:AddThis>
         <tem:x>5</tem:x>
         <tem:y>10</tem:y>
      </tem:AddThis>
   </soapenv:Body>
</soapenv:Envelope>

We should get back a soapFault:

As we can see, the SOAP XML is the same as our previous response, but now it also contains a Fault element. A Fault element contains errors and status info.

Open Source API Testing Tools for REST and WSDL based services

Remember Selenium is just for browser-based testing, you may be wondering which tool to use for Rest and Soap web service-based testing.

Check out my article on 15 Open Source API Testing Tools For REST & SOAP Service

Testing Web Services Wrap Up

And that’s my take on web services in a nutshell. For a deeper dive, I recommend checking out the site www3school. I’ve also found SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)
to be a great resource book.

If you are using Unified Functional Testing also check out my latest Pluralsight video course

Quick Guide to API Testing with HP’s Unified Functional Testing

2comments
Malay - April 7, 2011

Good going Joe,one thought which comes to the mind is about testing the performance of web services.
There are tools available for testing both functionality and performance of web services like SOAP SONAR etc.
My question is-can we not use Service test to test the performance of WS and not go for load runner?If yes,do we see some limitations?
I beleive ST is purely for WS testing which is preferred over QTP for functional testing,shouldn’t the performance be also tested thru ST.

Reply
    Joe Colantonio - April 8, 2011

    Malay » Hi Malay you still need to use LoadRunner. When you start Service Test up on a machine that has LR installed you are given an option to create a a “Service Test Enabled for Load Testing”. You can then run the script in the LR controller to create a performance test scenario. But if I’m doing a performance test I personal would rather just use LoadRunner’s built in web service protocol. Thanks Malay

    Reply
Click here to add a comment

Leave a comment: