Why use SoapUI Pro for Functional Testing?
While the Open Source version can be seen as the Swiss-Army knife for testing, SoapUI Pro is the tool with the sharpest edge. Applied to the Functional Testing area, SoapUI Pro focus on enhancing efficiency and usability. With Point and Click Testing, you can drag and drop instead of manually writing the code. The Form Editor creates a form from your request, further eliminating the need for you to spend time on repetitive coding. These functions make, in combination with The Outline Editor who simplifies and exposes the XML structure, your testing more fun and less time consuming. If creativity, flow and speed are important to you as a tester, SoapUI Pro is too.
Web Service Sample Project
Getting started with a new application is always a challenge, no matter how complex it is. In order to make getting started with SoapUI easier for you, SoapUI comes with a sample SoapUI Project file that can be used as reference and inspiration.
It illustrates some of the basic concepts of SoapUI and can be used as a SoapUI starting point; try out the project, run the included MockService and the included tests in order familiarize yourself with the s SoapUI interface, and then move on to the Your First SoapUI Project tutorial.
Here are the main concepts illustrated in the SoapUI Project.
- Web Service Mocking
- Web Service Inspection
- Functional Tests of Web Services
- Web Service Load Tests
Let start by opening a project.
- Right click on Project Node in the navigator and select Import Project
A Select SoapUI Project dialog will open.
- Select the project file sample-soapui-pro-project.xml or sample-soapui-project.xml from the tutorial folder user-dir/soapUI-Tutorials (Note that you won't have this folder in case you unchecked the option during the installation).
- The Sample Project will be shown in the SoapUI Navigator.
Now that we have the project loaded; let's move to Web Service Mocking!
1) Web Service Mocking
Now, let's see how you add a MockService.
Web Service Mocking is way to fake or simulate the functionality of a Web Service in SoapUI; to create a Mock Up. But why do you need such functionality?
Web Service Mocking is very useful in projects where implementation of the Web Service has not started or is not finished for use yet or where you for some other reasons can't access the Web Services live.
In other words, Web Service Mocking makes it possible for you to start creating test for a Web Service the same time you start to develop the same Web Service. This means, when the real Web Service is ready for testing; you can already have the tests done. This can be extremely powerful and will make it possible to work according to Test Driven or Agile Methodologies.
In SoapUI you can create a MockService simply by choosing to add a Web Service Request to a MockService in order for the MockService to listen to it. Or you can even right-click the Interface Icon and choose "Generate MockService", which will generate a MockService containing each defined response in the Interface.
- To add a MockService, right click on the interface icon and select Generate MockService.
- The Generate MockService dialog will open.
- Enter the name of your MockService and click OK.
Note: You will receive a Composite Warning if you have two mockservices with the same name.
- The MockService will now be successfully generated.
You can then choose how to Respond to the Request and choose how to Dispatch (send out) different responses.
- Now, let's take a look at how the Mock Service works. There is a SampleServiceSoapBinding Mock Service already in the Sample Pro Project, so if you followed the steps above, please discard what you've created or move to the SampleServiceSoapBinding MockService. Open the MockService by double clicking on it.
- Browse through the different Interfaces in the MockService; login, logout, search, and buy, and see what we do with different requests. As you see all the requests are dispatched using scripts. This is by far the most common way of dispatching, but early on in a project you might just want to create a set of responses and dispatch them in sequence or at random.
- Click on the Run button to start the MockService.
- You should now see the MockService running on port 8088.
2) Web Service Inspection
Web Service Inspection a fancy way of saying looking at the Web Service. Good support for Web Service inspection can be very important early in your testing process when you want to find out how a Web Service works.
Inspecting the Web Service can be done in two ways; inspecting the Web Service and making Web Service requests.
- Let's start by some Inspection. Go to the Interface Inspector by double clicking the SampleServiceSoapBinding node. You will see the Interface Inspector open on the SoapUI desktop.
- This is is a structured way of looking at your WSDL. Just browsing the XML of the WSDL is very cluttered and a WSDL often is to complicated too look at in its entirety and therefore it is seldom done, resulting in lower WSDL understanding. In other words, since WSDL's are so complicated people don't read it, and remember, the WSDL is the specification (contract actually, bet let's not get into that...) and how well you use it depends on how well you understand it. This is a serious problem early on in projects, the people in the project don't understand the Contract. The SoapUI Interface Viewer is a great tool for solving this problem.
Now let's Inspect the Web Service. Inspect the Sample Project WSDL by double clicking the SampleServiceSoapBinding Interface Icon. Use the Interface Viewer to familiarize yourself with the WSDL, the move on to Web Service Requests.
- Expand the "login" and double click on Request1. You will see loginRequest open on the soapUI desktop. The request already uses the username Login and the password Login123
- Click on the Run button to submit the request.
- You should now see response on the response panel
you can click on the different tabs to view response in different format.
3) Functional Tests of Web Services
Let's move on and look at how tests work in SoapUI. We have created three different TestSuites all containing different TestCases. A TestCase is made up of several steps, called TestSteps. The structure of a SoapUI project is like this;
As you can see there is also something called LoadTests, we can gather what they are, but we'll go into detail more what they actually do and how they actually work later.
Now let's examine a Functional Test in a TestCase.
- Expand the Sample Simple TestSuite and double click on Simple Login and Logout w. Properties Steps.
- As you can see the TestCase consist of five TestSteps.
- You can also click the Description tab in order to see the in test documentation.
- The step consists of three different types of TestSteps; One PropertyStep, Two TestRequests and Two PropertyTransfer Steps. This is what they do:
Stores Properties for later use. In our case it's the Username and Password required to login.
- Test Requests:
The actual requests to the server. In this case login and logout.
A step used for moving properties between different steps. This might be from a Property Step to a request like the step Property Transfer: Move Username and Password does, or to move properties from a Test Request to another, like the step Property Transfer: Move sessionID does.
- Double click on the TestStep Property Transfer: Move Username and Password.
- The TestStep Editor will now open on the SoapUI desktop.
Concept: this property transfer does two transfers in two Properties. First it takes does the TransferUser Transfer. It takes the Property Username from the step Properties: Username and Password and moves it to the step Test Request: login. Then it takes does the TransferPass Transfer. It takes the Property Password from the said step Properties: Username and Password and also moves it to the step Test Request: login.
- An important feature in SoapUI Tests is The Assertions. Assertions are made in Test Requests and is for validating that the response is what we expected. Open the Test Step Test Request: logout.
- In the TestStep we have four assertions, asserting different things;
- SOAP Response
That the response is a SOAP response
- Schema Compliance
That it complies with the Schema
- Not SOAP Fault
That is isn't a SOAP fault
- XPATH Match
And something called an XPATH match. The XPath Match validates that a certain element has the value expected.
The Test Run
Now that we have examined the TestCase, let's run it! Press the Play Button and the Test will run and the Test Case progress bar should be full and green.
Does it turn red after only a step?
Don't forget to start the MockService.
Or... did you run the TestStep earlier?
Look at the response, maybe the response is that you already have a session?
We logged in earlier and aren't allowed to log in again, let's just go to the MockService, stop it and restart it, clearing any server side sessions. Now, rerun the test.
4) Web Service Load Tests
Something very useful in SoapUI is the ability to quickly create LoadTests. Why is this useful? The earlier you are able to run load tests, the earlier you can discover any performance issues. In SoapUI you create a LoadTest simply by choosing a functional test, right-clicking it and saying New LoadTest. Done!
This makes SoapUI LoadTest extra good since the immediately enable you to load test the functionality not that the Web Service can respond quickly to the same Request over and over again. LoadTests are byproducts of the Functional Tests.
- Go to the TestSuite Sample expanded TestSuite and the TestCase Search and Buy TestCase. There are four different LoadTests in that TestCase, one for each LoadTest strategy. For now, we'll choose the LoadTest: Simple Strategy LoadTest. This LoadTest is based on a Load Strategy we call Simple Strategy which is a very basic strategy with a random delay.
- Let's configure the test.
- The first thing to configure in the Simple Strategy is Limit, the Number of second we want the test to run.
- The second thing to configure in the Simple Strategy is Threads, the number of threads used. For now we'll use one thread.
- The third thing to configure is the Test Delay, which sets the number of milliseconds our base delay will be (1000 is one second). In the test now we have set it to 200 milliseconds.
- The fourth item is the Random variable, which sets how the Test Delay should be changed at random, the value 0.5 means it should be half, that is between 100 and 300 milliseconds.
What would the value 0 in Random mean? That's right, no random delay at all, just 200 milliseconds all the time.
- Now, let's run it!
- As you see the numbers of the test are continuously updated. You can see figures like the response times' throughput per second (tps), assertions, errors, percent of the test run, and more.
- You can also press the graph button
and see a graph of the test run.
Read more about the Load Test Interface here and the different Load Testing strategies here.
- In the SoapUI LoadTests, you can also do LoadTest Assertions. One of the more important assertions is the Max Errors Step.
This is used for allowing the maximum number of errors allowed in a test run, which will lead us to the final example, discovering an error in our MockService.
An error in our MockService
Finally we would like to look at one error we've put in the MockService on purpose.
- Go to the TestSuite Sample TestSuite fails if we don't get faults and the TestCase TestCase: Searching after Logging out LoadTests. There you will find a load test called LoadTest with Multiple Tests (will fail).
- Open it and run it. After a time this test will fail
Because multiple users are simultaneously logging in with the same username, which is not allowed by the MockService
Go ahead, try it!