e soapUI project is the central point in all soapUI testing.

Once the project is created, you can

create and run Functional Tests, LoadTests, create MockServices or much more. In this tutorial,
we will walk through two things how to:
1. Create a soapUI project
2. Add a WSDL
1) Create a soapUI project
1. In the navigator, which is the tree structure at the left in the soapUI GUI, right click on
the project node and select New soapUI Project

This will open a New soapUI Project Dialog.

Note: you can also do ctrl +n(win) or cmd+n (mac) to open a new soapUI Project.
2. In the New soapUI Project dialog enter a project name and click OK

3. This will create a new project in the Navigator.

Congratulations, youve just created your first soapUI Project. Lets add a WSDL.
Note: If you would like to try importing a project, try importing the Sample soapUI Project, see
[Web Service sample project] for more details.
2) Add a WSDL
In soapUI the projects mostly are based on a WSDL. Its not necessary to start by importing
a WSDL, but it makes testing easier since the WSDL contains all information you need about
the web service tested; information about the requests and responses, what they contain and
much more, which simplifies soapUI testing greatly.
Lets add a WSDL to the project;
1. Right click on the project node and select Add WSDL

The Add WSDL dialog will now open.

2. Enter
http://www.webservicex.net/WeatherForecast.asmx?wsdl

Click OK.

3. You should now see that the WSDL was successfully added to the project by seeing the

operations in the Web Service in the navigator.

4. You can double click the Project for a window that gives you overview of your project.
As your project and test skills grow, this view will be very important since you can
manage a great deal of things at project level, like JDBC Connections (soapUI Pro only),
Security Configurations. soapUI even contains basic Requirements functionality in the

Project Window.
5. You can also double click the Interface for an Interface view, which shows a lot of
information about the WSDL itself. This is very useful for browsing and examining a

WSDL.

How to load test web service using SOAP UI

by admin on January 21, 2011
Load Testing is quite unique in soapUI, we have created a functionality that allows you to create
Performance Tests quickly and modify them easily. The main differentiator is that Performance
Tests in soapUI generally is created from existing Functional Tests. This allows you to very
quickly create advanced Performance Tests. You can then validate a Web Service performance
under different Load scenarios, maintain functional validations to see that they dont break under
load, run several load tests simultaneously to see how they affect each other and much more.
Lets move on to the tutorial. What we are going to learn is the following:
1. Create a new LoadTest
2. Run The LoadTest
3. Add Assertions to the LoadTest

1) Create a new LoadTest

1. Right Click on a TestCase in the Navigator and select New LoadTest

2. A New LoadTest Dialog will open. In it, enter the name of your LoadTest and click OK.
The LoadTest will open.Don

Done! It really is that simple in soapUI. Lets run it.

2) Run The LoadTest

When a new LoadTest is created, its pre configured to run for 60 seconds (top right) with 5
threads using the Simple LoadStrategy.

1. Modify these values as desired (read more about soapUI LoadTest Configuration) and
2. run the test.
You will see the statistics table in the middle beginning collecting data and after 60
seconds should have a finished LoadTest. (read more about LoadTest Execution)

We have now succesfully run our first LoadTest, lets add an assertion to do Load Validations.

3) Add assertion to the LoadTest

1. In the LoadTest editor, select the LoadTest Assertion tab at the bottom of the editor

2. Click the Add Assertion Button

assertion.

in the LoadTest Assertion menu bar to add an

3. The Add Assertion dialog will now open, select Step Maximum. Select Maximum sets a
Max Time in milliseconds that the responses are allowed to take, if the time exceeds what
weve set, the test will fail. Click OK.

4. The TestStep Max Assertion window will now open. As you can see we allow a max
response of one second, 1000 milliseconds. Lets not modify anyting, Click Ok

5. The Step Maximum assertion will now be successfully added.

6. Now run the test again. You should see that the column err adds up quickly, the responses
takes to long time.

Creating and Running Load Test

Basics
A LoadTest in soapUI is used for asserting that your target services when you run an existing
functional TestCase repeatedly for a desired duration with a desired number of threads (which is
the same as Virtual Users). LoadTests are shown in the Navigator as children to this TestCase;

(here you can see that the Search and Buy TestCase TestCase has four LoadTests defined).
You can create any number of LoadTests for your TestCase either from the TestCase right-click
menu or the TestCase Toolbar with the New LoadTest option. Open the LoadTest window by
double-clicking it in the Navigator (a newly created LoadTest will be opened automatically).

LoadTest Execution
SoapUI allows you to run your LoadTest with as many Threads (=Virtual Users) as your
hardware can manage, depending mainly on memory, CPU, target service response-time, etc. Set
the desired value and start the LoadTest with the Run button at the top left in the LoadTest
window. The underlying TestCase is cloned internally for each configured Thread and started in
its own context; scripts, property-transfers, etc.. will access a unique copy of the TestCase and
its TestSteps which avoids threading-issues at the TestStep and TestCase level (but not higher up
in the hierarchy; if you TestCase modifies TestSuite or Project properties, this will be done on
the common shared ancestor objects). The Thread Startup Delay setting in the LoadTest
Options dialog can be used to introduce a delay between the start of each thread, allowing the
target services (or soapUI) some breathing space for each thread.
Depending on which limit and strategy has been selected, the LoadTest will run as configured
until it terminates due to one of the following:

It has reached its configured limit

It has been canceled by the user with the Cancel button on the LoadTest toolbar
It has been canceled by a LoadTest Assertion when the maximum number of allowed
errors for that assertion has been passed

If the limit is time-based, the Cancel Running option in the LoadTest Options dialog allows
you to control if running threads should be allows to finish or should be canceled. In the same
manor, the Cancel Excessive option controls if excessive threads should be cancelled when
the thread-count decreases (for example when using the Burst Strategy).
Multiple LoadTests can be executed in parallel to test more advanced scenarios, just open several
windows at once and run them side-by-side. A sample scenario for this could be a recovery test
consisting of a simple LoadTest generating baseline traffic and another LoadTest using the Burst
Strategy which creates high traffic in Bursts; after each Burst the baseline LoadTest can assert
that the system handles and recovers as required.