Functional Testing of Webservices

Presented by Kushan Athukorala

2

Agenda

• Functional Testing of Webseriveces• TestSuites• TestSuite Runner• Generating Reports• TestSuite Coverage• TestCases• TestSteps• Asertions

3

Functional Testing of Web Services

• Types of Functional Web Service Tests in soapUI• Unit Testing

• Validate that each Web Service operation functions as stated

• Compliance Testing• validate that the Web Service returns results compliant with its definition

• Process Testing• validate that a sequence of web service invocations fulfil a required

business process

• Data Driven Testing• validate that any of the above works as required with data input from

external sources (for example a database or another web service)

4

Web Service TestSuites

• TestSuite serves as container for an arbitrary number of TestCases

• When running a TestSuite the contained TestCases can be executed either in sequence or in parallel

5

Generating TestSuites

• Selecting the "Generate TestSuite" option from the Interface menu prompts to generate a complete TestSuite for the selected interface.

6

Clone TestSuite

• Select clone a TestSuite from the TestSuite menu• We can clone the full test suite to a different project as well

7

TestSuite Runner

• Double Clicking a TestSuite in the navigator opens the TestSuite Runner

• There are two ways to run a TestSuite• Run in Sequence : Toggles if the TestCases should be run in

sequence • Run in Parallel : Toggles if the TestCases should be run in

parallel

• Setup and TearDown scripts• Setup Script - A Groovy script to run when the TestSuite is run • TearDown Script - A Groovy script to run when the TestSuite

finishes

8

Generating Reports (soapUI Pro only)

• In Pro Version we can export the suite results as a HTML Report.

9

TestSuite Coverage (soapUI Pro only)

• This feature allows you to see how much of Webservices are being covered by your tests

10

TestCases

• soapUI supports functional testing of web services by providing you to create TestCases

• A TestCase consists of number of TestSteps which can be executed in sequence.

11

Clone TestCases and TestSteps

• soapUI makes ease the TestCase design by cloning• You can clone TestCases as well as TestSteps

12

TestCase Editor Toolbar

• Run Continuously• TestCase Credentials

• Can give domain credentials for each test prompts to set the credentials to be used by all requests in the TestCase.

• This is useful if you want to run your tests with different domain credentials

• TestCase Endpoint• This is useful if you want to run your tests against different

servers

13

TestSteps

• A soapUI TestCase consists of an arbitrary number of TestSteps that are executed after each other

• Types of TestStepsStep Type Short Description

Request Sends a SOAP request and allows the response to be validated using a variety of assertions.

REST Request Step Executes a REST Request to a Resource defined in the project

HTTP Request Step Executes and arbitrary HTTP request

Property Transfer Used for transferring property values between two test steps.

Groovy Script Runs a Groovy script that can do more or less "anything".

Properties Used for defining global properties that can be read from an external source.

Conditional Goto Allows any number of conditional jumps in the TestCase execution path. Conditions are specified as XPath expression and applied to the previous request steps response.

Delay Step Pauses a TestCase run for the specified number of milliseconds

Run TestCase Step Runs another TestCase from within an existing one

MockResponse Step Waits/Listens for an incoming SOAP Request that can be validated and return a mock response

DataSource Step Reads external data to be used as input to requests, etc - soapUI pro only

DataSourceLoop Step Used together with a DataSource to specify looping for external data rows - soapUI pro only

DataSink Step Writes properties to an external storage - soapUI pro only

DataGen Step Generates property values - soapUI Pro only

14

Test Requests

• soapUI defines following Request Steps• SOAP Test Requests - calls a WSDL Operation defined in the

project • REST Test Requests - calls a REST REsource defined in the

project • HTTP Test Request - calls an arbitrary HTTP service • JDBC Test Request - calls an arbitrary HTTP service • AMF Test Request - calls an arbitrary HTTP service • More to come ...

15

Test Requests Assertions

• soapUI has the ability to assert the content of response messages

• Note - Assertions marked with a (*) are "singular assertions", meaning that they can be added only once to a TestRequest

Type Description

Schema Compliance * Validates the response message against its xml schema

Simple Contains Checks for the existence of a token

Simple Not Contains Checks for the non existence of a token

SOAP Fault * Checks that the response is a soap fault

Not SOAP Fault * Checks that the response is not a soap fault

SOAP Response * Checks that the response is valid SOAP Response

Response SLA * Checks the response time to be under a specified value

XPath Match Matches the result of a specified XPath expression against a predefined value

XQuery Match Matches the result of a specified XQuery expression against a predefined value

Script Assertion Allows a custom Groovy script for asserting the message exchange

WS-Security Status * Checks that incoming WS-Security processing was successful

WS-Addressing Response Assertion Checks that the response has valid WS-A header properties

WS-Addressing Request Assertion Checks that the request has valid WS-A header properties

16

Schema Compliance Assertion

• The Schema Compliance assertion checks that the response is compliant with the response messages XML Schema definition

17

Simple Contains Assertion

• The "Simple Contains" assertion simply checks for the existence of a specified substring in the received response

18

Simple NotContains Assertion

• The Simple NotContains assertion simply checks for the non-existence of a specified substring in the received response

19

SOAP Fault Assertion

• The SOAP-Fault assertion simply checks that the received response is a SOAP Fault

20

Not Soap Fault Assertion

• The Not SOAP-Fault assertion simply checks that the received response is not a SOAP-Fault

21

SOAP Response Assertion

• Validates that the response is a valid SOAP Message

22

Response SLA Assertion

• The Response SLA assertion simply checks that the response time is under the configured limit

23

WS-Security Status Assertion

• The WS-Security Status assertion checks that the incoming message has valid WS-Security headers

24

Thank You

25

USA INDIA SRILANKA UK

www.virtusa.com

© V I r t u s a C o r p o r a t i o n

"Virtusa" is a trademark of the company and a registered trademark in the EU and In India. "Productization" is a service mark of the company and a registered service mark in the United States.

"vRule" is a service mark of the company.

For more information please contact SalesInquiries@virtusa.com