Soapui

=====
Soapui is a testing tool to test web services Api

Before moving to soapui tool first we have to know what is web service

Api
-----
An API can be created for applications, libraries, operating systems, etc. This is a way
to define their “vocabularies” and resources request conventions (e.g. functions calling
conventions). Certainly, it may include specifications for routines, data structures, object
classes, and protocols used to communicate between the consumer program and the
implementer program of the API.

an API is an abstraction that describes an interface for the interaction with a set of
functions used by components of a software system. The software providing the
functions described by an API is said to be an implementation of the API.

An API can be:

● Firstly, API is bundled in the libraries of a programming language, e.g. Standard Template
Library in C++ or Java API.
● Secondly, it specifies, meant to address a specific problem, e.g. Google Maps API or Java
API for XML Web Services.
● Thirdly, it is language-dependent, meaning it is only available by using the syntax and
elements of a particular language, which makes the API more convenient to use.
● Lastly, it is language-independent, written so that it can be called from several programming
languages. This is a desirable feature for a service-oriented API that is not bound to a
specific process or system and may be provided as remote procedure calls or web services.

API in Brief
API is an acronym and it stands for Application Programming Interface. This is a set of
routines, protocols, and tools for building Software Applications. APIs specify how one
software program should interact with other software programs.

Routine​: a program that performs a particular task. Routine is also known as

procedure, function or subroutine.
Protocols​: A format for transmitting data between two systems.

In other words, API stands for Application Programming Interface. Subsequently, it acts
as an interface between two software applications and allows the two software
applications to communicate with each other. Moreover, it is a collection of software
functions which can be executed by another software program.

An Application Programming Interface, API, specifies how some software components

should interact with each other. While many people associate APIs with software
libraries, the definition is broad enough to include Web Services and all types of
messaging that SoapUI supports: SOAP, REST, JMS, JDBC, AMF and HTTP.

Understanding API Testing and its

Types
Let us understand API Testing and its Types. API testing is a type of software testing
that involves testing APIs directly. But also, as a part of integration testing to check
whether the API meets the required expectations. The main focus lies on a Business
logic layer of the software architecture. Moreover, API testing can be performed on any
software system. However, API testing is entirely different from GUI Testing.
Functional API Testing
While SoapUI includes basic functional, load, and security testing. Moreover, this
involves verifying the behaviour of a system matches expected usability and
functionality requirements.

Further, an API works on a series of requests and parameters to invoke a response.

This data is usually from another system or database. Subsequently, SoapUI works by
sending requests and parameters against a system, and then verifying whether the
response received is correct.

What to Test by API

Basically, on API Testing, we send a request to the API with the known data and we
analyse the response.

● Firstly, Data accuracy

● Secondly, HTTP status codes
● Thirdly, Response time
● Fourthly, Error codes in case API return any errors
● Subsequently, Authorization checks
● Lastly, Non-functional testing such as performance testing, security testing

UI Testing and API Testing

UI (User Interface) testing tests the graphical interface part of the application. Further,
Its main focus is to test the look and feel of an application. However, API testing
enables the communication between two different software systems. Subsequently, its
main focus is in the business layer of the application.

API Testing Types

API testing typically involves the following practices:

● First of all, Unit testing: To test the functionality of individual operation

● Secondly, Functional testing: To test the functionality of broader scenarios by using a block
of unit test results tested together
● After this, Load testing: To test the functionality and performance under load
● Subsequently, Runtime/Error Detection: To monitor an application to identify problems such
as exceptions and resource leaks
● In addition, Security testing: To ensure that the implementation of the API is secure from
external threats
● Moreover, UI testing: It is performed as part of end-to-end integration tests to make sure
every aspect of the user interface functions as expected
● Lastly, Interoperability and WS Compliance testing: Interoperability and WS Compliance
Testing is a type of testing that applies to SOAP APIs.

API Testing Benefits

● First of all, API Testing is time effective when compared to GUI Testing. API test automation
requires less code so it can provide faster and better test coverage.
● Secondly, API Testing helps us to reduce the testing cost. With API Testing we can find
minor bugs before the GUI Testing. These minor bugs will become bigger during GUI
Testing. So finding those bugs in the API Testing will be cost-effective to the Company.
● Further, API Testing is language independent.
● Lastly, API Testing is quite helpful in testing Core Functionality. We can test the APIs without
a user interface. In GUI Testing, we need to wait until the application is available to test the
core functionalities.

API Testing Challenges

● First of all, Main challenges in Web API testing is Parameter Combination, Parameter
Selection, and Call Sequencing.
● Subsequently, there is no GUI available to test the application which makes difficult to give
input values.
● Further, Validating and Verifying the output in a different system is a little difficult for testers.
● Last but not least, Parameters selection and categorization is required to be known to the
testers..

API Testing Test Cases

Test cases of API testing are based on
 ● Firstly, return value based on input condition: it is relatively easy to test, as input can be
defined and results can be authenticated
● Secondly, Does not return anything: When there is no return value, a behaviour of API on the
system to be checked
● Thirdly, trigger some other API/event/interrupt: If an output of an API triggers some event or
interrupt, then those events and interrupt listeners should be tracked
● Fourthly, Update data structure: Updating data structure will have some outcome or effect on
the system, and that should be authenticated
● Subsequently, Modify certain resources: If API call modifies some resources then it should
be validated by accessing respective resources
● Further, No Graphical User Interface (GUI) – APIs are primarily intended for
computer-to-computer communication. Computers don’t need a user interface.
● In addition, Synchronous and Asynchronous Dependencies – APIs often rely on other APIs
or back-end systems to function correctly, on time, in a sequenced fashion.
● Lastly, Test Data Management – API testing verifies the business logic of an application
layer, which often has millions of permutations and use cases.

what is web services?

---------------------------

Web Services is the mechanism or the medium of communication through which two
applications / machines will exchange the data irrespective of their underlying architecture and
the technology.
Or simply we can say

Web services is a technology that enables interaction between any two applications.

See one example

Consider a bus booking site. 

When user selects a bus and input all the information, he has to make the payment and 
for that the site requires user to select a mode of payment .  
 
If user selects CREDIT card as the mode of payment then user has to input all the credit 
card details.  
 
 
Now these details cannot be authenticated by the bus booking site , 
 
it has to request the bank to authenticate the details provided by the user. 
 
 But how will it interact with the bank because the bank application can be developed in 
any other technology .  
 
The bus booking site has no control over which technology the bank application has 
been developed. 
 
Thats where webservices comes into picture. 
 
It makes the interaction between two applications possible . It accomplishes by 
serving the data in the standard format such as XML or JSON. 
 
In our example the bus booking site will send all the CREDIT card related information. 
The bank application will then authenticate the credentials and then return appropriate 
response to the bus booking site. 

In the modern technology if you want to build a software application

you don't need to build each and everything from scratch.

There are lots of readymade services available which you can plug into your
application and you can start providing those services in your application.

In that example u can see bus site is different and bank site is different but
who is connecting from bus site to bank site

Webservices right?

One more example

I have developed a application “Any application” like ecomerce or bus site application

In my application i want to display weather forecast information

How can we interact with weather service

we need to put the weather sensor in different different country

Then we can interact with weather information
Here just think if we ill do this kind of thing then definitely it will take so much time and also it will
very expensive

So here i ​ don't need to collect, process and render the data in your application

Simply i can buy the services from the people who already well-established in
processing and publishing such kind of data.

Or

One more example

Make my trip site

In make my trip application u can see there are so many services availble like flight service,
hotel service,train service and also providing travel system for different different holiday
packages

In one application there are providing so many services

If i developed a application like makemytrip

Then just how many services we have to develope

For making simplicity we just added diffrent web services

Means

In make my trip application if any customer want to book a flight tiket there are providing
diiferent flight companys name and timing also how its possible

These flight company application provided their webservices to make mytrip

Comming hotel booking throgh make my trip

There are different hotel company is availble ​Booking​.com.

● Kayak.
● Priceline.
● Hotels.com.

These hotel companies providing there apis or webservices to make my trip

Suppose you are working on a company in this company developed a application
So u are the automation tester so u have to check the webservices working perfectly or not
See how webservices working and how to develo[ed a webservices these are headche for
developer not the test engineer

So testing engineer only test the webservices

The webservice perfectly working or not

========================================
So any doubt on web service

Api vs webservices
Dont be confuse between api and webservices

Every webservices we can say api

Bu every apis we cant say webservices

both are means of communications 

 
The difference is that Web Service almost always involves communication over network  
 
and  
 
HTTP is the most commonly used protocol 
 
While an API can use any means of communication e.g. DLL files in C/C++, Jar files/ 
RMI in java, Interrupts in Linux kernel API etc. 
 
In api’s has different different flavores 
 
In api’s one flavour is webservices 
==================================== 

webservices is a language independent way of communication.

Means
Web Service can support any programming languages
For example

If one application internally uses java languages and one more site is internally uses .net in this
case
We can use web service because webservice support all languages
That's why we called webservice is platform independent

There are 2types of web services:-

---------------------------------------------

1)SOAP services
2)RESTful Services

SOAP Services:-
---------------------
SOAP stands for Simple Object Access Protocol. It Support only XML type format.(why xml
format because of machine readable)

SOAP can work on almost any internet protocol like http,https,smtp,ftp etc.
What is protocols

Protocol means a standard or set of rules that allowed to communicate with 2 application

Diffrent diffrent protocol is there like http, https,ftp, smtp

It is one type of gate whatever the data i will send from one application to another application
first it will check then it will verify the data then it will send to 2nd application
If some error will happen in my data then it will send the diifrent diffrent status code

SOAP supports SSL and WS-Security which is enterprise level security.

What is SSL(Secure Socket Layer) and WS-Security:-

----------------------------------------------------------------
SSL provides in-transit security only. This means that the request is only encrypted while it is
travelling from client to server (or back). ... SSL secures entire message, with WS-Security we
can choose to encrypt only part of a message.SSL encrypts at transport level; WS-Security
encrypts at message level.
SOAP is a W3C( World Web Web Consortium) recommendation for communication between
two applications.

SOAP is XML based protocol. It is platform independent and language independent. By using
SOAP, you will be able to interact with other programming language applications.

Advantages:-
------------
WS Security: SOAP defines its own security known as WS Security.

Language and Platform independent: SOAP web services can be written in any programming
language and executed in any platform.

Disadvantages:-
--------------
Slow: SOAP uses XML format that must be parsed to be read. It defines many standards that
must be followed while developing the SOAP applications. So it is slow and consumes more
bandwidth and resources.

REST Services:-
---------------
REST stands for REpresentational State Transfer.

REST is an architectural style not a protocol.

Representational state transfer is a software architectural style that defines a set of constraints to be
used for creating Web services. Web services that conform to the REST architectural style, called
RESTful Web services,

Advantages:-
------------
Fast: REST Web Services are fast because there is no strict specification like SOAP. It
consumes less bandwidth and resources.

Language and Platform independent: REST web services can be written in any programming
language and executed in any platform.

Can use SOAP: REST web services can use SOAP web services as the implementation.

Permits different data format: REST web service permits different data format such as Plain
Text, HTML, XML and JSON.
Web Services Components
Important components of the web services. They are,

● WSDL – Web Service Description Language

● SOAP – Simple Object Access Protocol
● UDDI – Universal Description, Discovery and Integration
● RDF – Resource Description Framework

WSDL (Web Services Description Language) ​– A WSDL is a document that should

be written using XML. This document describes the following details about the web
service:

● First of all, the origin of the web service

● Secondly, header information
● Subsequently, port type
● Last but not least, input and output messages

WSDL
----------
WSDL stands for Web Services Description Language.
Wsdl is xml standard document it is used to describe web services
{
When server send the information data to client it will come in wsdl format
It is a one type of format we can test soap based web services
}
Using wsdl we can test soap based webservice
If u want to test any webservices u need a proper format of this webservice
{
Suppose u are a automation tester u have to test webservices

One make my trip application is there u have to test that application hotel services

U need a format right without format how can u know this is a webservices this format is nothibg
but wsdl file

Using wsdl we can test soap based webservice

Without wsdl file we cant test soap based services

For soap base web services we can use wsdl file

For rest base we are using different format i wll discuss later

WSDL (Web Services Description Language) is an XML based language

which will be used to describe the services offered by a web service.

Structure of wsdl file

<type>
This tag is define all the datatypes, which will be used to define the type of data in the message
exchanged between the client application and the web services

For example
In a company has employer name ,id ,salary
Employe name is a string type
Employe id is int type
Employee salary is double type

<message>
This tag is used for define which is exchanged between the client application and the
webserver. This message will exchange the input and output operation which can be performed
By the webservice
In message tag it consist input and output
<port type>
This is tag is used to encapsulated every input and output message into one logical operation

<binding>
This tag is used to bind the operation to the particular port type, this is so that when the client
application calls the relevant port type , it will then able to access the operation which are bound
this port type

<service>
This tag is a name given to the web service itself, initially when a client application make a call
to the webservice , it will do by calling the name of the webservice

​UDDI (Universal Description, Discovery and Integration) ​– This is a global

repository where we can search the web services spread over the globe. Moreover, this
is the place where the WSDL is described in detail. In addition, this will communicate
through the SOAP protocol .
SOAP (Simple Access Object Protocol)​ – Generally, it uses XML based data to
interact with web applications.
● Firstly, SOAP is language and platform-independent as it is written by using XML.
● Subsequently, It creates the platform to communicate with the applications that are running
in different operating systems using different technologies.
● Moreover, most of the Internet applications interact with each other over Remote Procedure
Calls that use DCOM (Distributed Component) and CORBA (Common Broker Architecture)
● Lastly, these technologies are different than the HTTP.

RDF
RDF (Resource Description Framework) – RDF contains the description of web
resources such as title, author, content, and copyright information. This framework was
designed so that computers can be read and understood easily by the web. RDF is
completely written by using XML language.

RDF data can be transferred between different types of computers using different
operating systems and programming languages. Generally, RDF uses Uniform
Resource Identifiers (URIs) on the web and it describes the resources along with the
property and property values.

For Rest we used URI(​Uniform Resource Identifiers)

---------------------------------------------------------------------------------------
Dont be confused uri and url

Uri is uniform resource identfier and url is uniform resource locators

The diffrence between the url is a basically a name it represenation of an entity of some kind of
Resource somewhere where a url specifies where that resouce can be found
So url is a uri but a uri is not a url

{
REST APIs using ​ Uniform Resource Identifiers (​URIs​) to address resources. ​REST
API​ designers should create ​URIs​ that convey a ​REST API's​ resource model to its
potential ​client​ developers.
}
SOAP UI TOOLS:
------------------------
SoapUI is an open-source web service testing application for service-oriented
architectures (SOA) and representational state transfers (REST). Its functions are-

● Firstly, web service inspection,

● Secondly, invoking, development, simulation and mocking testing
● Subsequently, functional testing,
● Lastly, load and compliance testing.

Moreover, a commercial version, SoapUI Pro is also available. Further, it mainly

focuses on features designed to enhance productivity. In addition, SoapUI was initially
released to SourceForge in September 2005.

Also, it is free software. This is licensed under the terms of the European Union Public
License. Since the initial release, SoapUI has been downloaded more than 2,000,000
times. Moreover, it is built entirely on the Java platform and uses Swing for the user
interface. As a result, this makes SoapUI a cross-platform. Today, SoapUI also supports
IDEA, Eclipse, and NetBeans.

SoapUI can test SOAP and REST web services. Moreover, it can also test JMS, AMF
and any HTTP(S) and JDBC calls

Using soapui we can test soap based services and rest based services

Using soapui tool we can test

Functional testing
Load testing

Security testing

SOAPUI supports all the standard protocols and technologies to test all kinds of API's.
Using soapui we can test both manual and automation testing
SOAPUI interface is simple that enables both technical and non-technical users to use
seamlessly.

There are 2version is there

1)Free--Soapui
2)license--soapui pro

Features of SoapUI
SoapUI core features include:

● Firstly, web services inspection

● Secondly, web services invoking
● Subsequently, web services development
● Further, web services simulation and mocking
● Lastly, web services functional, compliance and security testing

User-Friendly: Features of SoapUI

Even without prior familiarity, SoapUI is very comfortable for new users. For instance, if
we wish to create a SoapUI project. Just click on the File menu and then click New
SOAP Project option and then provide a valid WSDL file path. Similarly, if you take an
assignment in SoapUI tool, we can do it as easily as Microsoft suites.

Easy for Functional Testing

SoapUI provides drag and drops options for creating test suites, test steps and test
requests to build complex test scenarios without writing any background scripts. Once a
project is created, then we can add test suites under it. The test suite includes test steps
and test requests based on the services.
SoapUI also provides options for test debugging that lets us watch the test execution
step by step. With the help of SoapUI, we can also perform data-driven testing within a
short period of time.

It provides –

● Firstly, Drag and Drop Test Creation – Enhance your productivity with a code-free test
environment. Create and run even the most complex test scenarios with drag and drop
actions.
● Subsequently, Complex Scenarios – Perform and validate a login procedure while testing
your enterprise messaging and capturing client-server SOAP traffic. All at once!

Security or Vulnerability Testing

SoapUI and SoapUI Pro tools provide options to protect the websites from hackers and
viral software applications. Vulnerability testing is a type of testing that helps us to
identify the weak areas of web applications.

With the SoapUI family tools, we can protect applications by executing Test Generator,
SQL Injection and XML Bomb methods. Test Generator is a SoapUI Pro feature. It
helps to create complete vulnerability test suites..

For example, see the below SQL query:

Select *from Customers where CustomerId = “C2014” or 1=1

The above query will return all the customers since the 1=1 condition is always true.
This way hacker can get all the username and passwords easily with this sample query.
SoapUI tool can simulate these queries so we can understand the hack-proof-ness of
the site.

XML bomb is in SoapUI that allows us to test services bypassing huge XML data and
examines the overflow of the application.
In addition to these, the SoapUI tool has many more features like cross-site scripting,
passing random string data to identify the string vulnerabilities, boundary level testing,
etc.

Using a complement of tests and scans, protect your services on websites against the
most common security vulnerabilities.

It provides

● Firstly, SQL Injection – Secure your database. Send in Malicious SQL statements in order to
make sure it’s not possible to get access to or weaken your databases.
● Subsequently, XML Bomb – A document of extreme size can cause instability, make your
systems inaccessible or make your system an attack vector. The XML Bomb scan will
examine whether your system is vulnerable to stack overflows.

Load Testing using LoadUI

SoapUI can also estimate a web application’s load balancing capacity. For this, SoapUI
includes an option called LoadUI that is available on the toolbar. After creating a project
with proper test suites we can move to load testing by just clicking on the LoadUI option.
SoapUI then navigates to the LoadUI tool and then to the tests can be configured based
on the need.

After executing the load test, LoadUI will generate a report that helps determine whether
the application can run with a heavy load or not.

In SoapUI, you create advanced load tests quickly and easily on the base of existing
functional API tests.

It provides

● Firstly, Click and Run Tests – Create load tests in SoapUI from existing functional tests with
just a right-click.
● Subsequently, Pre-Built Load Strategies – Select one of pre-defined load strategies –
Simple, Fixed-Rate, Variable, or another – to simulate various test conditions easily.
●
Automation with Groovy
To write automation scripts in SoapUI, we need to add Groovy Test step under the test
suite. The groovy script has built-in libraries and allows us to integrate Java-based
libraries too. So, it will be very helpful if you are familiar with Core Java. We can write
complex scenarios using Groovy script and java.

For instance, consider a situation where you need a response from one test request and
then pass it as an input to another request. To accomplish this, we could store the
response data in global properties and then reuse them through the scripts.

See the sample screenshot which shows Groovy script test step and a sample script:

Data-Driven Testing
SoapUI Pro supports data-driven testing. It lets us perform bulk insert, delete and
update related testing. We could upload the Excel/CSV format test data to perform bulk
testing.

In order to perform data-driven testing in SoapUI, we will have to add DataSource and
DataSourceLoop test steps under the test suite. DataSource test step deals with the
external data source configuration and DataSourceLoop fetches the data row by row
from the external data source.

Assertions
Assertions are another key feature in SoapUI. It basically validates the response
message while executing the test steps by comparing it to any part of the response
message or entire message.

For instance, if we have an authentication web service which should authenticate the
login credentials given by the user. Let’s assume the web service response is in JSON
format. So, if the authentication is done successfully means, service will return a
successful message to the user.

Download-
----------------
And explain the difference between soapui and soapui pro
============================================
How to install
===========

Explain Ui of SOAPUI-
--------------------

Main Window
The Main Window has the following tools-
 Option Description
1 Main toolbar Main toolbar
2 Icons toolbar Icon shortcuts toolbar
3 Navigator Pane Expandable tree display of workspace content (Read Reference
Navigation)
4 Properties Pane Lists available predefined workspace properties(Read Reference
Navigation)
5 Log Inspectors Available log inspectors in the main window

File Menu
The File Menu has the following tools-
Option Description
New soapUI Project Creates a new soapUI project in this workspace
Import Project Adds an existing project into this workspace
Import Remote Project Imports a remote project into this workspace
Save All Projects Saves all projects in the current workspace
Open All Closed Projects Opens all closed projects in the current workspace
Close All Opened Projects Closes all opened projects in the current workspace
Rename Renames this workspace
New Workspace Creates a new workspace
Switch Workspaces Loads another workspace file
Clear Workspace Removes all projects from the workspace
Preferences Sets global soapUI preferences
Save Preferences Saves all global preferences
Import Preferences Imports soapUI settings from another setting -file
Recent Reopens recent items
Exit Saves all projects and exist soapUI
Exit Without Saving Exits SoapUI without saving
Online Help Shows online help

Tools Menu
The Tool Menu consists of the following tools-

Option Description
JBossWS Artifacts Generates JBoss WS artifacts using the JBoss wstools utility
JBossWS JAX-WS Artifacts Generates JBossWS JAX-WS artifacts using JBoss WS
wsconsume
JAX-RPC Artifacts Generates JAX-RPC artifacts using wscompile
JAX-WS Artifacts Generates JAX-WS artifacts using wsimport
AXIS 1.X Artifacts Generates AXIS 1.X artifacts using WSDL2Java
AXIS 2.X Artifacts Generates AXIS 2.X artifacts using WSDL2Java
Apache CXF Generates Apache CXF using WSDL2Java utility
XFire 1.X Stubs Generates XFire 1.X stubs using wsgen utility
Oracle Proxy Artifacts Generates Oracle Proxy artifacts using the wsa.jar utility
XmlBeans Classes Generates XmlBeans classes
JAXB 2.0 Artifacts Generates JAXB 2.0 artifacts
.NET 2.0 Artifacts Generates .NET 2.0 artifacts using wsdl.exe
GSoap Artifacts Generates GSoap artifacts using wsdl2h and soap2cpp
Launch TcpMon Launch Tcp Mon for monitoring SOAP traffic
HermesJMS Start Hermes JMS application

Desktop Menu
The Desktop Menu consists of the following tools-

Option Description
Switch Window Prompts to switch to an open editor window
Maximize Desktop Hides or shows the navigator and log tabs
Close Current Close the current tab
Close Others Close all tabs except the current one
Close All Close all windows
Open TestCase Layout Opens TestCase Layout

Icons Toolbar
The Icons Toolbar has the following options and tools-

Option Description
Empty Creates an empty SoapUI project.
SOAP Creates a new SOAP project.
REST Creates a new REST project.
Import Imports an existing soapUI project into the current workspace
Save All Saves all projects in the current workspace
Forum Opens SoapUI forum.
Trial Opens the SoapUI Pro Trial download page.
Preferences Sets global soapUI preferences
proxy Apply proxy defined in global preferences
Find Searches the soapUI support forum
Help browser Show online help

Log Inspectors
● Firstly, soapUI Log
● Secondly, HTTP Log
● Subsequently, Jetty Log
● Moreover, Error Log
● In addition, Wsrm Log
● Lastly, Memory Log

In SoapUI, the work is organized into projects. These are further displayed under the
root node in the workspace navigator. However, a project can contain any number of
functional tests, load tests, and service simulations.

Hence, the project structure is as

● Firstly, create a workspace. There can be several projects associated with a workspace.
Users can create more than one workspace. In SOAP UI Pro version, we can seamlessly
switch environments to map it to different endpoints.
● Secondly, for each project, we can create several test suites.
● Thirdly, for each Test Suite, there can be several test cases attached to it.
● Lastly, for each Test Case, there can be several test steps associated with it.
Project Types
There are three main types of projects in SoapUI:

● SOAP Projects – SOAP projects can be created from a WSDL file or single service call. You
can use these projects to test every aspect of your SOAP services, verify that the services
support commonly used standards such as WS-Security, WS-Addressing, and MTOM,
create functional and load tests, and much more.
● REST Projects – REST projects can be created from WADL file or, directly, URI and its
parameters. You can use these projects to test RESTful services, create various requests
and check the information you receive, give a try to a multitude of methods and operations,
and so on.

Creating a Workspace
● All the artifacts which will be created, from now on would be contained in this workspace.
● Enter a name for the workspace and click ‘OK.’
● Now the user has to select the path where this workspace has to be saved.
● Select the path where the workspace has to be saved
 ● The name of the workspace XML, which has to be located when the user wants to open the
workspace in the future.
● Click ‘Save’.

Add Project to Workspace

There are two ways to add a project to the workspace:

● By creating a new project

● By importing an existing local, composite, packed, or remote project

Create a New Project

● To create a new SOAP project, select File > New SOAP Project. Specify the name for your
new project and the WSDL file that SoapUI will use for the initial configuration, then select
the necessary options.
● Click OK. SoapUI will generate the service and, optionally, test suite and mock service.
● To create a new REST project, select File > New REST project. Specify a URI to use for the
project generation in the subsequent dialog and click OK.
● You can also click Import WADL to switch to the New WADL project dialog. With this dialog,
you create a REST project based on WADL.
● To create a new empty project, select File > Create Empty Project. It will immediately appear
in the Navigator, and the editor for the project will become available in the Workspace.

Import Project
By Local Project File

● To import an existing project file from your computer: Select File > Import Project.
● Specify a path to the project XML file, or click Browse and navigate to the file manually.
● Click OK.

By Local Packed Project

● To import an existing packed project ZIP file from your computer: Select File > Import
Packed project.
● Specify a path to the project ZIP file, or click Browse and navigate to the file manually.
● Click OK.

By Local Composite Project

● To import a composite project consisting of multiple files: Select File > Import Project.
● Specify a path to the folder that contains the project files, or click Browse and navigate to the
folder manually.
● Click OK.

To Import Remote Project

● To import a remote project (for example, a tutorial, demonstration, bug report, and so on)
using HTTP:
● Select File > Import Remote Project.
● In the subsequent dialog, specify an URL that leads to the project.
● Click OK. SoapUI saves all changes you apply to the imported remote project to the local
copy.

Create new Project-

-------------------

-->Creating SOAP project- adding WSDL during creation or after

-->Request and Response verification
-->Working with TestSuites, TestCases and TestSteps

---
--> this is not simple xml file.if it simple xml file any one can hack it.suppose some guys having
wrong intention immediately he can access the particular information ,whatever the data we are
getting from this particular server they can attack and get the information. To avoid this kind of
things u can see that 3 important thing is their.
soap envelope
soap header
soap body
these are the 3 soap envelope tags are available

if interviewer ask questions-

---------------------------
what are the different envelope tag is available in soapui?

ans-
----
there are 3 envelope tag is available
-->envelope
-->header
-->body

due to these things the web services providing some security that no one can hack it.

Working with TestSuites,Test Cases and Test Steps-->

----------------------------------------------------
what is Test suites?
ans-
A test suite is a collection of test cases.

What is Test Cases?

ans-
A TEST CASE is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly.

what is Test Steps?

ans-
Test Steps describe the execution steps and expected results that are documented against
each one of those steps. Each step is marked pass or fail based on the comparison result
between the expected and actual outcome.

After explian
---------------
Hierchy of Test Suites
----------------------
Project

Test Suite1
Test Cases1
Test Cases2 Test Steps 1,Test Steps2,Test Step3,Test Steps...n
Test Cases n
 Test Suite2
Test Cases1
Test Cases2 Test Steps 1,Test Steps2,Test Steps3,Test Steps...n
Test Cases n
Test Suite n
Test Cases1
Test Cases2 Test Steps1,Test Steps2,Test Steps3,TestSteps...n
Test Casesn

AMF(actionscript messgaing format)

The AMF TestStep can be used for sending AMF remote calls over HTTP (AMF being Adobes
ActionScript Messaging Format used by Flash/Flex applications to interact with a server backend).

The new AMF TestStep lets you perform call to AMF server with access to all the XML-related
bells-and-whistles (assertions, property-transfers, etc) .

Assertions in soapui-:
----------------------

Contains
-----------
What ever the values u are putting it will check the values is contain or not
Use 11

Not contains
-----------------
Checks for the non-existence of the specified string.

Xpath match
------------------
It compares the result of an XPath expression to an expected value.
It is mainly used for compare xpath

One of them is the schema URL and the other corresponds to the actual web service URL.
//ns1:AddResult

Xquery match
-------------------
XQuery uses an XQuery expression to select content from the target property. It compares
the result of an XQuery expression to an expected value.
{
XQuery​ is a functional programming and query language that is used to query a group
of XML data. ​XPath​ is a xml path language that is used to select nodes from an xml
document using queries. ... ​xpath​ was created to define a common syntax and behavior
model for xpointer and xslt.
}

Valid HTTP Status Code

---------------------
The Valid HTTP Status Codes assertion checks whether the target test step received the HTTP
result with a status which is on the list of defined codes.

Invalid HTTP Status codes

-------------------------
The Invalid HTTP Status Codes assertion checks whether the target test step received the
HTTP result with a status code which is not on the list of defined codes.

Not SoapFault
-------------
The Not SOAP Fault assertion checks whether the last response you have received does not
contain a SOAP Fault element.

Schema compliance
-----------------
The Schema Compliance assertions check whether the last request or response follows the
associated WSDL schema definition. This schema can be taken from the service definition.

Soap fault
---------------
Validates that the last received message is a SOAP Fault

SLA
=====

WS-Adressing Response
---------------------
The WS-Addressing Response assertion checks whether the last response you have received
contains valid WS-Addressing headers.

WS Security Status
------------------
The WS-Security Status assertion checks whether the last request or response you have
received contains valid WS-Security headers.

Script asserrtions
------------------
The Script assertion runs a groovy script to perform custom checks on the message. Use it to
verify the message content, headers, properties and other components.

If u purchase paid version soapui pro then u will get groovy template
In this situation you no need to write these script

def display
log.info("hello everyone")

Validate a certain response time

// check that response time is less than 400 ms

assert messageExchange.timeTaken < 400

SLA
----
The Response SLA assertion checks whether the response arrives within the specific time limit.

JMS
---
Use JMS assertions to verify that no JMS errors occur and the response comes within the
expected time
-->JMS Status
----------
he JMS Status assertion checks whether the JMS request of the target test step has been
executed successfully.

-->JMS Timeout
-----------
The JMS Timeout assertion verifies that the JMS statement of the target test step does not take
longer than the duration you have specified.

Sensitive Information Exposure

-------------------------------
The Sensitive Information Exposure assertion checks whether the last message received
exposes sensitive information about the target system. For example, if the response gives away
the database version in the error message, a hacker can use this information to exploit known
database security issues.

Properties
=========
Properties can be used as variable to store values

Properties can be accessed as following levels

1)project
2)test suite
3)test cases
4)test step

Load testing
==========
A ​load test​ is type of software ​testing​ which is conducted to understand the behavior
of the application under a specific expected ​load

Load testing is performed to determine a system's behavior under both normal

and at peak conditions.

Create one load test

Play the load test

Add load assertion
----------------------------
Tps(transaction per second)
-------------------------------------------
How many transactions executing per second

Max error
--------------
How many max error u get

Let’s understand the Load Performance Testing Basics.

Load or performance testing is artificially creating or simulating load and

measuring how your environment handles it. This implies it does not necessarily
have to be how a system performs under high load. However, it can also be how it
performs under baseload or expected load. Moreover, it doesn’t even have to be
structured, automated or created in a tool like SoapUI.

Various definitions of performance testing-

● Firstly, Baseline Testing – this can be defined as pure performance testing. Goal: Find
metrics for system performance under normal load.
● Secondly, Load Testing – Load testing includes increasing the load and see how the
system behaves under higher loadGoal: Find metrics for system performance under
high load.
● Subsequently, Stress Testing – The goal of a stress test is exactly that, to find the
load volume where the system actually breaks or is close to breaking. Goal: Find the
system breaking point.
● Further, Soak Testing – To find system instabilities that occur over time, you need to
run tests for a long period. Goal: Make sure no unwanted behaviour emerges over a
long period of time.
● Lastly, Scalability Testing – The purpose of scalability testing is to check whether
your system scales appropriately to the changing load. Goal: Find metrics and check
if the system performance changes appropriately to the load.

Load Testing in SoapUI

Let us understand Load Testing in SoapUI. In SoapUI, LoadTests are based on
existing functional TestCases. A LoadTest runs the TestCase repeatedly for the
specified time with a desired number of threads. Moreover, LoadTests are shown
in the Navigator as children to the TestCase they use.
You can create any number of LoadTests for your TestCase by using the New
LoadTest command. You can find it in the context menu in the Navigator panel, or
on the TestCase editor toolbar.

After you created a LoadTest, SoapUI will open its editor automatically. You can
also open the editor any time by double-clicking a LoadTest in the Navigator.

This testing usually identifies –

● Firstly, the maximum operating capacity of any application.

● Secondly, determine if the current infrastructure is sufficient or not.
● Subsequently, sustainability with respect to peak user load
● Lastly, a number of concurrent users that can be easily supported.

Let’s understand LoadTest Execution. SoapUI allows you to run your LoadTest
with as many threads as your hardware can manage. Further, it depends mainly
on memory, CPU, target service response-time, and other factors. Now, set the
desired value and start the LoadTest with the Run button at the LoadTest editor
toolbar.

However, the underlying TestCase is cloned internally for each configured thread
and started in its own context. Subsequently, the TestCase will access a unique
“copy” of the TestCase and its TestSteps which avoids threading-issues at the
TestStep and TestCase level.

The LoadTest will run as configured until it terminates due to one of the
following:

● Firstly, it has reached its configured limit.

● Secondly, it has been cancelled by the user with the Cancel button on the LoadTest
toolbar.
● Lastly, it has been cancelled by a LoadTest Assertion when the maximum number of
allowed errors for that assertion has been passed.
● .

Add an assertion to the LoadTest

● First of all, In the LoadTest editor, switch to the LoadTest Assertion tab:
● Secondly, click plus-btn.png Add Assertion button in the LoadTest Assertion menu
bar to add a new assertion
● Subsequently, in the subsequent dialog, select the assertion type to add. Let’s choose
Step Maximum. This assertion sets the maximum allowed response time. If some
request is executed longer, the test will fail. This is a good way to establish and check
some SLA for your web service. Click OK
● Further, SoapUI will display the dialog box, where you can specify the assertion
properties. Enter the maximum response time in the Max Time edit box. By default, it
has 1000 milliseconds (that is, 1 second). Let’s keep the default value and click OK
● In addition, the Step Maximum assertion is now added to the test
● Lastly, now run the test again. If some responses will work longer than 1 second, you
will see numbers in the err column. This indicates that your test fails.

TPS / BPS Calculation

Let’s understand the TPS / BPS Calculation. Calculation of the different values in
the Statistics table is straight-forward for all columns except TPS (transactions
per second) and BPS (bytes per second). These two can be calculated in two
different ways-

● Firstly, based on the actual time passed (default):

● Secondly, TPS: CNT/Seconds passed, i.e. a TestCase that has run for 10 seconds and
handled 100 requests will get a TPS of 10
● Subsequently, BPS: Bytes/Time passed, i.e. a TestCase that has run for 10 seconds
and handled 100000 bytes will get a BPS of 10000.
● Further, based on average execution time:
● After this, TPS: (1000/avg)*threadcount, for example, avg = 100 ms with ten threads
will give a TPS of 100
● Lastly, BPS: (bytes/CNT) * TPS, i.e. the average number of bytes per request * TPS.

Example
A TestCase with two groovy scripts. The first sleeping for 900ms and the second
for 100ms. So, we’ll run this with 10 threads for 10 seconds, which theoretically
should result in 100 executions of our TestCase;
With TPS being calculated on time passed, the value is the same for both
TestSteps. Since it executes the same number of times during our 10 seconds.
Their individual execution speeds do not affect this value.

Now let’s change the way TPS is calculated to be based on average (in the
LoadTest Options dialog):
So, if we now run the test we get the following:

Here is the hypothetical TPS for the first teststep is calculated to be 11, Since
with 10 parallel runs the average time was 909ms. The second teststep gets 100
TPS. Once again calculated with 10 parallel runs which took 99ms on average (if
this was sustained performance we could theoretically have “squeezed in” 100
requests in each second).

Which of these two to use is up to you; with single step TestCases you should
get roughly the same result from both, but when your TestCases contain many
steps, both ways have their pros and cons (as illustrated above).

Statistics Graphs

Let’s understand Statistics Graphs. There are two types of graphs available from
the LoadTest Toolbar during execution; statistics and statistics history. The main
purpose of these is to visualize selected statistics over time to be able to detect
sudden and unexpected changes. However, the display of statistics is relative
(not absolute). Therefore, the graphs are not very useful for analyzing exact data.
So, both graphs have a Resolution setting which controls how often the graph is
updated. So, setting this to “data” will update the graph with the same interval as
the Statistics Table Alternatively, if you want one of the fixed resolutions select
these.

The Statistics Graph shows all relevant statistics for a selected step or the entire
testcase over time. Further, this allows you to see how values changes. For
instance, increase the number of threads-

As you can see the green line (threads) jumps up after half the test, which also
causes an expected jump in average and a minor change in transactions per
second. the later meaning that although we increase the number of threads we
don’t get a corresponding increase in throughput (since the average response
time increases).

The Statistics History Graph shows a selected statistic value for all steps
allowing you to compare them and see if the distribution of any value between
teststeps changes over time. For the same test we can compare the avg over
time:

The graph above contains one line for each TestStep in our TestCase shown with
the same color as the TestStep in our Statistics table:

As we can see the average changes similarly for both TestSteps when the
number of Threads increases.
SoapUI Load Strategies

The different Load Strategies available in SoapUI and SoapUI Pro allow you to
simulate various types of load over time. Further, this enables you to easily test
the performance of your target services under a number of conditions. Since
SoapUI also allows you to run multiple LoadTests simultaneously, a combination
of LoadTests can be used to further assert the behavior of your services.
Therefore, select the desired Strategy for your LoadTest from the Strategy
Toolbar in the LoadTest Window:
SoapUI Load Strategies: Simple Strategy –
Baseline, Load and Soak Testing
The Simple Strategy runs the specified number of threads with the specified
delay between each run to simulate a breathing space for the server. Further, the
Simple Strategy is perfect for Baseline testing. So, use it to assert the basic
performance of your service. Also, validate that there are no threading or
resource locking issues. Now, ramp up the number of threads and use the
strategy for long-running soak tests.

SoapUI Load Strategies: Fixed Rate

Strategy
The Simple Strategy doesn’t guarantee a number of executions within a certain
time. The “Request Level” setting will attempt to maintain the TPS on the request
level instead. For instance, if you have a data-driven LoadTest or a TestCase with
many requests. Then, you want the TPS setting to apply not on the execution
level of the entire TestCase but on the request level.
In any case, the Fixed Rate strategy is useful for baseline, load and soak-testing if
you don’t run into the “Thread Congestion” problem described above. On the
other hand, you might provoke the congestion (maybe even in combination with
another LoadTest) to see how your services handle this or how they recover after
the congestion has been handled.

Variable Load Strategies

There are several strategies that can be used to vary load (the number of threads)
over time, each simulating a different kind of behavior. They can be useful for
recovery and stress testing, but just as well for baseline testing, either on their
own or in combination with other strategies.

Running this with the strategy interval set to 5000 the number of threads will
change every 5 seconds:

Variance Strategy
this varies the number of threads over time in a “sawtooth” manor as configured;
set the Interval to the desired value and the Variance to the how much the number
of threads should decrease and increase.

Burst Strategy
This strategy is specifically designed for Recovery Testing and takes variance to
its extreme. It does nothing for the configured Burst Delay, then runs the
configured number of threads for the “Burst Duration” and goes back to sleep.
Here you could (and should!) set the number of threads to a high value (20+) to
simulate an onslaught of traffic during a short interval. Then, measure the
recovery of your system with a standard base-line LoadTest containing basic
performance-related assertions. Let’s try this with a burst delay and duration of
10 seconds for 60 seconds:

Grid Strategy​ –
This strategy allows the user to specifically configure the relative change in the
number of threads over a defined interval of time. Further, its main use for this is
a more advanced scenario and recovery testing, where you need to see the
service’s behavior under varying loads and load changes.

Both values are stored relative to the duration and actual ThreadCount of the
LoadTest. If you change these, the corresponding Grid Strategy values will be
recalculated. Running the test shows the following output:

Script Strategy
The script strategy is the ultimate customization possibility. The script you
specify is called regularly and should return the desired number of threads.
However, returning a value other than the current one will start or stop threads to
adjust for the change. Further, this allows for any kind of variance of the number
of threads. So, for instance, the following script randomizes the number of
threads between 5 and 15
Statistics Calculation and ThreadCount
Changes
Many of these strategies will change the number of threads which has an
important impact on the statistics calculation. Further, you need to be aware of
when the number of threads changes. This will usually change the response
times of the target services, resulting in a change in avg, tps, etc. But, the
LoadTest has already run at a previous number of threads the results for those
runs will skew the result for the new ThreadCount.

Understanding the Performance

Assertions in SoapUI
Let us understand Performance Assertions in SoapUI. In SoapUI the possibilities
for asserting the performance and underlying functionality are many. Finding the
right mix is not easy. Since LoadTest results are extremely dependent on external
factors, networks, disk activity, database backups, etc. Therefore, we recommend
creating assertions as a “safety net” for your LoadTest to detect.

For example, if you have a step that usually takes around 300ms and you want to
automate the execution of the LoadTest, you could create a “TestStep Average”
assertion at around 900ms, which gives a lot of breathing space. Alternatively,
you could set the level rather low (400ms) but the minimum-errors setting to a
rather high value (100).

Accessing Assertions
Access the assertions for your LoadTest from the Assertions tab at the bottom of
the LoadTest window:
Here you can add and configure as many assertions using the toolbar button.
Further, add the assertion by right-clicking in the Statistics table. Then, select the
desired assertion. After this, double-clicking an assertion opens the
corresponding configuration-panel. Also, this allows you to set its configuration
as desired.

Available Assertions
As you can see on the above screenshot SoapUI provides 5 assertions for
validating the ongoing performance of your services. These all have the following
configuration settings in common:

● Firstly, Name – the name of the LoadTest Assertion.

● Secondly, Minimum Requests – this is the minimum number the target testStep or
testCase must have been executed before the assertion is applied.
● Subsequently, Max Errors- this is the maximum number of failures that are allowed
before the LoadTest fails.
 ● Lastly, TestStep – the target TestStep, all TestSteps or TestCase the assertion should
be applied to.

The available assertions then have specific configuration options as follows:

● First of all, Step Average – asserts that the average value of a TestStep or the entire
TestCase doesn’t exceed the specified limit.
● Secondly, Step TPS asserts the TPS (transaction per second) value for the
corresponding TestStep or TestCase.
● Subsequently, Step Maximum – Asserts the max value for the corresponding TestStep
or TestCase, going over the specified “Max Time” limit fails the assertion.
● Further, Step Status – check that the underlying execution status of the TestStep or
TestCase is successful, otherwise the assertion fails.
● Last but not least, Max Errors – check that the number of failures for the
corresponding TestStep or TestCase does not exceed the configured “Max Absolute
Errors” and/or “Max Relative Errors” value.

Viewing Assertion Errors

When running your LoadTest, assertion failures are shown in the LoadTest Log
as they occur.
The toolbar has combo-boxes for filtering which message to display and also
contains a button for exporting the log to a comma-separated file.

Double-clicking an entry opens the corresponding result for the underlying

TestStep, allowing you to “debug” the failed message exchange, for example
double-clicking the first error in the log above shows.

Security testing
=============

A Security Test is used in soapUI to scan your target services for common security
vulnerabilities, like for example SQL Injections and XML Bombs.
Web Forms Authentication

Let’s start by learning Web Forms Authentication. Some web services require
form based authentication. In order to be able to use API calls, you typically need
to launch a browser, log into a web form, and then establish a session.

Example:

A form that asks for authentication credentials might look like this

<form method=”post” action=”/login”>

Username: <input type=”text” name=”username” required>

Password: <input type=”password” name=”password” required>

<input type=”submit” value=”Login”>

</form>

This would render a HTML form:

SoapUI Test Case

The way to deal with this in SoapUI would be to:

● Create a HTTP Request Step with the appropriate settings (username, password,
method).
● Set the TestStep to keep the session alive with the option Maintain HTTP Session.

Creating HTTP Test Request

In your TestCase, create an HTTP Request Step.

Username is “admin”, and the password “p@ssw0rd” in this case. The HTTP
method is specified as POST.

Maintaining Session

When you have a HTTP Request TestStep that works, you can set the TestCase to
maintain the session provided by the TestStep.

● Open the TestCase window.

● Click Option.
● In TestCase Options, check the Maintain HTTP Session checkbox.
You should now be able to add SOAP and/or REST test steps further in the test
case that will maintain the authenticated session.

Configuration of WS-Security
Let’s understand the WS- Security Configuration. SoapUI manages WS-Security
configurations at the project level. These configurations are useful at several
places within a project:

● Firstly, for outgoing requests and their responses.

● Secondly, for incoming requests to MockServices and their MockResponses.
● Subsequently, for monitored requests and their monitored responses in the SOAP
Monitor.

If you click on the WS-Security Configurations tab on the project level, four
sub-tabs are-

● First of all, outgoing WS-Security Configurations: configurations that should be

applied to outgoing messages.
● Secondly, incoming WS-Security Configurations: configurations that should be
applied to incoming messages.
● Subsequently, Keystores: keystores used for encryption, decryption and signing.
● Lastly, Truststores: truststores used for signature verification.
Steps for encrypting a soap request in
SoapUI
● First of all, add a keystore by clicking the Add button and browsing to your keystore
file.
● Secondly, enter the password for the keystore.
● After this, make sure that the Status is OK. If not, check your password and Status for
errors.
● Subsequently, create a new outgoing configuration by clicking on the add button.
● Further, name the outgoing configuration.
● In addition, now create a new Outgoing configurations entry by clicking on the lower
add button.
● Add an Encryption entry.
● Consequently, select the keystore and key alias (key) that you want to use along with
the password for that alias.
● Now, open the SOAP request that you want to apply the encryption to and click the
Aut tab in the bottom corner and select the outgoing configuration.
● Finally execute the SOAP request and click the Raw tab to verify that the encryption is
added to the outgoing request.

Keystores and Truststores

The Keystores and Truststores tabs allows you to add an arbitrary number of
keystores and truststores to your WS-Security configurations.

Add a new keystore or truststore by selecting the Add button in the toolbar. Then,
browse to the corresponding file and press ok. Now, type the password to the file
and it will be added to the list. The Status column will display if loading goes ok.

The following columns are available in the Keystores and Truststores table:

● First of all, Source: the source file of the keystore / truststore.

● Secondly, Status: the load status of the keystore / truststore.
● Subsequently, Password: the keystore password.
● Further, Default Alias: the default alias (key) to be selected when using the keystore /
truststore.
● Lastly, Default Password: the password for default alias.

Outgoing WS-Security configurations

Outgoing WSS configurations are helpful in processing outgoing messages, like
adding encryption, signature, etc. Each configuration contains an arbitrary
number of entries, each corresponding to some WSS related action to be taken
on the outgoing message.
The following columns are available in the Outgoing WS-Security Configurations
table:

● First of all, Name: a unique name for the configuration.

● Secondly, Default Username/Alias: The default username / alias to be used in entries.
● Subsequently, Default Password: the default password for the username / alias.
● After this, Actor: the actor name.
● Last but not least, Must Understand: marks the header as must understand.

When selecting a configuration in the table, the lower half of the panel will display
a list of applied entries. Now, select the outgoing configuration, in our case an
Encryption and a Timestamp entry. The entries are applied to the outgoing
message from top to bottom in the list. It’s also possible to reorder or remove
entries by using the toolbar buttons.

Entries
These are the possible entries for the Outgoing WS-Security configurations.

Encryption
Encrypts outgoing messages. These are the configurable fields:

● First of all, Keystore: The keystore to use when encrypting the message.
● Secondly, Alias: The alias (key) to use when encrypting the message.
● Thirdly, Password: The password for the alias.
● Subsequently, Key Identifier Type: The type of key.
● After this, Embedded Key Name / Embedded Key Password: If the key identifier type is
Embedded KeyInfo then these fields are used to specify the name and password of
the embedded key.
● Further, Symmetric Encryption Algorithms / Key Encryption Algorithm: The
algorithms to use. If you’re not sure which to choose, leave the preselected item as
default.
● After this, Create Encrypted Key: If checked this will encrypt the symmetric key into
an EncryptedKey.
● Moreover, Parts: By using this table, you are able to encrypt only certain parts of the
outgoing message. If this is not checked the whole message will be encrypted.
● Further, ID: The identifier of the XML element to encrypt.
● Consequently, Name: The name of the XML element to encrypt.
● After this, Namespace: The namespace of the XML element to encrypt.
● Moreover, Encode: Use Content for encrypting the inner parts of the element and
Element to encrypt the whole element.
● Lastly, Observe! This cell is required when using the Parts table.

Signature
Signs the outgoing message. These are the configurable fields:

● Firstly, Keystore: The keystore to use when signing the message.

● Secondly, Alias: The alias (key) to use when signing the message.
● Thirdly, Password: The password for the alias.
● Subsequently, Key Identifier Type: The type of key.
 ● Further, Signature Algorithm / Signature Canonicalization / Digest Algorithm: The
algorithms to use. If you’re not sure which to choose, leave this as default.
● Moreover, Use Single Certificate: If checked, a single certificate will be used.
● After this, Parts: By using this table, you are able to sign only certain parts of the
outgoing message. If this is not checked the whole message will be sign.
● Subsequently, ID: The identifier of the XML element to sign.
● In the same vein, Name: The name of the XML element to sign.
● Further, Namespace: The namespace of the XML element to sign.
● Moreover, Encode: Enter “Content” for signing the inner parts of the element and
Element to sign the whole element.
● Lastly, Observe! This cell is required when using the Parts table.

Username
Add a Username token to the outgoing message. These are the configurable
fields:

● First of all, Username: The username.

● Secondly, Password: The password.
● After this, Add Nonce: Adds a nonce (recommended).
● Subsequently, Add Created: Adds a created element (recommended).
● Lastly, Password Type: This specifies how the password should be serialized. The
PasswordDigestExt option is non-standard and should only be used for interop issues
where the message receiver desires an extra SHA-1 Hash of the password.

Timestamp
Adds a timestamp entry. The configurable fields are as follows:

● On one hand, Time To Live: How long the message is valid. The default unit is
seconds.
● On the other hand, Millisecond Precision: If checked the unit will be milliseconds
instead of seconds.

SAML (Form) – Adds SAML assertion. The configurable fields are as follows:

● First thing first, SAML version: The SAML standard version.

● Secondly, Signed: Check this if you want to sign your assertion.
● Further, Assertion type: The type of assertion.
● Subsequently, Keystore: The keystore to be used when signing.
● After this, Password: The password used by the keystore.
● Moreover, Issuer: The issuer.
● Consequently, Subject name: The subject name.
● Further, Subject Qualifier: The subject qualifier.
 ● In the same vein, Digest Algorithm / Signature Algorithm: The algorithms to use.
● In addition, Attribute name: If the assertion type is Attribute, you can use this field to
specify the attribute name.
● Lastly, Attribute values: A list of values that belongs to the attribute name specified
above.

Adding outgoing configuration explicitly – As an alternative to using the Auth tab

you can right click in a XML view of a request and select the Outgoing WSS menu
item. This will try to generate and add the outgoing WSS to the current XML.

Incoming WSS
Incoming WSS configurations are useful in processing incoming messages like
decrypting and validating signatures of the incoming messages. Since the
WS-Security headers of an incoming message contain most of the information.
Further, this information requires to decrypt or validate a message. The only
configuration needed by SoapUI is which keystore or truststore that should be
used.

The following columns are available in the Incoming WS-Security Configurations

table:

● First thing first, Name: A unique name for the configuration.

● Subsequently, Decrypt Keystore: The crypto used for decryption.
● In addition, Signature Keystore: The crypto used for signature verification.
● Last but not least, Password: The password for the crypto.
Security Testing in SoapUI

Let’s understand Security Testing in SoapUI. The Security Testing features

introduced in SoapUI 4.0 make it extremely easy for you to validate the functional
security of your target services. Further, this allows you to assess the
vulnerability of your system for common security attacks. In addition, this is
especially critical if your system is publically available. Still if that is not the case,
ensuring an altogether secure environment is equally important.

Create a Functional TestCase (or use an

existing one)
We’ll start with the trustworthy included Sample Project. First of all, import it into
your workspace and open the first TestCase:
Adding a Security Test
You can see an empty “Security Tests” node in the left tree. Firstly, right-click it
and select the “New SecurityTest” option, this opens the following dialog

● First of all, “Empty Test” will simply create an empty Security Test, requiring you to
manually configure the desired Security Scans.
● Secondly, “Automatic” will generate a default setup with common Security Scans and
default assertions
 ● Lastly, “Full Control” will give you fine-grained control of which Security Scans to add
and how they should be configured initially

Once added, double-click a Security Test to see its main configuration and
execution window. This window has a layout similar to the TestCase window (top
to bottom);

● First thing first, A toolbar with actions related to execution, reports, etc
● Secondly, a progress bar at the top for tracking progress of the Security Test as it
executes
● Subsequently, a toolbar and list of the TestSteps in the underlying TestCase, with
additional information on execution progress and configured Security Scans for each
TestStep
● In addition, the usual inspectors for adding a description, properties and
setup/teardown scripts to the Security Test
● Now, a number of log tabs for viewing results from the execution of the Security Test
● Lastly, select the “Auto” mode to generate default Security Scans and Assertions for
the TestSteps in your TestCase and press “Next.

A summary of all the Security Scans and Assertions SoapUI will add to the
Security Test are listed, press OK to create the Security Test with the described
configuration and open the Security Test window.

Run the Security Test

To run a Security Test, make sure all your scans are configured as desired.
Further, press the run button in the top left. The following will now happen:

● First of all, each TestStep in the underlying TestCase will be executed and asserted as
usual – the results of the functional test are visible in the “TestCase Log” at the
bottom of the Security Test window
● Subsequently, for each TestStep, its configured Security Scans will be executed also.
Their individual progress and results will be shown in the Security Test window and
the Security Run Log at the bottom of the Security Test window
● After this, run the Test by pressing the green arrow on the top left. After this, you will
see ongoing progress for each TestStep and configured Security Scans in the
Security Test window.
You will see ongoing progress in the main window as the different Security Scans
are executed. Moreover, more detailed information is available in the Security Log
at the bottom.

Analyze the Results

The Security Log at the bottom of the Security Test window shows detailed
information on failed Security Scans, click on a Security Scan in the main window
and the log will scroll to that Scans entries:

Check here for unexpected alerts that might indicate a possible security
vulnerability in your target service. Double click individual entries to see their
actual message exchanges.
Here you can see one of the XPath Injection mutations sent to our logout service
operation.

Learning Security Scans

Security Scans are useful to identify potential security vulnerabilities in your

target services. Each scan sends a number of malicious requests to your service
to try to provoke and identify a behavior that could indicate a security
vulnerability that needs to be handled.

The following Security Scans are currently available (click on the name for a
dedicated page)

● Firstly, SQL Injection : tries to exploit bad database integration coding

● Secondly, XPath Injection : tries to exploit bad XML processing inside your target
service
● Thirdly, Boundary Scan : tries to exploit bad handling of values that are outside of
defined ranges
● Subsequently, Invalid Types : tries to exploit handling of invalid input data
● Further, Malformed XML : tries to exploit bad handling of invalid XML on your server
or in your service
● In addition, XML Bomb : tries to exploit bad handling of malicious XML request (be
careful)
● Moreover, Malicious Attachment : tries to exploit bad handling of attached files
● After this, Cross Site Scripting : tries to find cross-site scripting vulnerabilities
● Lastly, Custom Script : allows you to use a script for generating custom parameter
fuzzing values

Adding Security Scans

Add a Security Scan to a TestStep in your Security Tests. Further, this is easily
done using the “Adding SecurityScan” button or the corresponding TestStep
right-click menu option. After this, it will ask which type of Security Scan to add.
After this, it opens the corresponding Security Scan configuration window:
 ● First of all, Assertions : the assertions are useful to validate and check the response
for any signs of a successful security exploit
● Secondly, Strategy : settings related to how multiple parameters should be
permutated against each other
● Lastly, Advanced : settings specific for the Security Scan (if applicable)

The table of parameters, assertion tab and strategy tab are common for most
Security Scans. So, let’s have a look at them in more detail.

Security Scan Parameters

Most Security Scans require you define the content of the underlying request. For
example for a SOAP request you might have a message as follows:
When performing a SQL Injection scan with this request, you need to send the
malicious SQL statements in both the username and password field. So, this
requires you to define these two as parameters in the table. However, in the Pro
version, you can easily achieve by pressing the “Extract Parameters” button on
the top of the table itself. Further, this will search all available properties in the
request and automatically add them to the table if they contain a value:

Alternatively, you can use the “Add Parameter” button which will open a dialog
for specifying the Parameter manually:
Here you need to specify the following:

● First thing first, the underlying Test Property that contains the parameter value.
● Secondly, a unique label for the parameter.
● Subsequently, An optional XPath statement specifying where in the Test Property
value to find the parameter.
● Last but not least, this is for properties containing XML values.

Security Scan Assertions

Assertions are useful to assess the responses for the Security Scan requests.
Certainly, these requests contain some kind of content that indicates that the
target system has a corresponding vulnerability. Likewise, the mechanism is the
same as for standard Test Requests-use the table in the assertions tab to specify
which assertion to use and their configuration:
All the standard assertions are available, but also a number of new ones have
been added specifically for this purpose.

Invalid HTTP Codes

Allows you to specify a comma-separated list of HTTP status codes that the
target service should return.

Valid HTTP Codes

Allows you to specify a comma-separated list of HTTP status codes that should
return.

System Information Exposure

Checks the response for content that reveals system information which is helpful
to hackers to further exploit any existing vulnerabilities.

The default configuration for this assertion is specific at both the global and
project level. So, if you want to add any custom tokens that are useful in the
search. Then, it can be done either specifically for the containing Security Scan
or at a higher level. After this, soapUI provides the default list. This is visible in
the Global Preferences under the “Global Sensitive Information Tokens” tab.

The table has two columns:

● On one hand, the token itself can either contain a plain string or a regular expression
prefixed with a tilde sign.
● On the other hand, a description that will be shown in the Security Log if the
corresponding token is found.

Cross Site Scripting Assertion

This assertion is available only for the Cross Site Scripting Scan and
automatically adds. Moreover, it checks the response for the same injection
strings that is sent with the parameter. Further, this allows you to specify a script
that populates a list of URLs to check separately for the send XSS tokens:

Strategy
The strategy tab allows you to specify how multiple parameters are to be
permutated and executed during the execution of the Security Scan:

There are currently two modes of execution:

● Firstly, “One by One” – mutates one parameter at a time.

● Subsequently, “All at once” – mutates all parameters at the same time.

The “Request Delay” setting allows you to specify a delay between multiple
mutated requests. So, the Security Scan can’t overload your server. After this, the
“Apply to Failed TestSteps” option allows you to control.

Execution
When a Security Scan is run as part of the containing Security Test. After this, it
sends the different mutation requests as configured. After this, mutating the
defined parameters for each request. Moreover, the Security Log shows
specifically which values were sent for each parameter and request, together with
any assertion failures.

Jdbc request
-=----------------
com.mysql.jdbc.Driver

jdbc:mysql://localhost:3306/database name","user name","password"

query==select * from the database name

Or
Select emp, id, age from database name

Grovvy script for jdbc connection

=========================
query = “SELECT FROM < WHERE ID = 103231”

testRunner.testCase.testSuite.project.setPropertyValue(“JDBC_QUERY”,query)

log.info(query)

tc = projectName.testSuites[‘TestSuite’].testCases[‘MyTestcase’]

tstp = tc.getTestStepByName(‘TestStep’)

runner = tstp.run(testRunner,context)
responseHolder = runner.getResponseContent()

runner = null

resultXml = new XmlSlurper().parseText( responseHolder )

relObjIds = resultXml?.ResultSet?.Row?.collect{it.<>}

relObjectId = relObjIds[0]

testRunner.testCase.testSuite.project.setPropertyValue(“ID”,relObjectId.toString())

=========================================
testRunner - a TestCaseRunner object (javadoc), which is the entry-point to the SoapUI API for
accessing project items, results, etc. The TestRunner is the object that is actually executing the
TestCase by cycling through the TestSteps in the TestCase and executing them.

Script for getting the project name

testRunner.testCase.testSuite.project.name

Get the step name

context.getCurrentStep().getLabel()

Get the Project Name

testRunner.testCase.testSuite.project.name

Restfull testing
=================