This document provides an introduction to web services and the API testing tool SoapUI. It discusses what web services are, their components like XML, SOAP, WSDL and UDDI. It describes the architecture of web services including roles like service provider, requester and registry. It explains operations like publish, find and bind. It then introduces SoapUI for testing web services, covering its project structure of test suites, cases and steps. It provides details on creating a project, adding tests, assertions and response time verification. It also briefly mentions the pro version and using SoapUI for security testing through security scans and assertions.

1. Web Services and
Introduction of SOAPUI
Dinesh kaushik
+91-
9555927575

2. Discussion Points
● What are web services?
● Component of web services
● Architecture
● Operations in web service architecture
● Diagram of web service architecture
● Types of web services
● What is SoapUI
● SoapUI test structure

3. Discussion Points(Continued..)
● Creating a new SOAP project
● Adding a TestSuite
● Adding a Test
● Assertion
● SoapUI Pro

4. What are web services
● Web services are the method of communication
between the systems over a network.
● This communication is done over http platform.
● XML is used to encode all communication in form of
XML message.
● It is not tied to any particular Operating system or any
programming language.

5. Components of web services
All standard web services uses the following components.
1. XML
2. SOAP
3. WSDL
4. UDDI

6. SOAP
● Its stand for Simple Object Access Protocol
● It is an XML based protocol for exchanging the
information between the computers.
● It can extend extends HTTP for XML messaging.
● It is an XML way of defining what information gets sent.
● It is platform and language independent.

7. WSDL
● It stands for Web Service Description Language.
● It is a standard format for describing the web services.
● Its definition describe how to access a web service and
what operation it will perform.
● It was developed jointly by microsoft and IBM.

8. UDDI
● It stands for Universal Description,Discovery and
Integration
● It is an XML standard for describing,finding and
publishing the web services.
● It communicate via SOAP,CORBA and Java RMI
protocol.
● It is platform independent and open framework.

9. Architecture
There are three major roles with in web service
architecture.
● Service Provider : It implements the service and make it
available on internet.

10. ● Service Requester : It utilizes existing web service by
opening a network connection and sending an XML
request.
● Service registry : It is a central place where developers
can publish new services or find the existing one.

11. Operations in web service architecture
There are three major types of operations performed in
web service architecture.
● Publish : A service description needs to be published so
that a service requester can find it.

12. ● Find : In this operation,service requester retrieves a
service description directly or queries the service
registry for the type of service required.
● Bind : In this operation,a service requestor use the
binding detail to invoke the service.

13. Diagram of web service architecture

14. Type Web Services
● XML-RPC
● SOAP
● REST

15. What is SoapUI
● SoapUI is a API testing tool which is free and open
source cross-platform for Functional Testing solution.
● SoapUI provides complete test coverage and supports
all the standard protocols and technologies.
● SoapUI allows you to easily and rapidly create and
execute automated functional, load tests and security
testing.

16. SoapUI Test structure
It structures functional tests into three level.
● Test Suites
● Test Cases
● Test Steps

17. Test Suite
● It is a collection of test cases that can be used for
grouping functional tests into logical units
● We can create any number of test suites inside the
soapUI project.

18. Test Case
● It is a collection of test steps that are assembled to test
some specific aspect of your service.
● We can add any number of test cases to a containing
test suite.
● We can even modularize them to call each other for
complex test scenarios.

19. Test Steps
● These are “building blocks” of functional tests in soapUI.
● They are added to a Test Case and used to control the
flow of execution.
● Validate the functionality of service to be tested.

20. Creating a new SoapUI project
● Start SoapUI
● Click on “File”
● Click on “New Soap Project”.
● Add Project Name and URL
● Select the checkbox option
● Click on “OK”

21. New SOAP Project window

23. Adding a TestSuite
● Right click on the name of interface
● Click on “Generate TestSuite”.
● A dialog box will show up where you can customize the
generation

25. Adding a Test
● Expand the tree until the test steps have been unfolded.
● Double click on the test step. A sample request should
appear in the request editor.

27. Assertion
● It gives an indication that your test case has been
passed or failed.
● If we add at least one assertion,it will warn us about the
problem which failed our test case.

28. Adding an assertion
● Click on the label “Assertions” at the bottom of the
request editor.
● This will expand the assertions editor. It is empty.
● Click on the small +-sign at the top of the assertions
editor.
● Select “Property Content assertions.” The first one in
the list is a Contains assertion.

29. ● Let’s use that one. Click on the “Contains” box
● Click on “Add” to add it to the test case.

32. Verify a range
We need the assertion “Range” when value is expected to
change then we need a test that can handle a range
instead of fix value.

33. Steps to add range
● Click on the label “Assertions” at the bottom of the
request editor.
● Click on the small +-sign at the top of the assertions
editor.
● Select “Property Content.”
● Select “XPath match” and click “Add.”

34. ● Click “Declare” in the XPath editor, SoapUI declared
two namespaces for you. They can be called anything.
The two namespaces that were declared are called
soap and ns1.
● Rename ns1 to something more descriptive.
● The next step is to add an XPath3 expression that will
search for the element that contains the conversion
rate.
//Web:ConversionRateResult

36. Verify response time
Verifying the response time is often important. A slow API
is a problem waiting to emerge. Customers will probably
start to complain when you have a lot of traffic and they
don’t get their response quickly enough.

37. Steps to add response time
● Add a new assertion.
● Select “SLA” and “Response SLA.”
● Add it.
● Specify the desired response time.
● Click on “OK”

40. SOAP UI Pro
It comes with several time saving features aimed at making
your testing faster and testing life easier.
● Test Debugging
● Multi Environment Support
● Data Driven
● Reporting

41. Security Testing with SOAP UI

42. Discussion Points
● What is Security Testing
● Purpose of Security Testing
● Security Test in SOAPUI
● Security Scans
● Add Security Scan
● Add New Security Parameters
● Assertions
● Execution

43. What is Security Testing?
● Testing how well the system protects against
unauthorized internal or external access.
● To check whether there is any information leakage.
● Non-functional testing

44. Purpose of Security Testing
The purpose of the security test is to discover the
vulnerabilities of the application so that the developers can
then remove these vulnerabilities from the application and
make application and data safe from unauthorized actions.

45. What is a Security Test in SOAPUI
● A Security Test is used in soapUI to scan your target
services for common security vulnerabilities, like for
example SQL Injections and XML Bombs.
● Security Tests are layered “on top” of an existing
TestCase to which it then applies a configurable
number of “Security Scans” which perform the actual
vulnerability scanning and detection.

46. In the main navigator Security Tests are visible
under a corresponding “Security Tests” node under
the containing TestCase:

47. Security Scans
● SQL Injection : tries to exploit bad database
integration coding
● XPath Injection : tries to exploit bad XML
processing inside your target service
● Boundary Scan : tries to exploit bad handling
of values that are outside of defined ranges
● Invalid Types : tries to exploit handling of
invalid input data

48. Security Scans
● Malformed XML : tries to exploit bad handling of invalid
XML on your server or in your service.
● Malicious Attachment : tries to exploit bad handling of
attached files
● Cross Site Scripting : tries to find cross-site scripting
vulnerabilities

49. Add Security Scan
● Once added, double-click a Security Test to see
its main configuration and execution window:
● A toolbar with actions related to execution,
reports, etc.
● A progress-bar at the top for tracking progress
of the Security Test as it executes.

50. Add Security Scan (Continue)
● A toolbar and list of the TestSteps in the
underlying TestCase, with additional information.
on execution progress and configured Security
Scans for each TestStep.
● a number of log tabs for viewing results from the
execution of the Security Test.

51. Add Security Scan

52. Add Security Scan
● Add a Security Scan to a TestStep in your Security
Tests either with the “Add SecurityScan” button or the
corresponding TestStep right-click menu option in the
Security Test window.
● You will first be prompted for which type of Security
Scan to add (differs based on the underlying TestStep)
and then open the corresponding Security Scan
configuration window:

53. Add Security Scan

54. Security Scan Parameters
● Most Security Scans require you define which content
of the underlying request you want to use as
placeholders for the corresponding scan, for example
for a Rest request you might have a message as
follows:
● When performing for example a SQL Injection scan with
this request, you would want to send the malicious SQL
statements in OS, User Id, Deal Id and version fields,
which would require you to define these four as
parameters in the table.

55. Adding New Security Parameters

56. Adding New Security Parameters
Here you need to specify the following:
● The underlying Test Property that contains the
parameter value (for example Request for Rest
requests).
● A unique label for the parameter.
● An optional XPath statement specifying where in the
Test Property value to find the parameter.

57. Add Assertions

58. Add Assertions
● The top of the dialog usually contains a table for
defining which parameters in the request to use for test
testing (see below).
● In the middle there is an area for Security Scan specific
configuration components (not used in the above
screenshot).

59. Add Assertions
At the bottom there are a number of tabs for further
configuration:
● Assertions : the assertions used to validate and check
the response for any signs of a successful security
exploit
● Strategy : settings related to how multiple parameters
should be permutated against each other (see below)
● Advanced : settings specific for the Security Scan (if
applicable)

60. Security Scan Assertions
● Assertions are used to assess if the responses for the
Security Scan requests contain some kind of content
that indicates if the target system has a corresponding
vulnerability.
● All the standard assertions are available, but also a
number of new ones have been added specifically for
this purpose.

61. Security Scan Assertions
● Invalid HTTP Codes : Allows you to specify a comma-
separated list of HTTP status codes that should not be
returned by the target service. e.g 500, 404, 403.
● Valid HTTP Codes : Allows you to specify a comma-
separated list of HTTP status codes that should be
returned. e.g 200, 201, 202

62. Invalid HTTP Codes

63. Security Scan Assertions
● System Information Exposure : Checks the response for
content that reveals system information which could be
used by hackers to further exploit any existing
vulnerabilities, for example if the response gives away
which database version that is being used (in an error
message), hackers could use this information to try to
exploit known security issues with that database.

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

65. Execution

66. Any Questions

67. Thanks