The document proposes a data-driven automated testing platform for web services using SoapUI. The platform utilizes Excel files to store test case data, request and response exemplars defined in XML, and Groovy scripts to build requests and validate responses. This allows testing web services in a maintainable and scalable way that is accessible for various roles.

1. Assertive Data-Driven test
Automation for Web Services
SoapUI Automation

2.  Any solution needs to encompass:
◦ Scalability – easy to expand the (test/Web service)
collection
◦ Assertiveness – provides strong outcome assertions, at
Response field level
◦ Accessibility – easy to use, can be used by a wide range
of roles (not just the “specialist”)
◦ Maintainability – easy to maintain the codebase, easy to
maintain the detail & scope of tests
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

3.  How to achieve these objectives?
◦ Develop our own framework
 “Cost” of production – relatively high
 “Cost” of ownership – support, maintenance; relatively high
◦ Leverage a commercial tool
 “Cost” of production – relatively low
 “Cost” of ownership – relatively low
◦ The solution presented here is a variation of the “own framework”
◦ Specific additional benefits:
 High accessibility – BAs, POs and junior project actors. Involve these other roles in the quality story
using a branded tool that is known
 High extensibility – grow tests easily
 Strong validation – takes account of response variations and details
 Business & Tech Actors can get involved – commercial tool which they can use directly
 Still OK for use in CI pipeline
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

4.  In this presentation we look at 2nd option ->
Leverage a commercial tools
 Use SoapUI (free version) – no licencing issues in the
enterprise 
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

5.  Architectural Use Cases:
◦ Test a range of Web Services in detail
◦ Separate the concerns of “data” and “test”
◦ Want to validate the response in detail
 Not just “error code = pass” style
 Need to specify clearly the Request (RQ) part
 Need to specify clearly the Response (RS) part
 Both parts need to deal with messages at the field level
◦ Want the solution to play in an Agile project setting
◦ Want solution to play in DevOps/CI pipeline
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

6.  Overview – the “data” part
 The Excel Tab Pages represent individual “test case collection” (operation tests) that need to be covered
 Each “Name” cell marks an individual test to be applied to an operation – could be a number of “cases” defined up to “stop” word
 Example Web Service: (https://api.flightstats.com:443/flex/flightstatus/soap/v2/airportService)
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

7.  Overview – the architecture
 Require: an exemplar for both RQ and RS for each WS under test
 SoapUI augmented by scripts (Groovy) as well as a specialist Java object
 Java object does all the “heavy lifting” – binding external data and exemplars together to compose a test
 Java object contains the validation logic for tests – applied as specified by external data/test
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]
Data
driving
spreadsheet
SoapUI
Scripts
Java object
Web
Service
WS RQ
Exemplar
WS RS
Exemplar
1
N
N

8.  Overview - the RQ Exemplar
 File naming convention: {InterfaceVendor}_{InterfaceCollection}_{Version}_ExemplarRQ.xml
 Each of the “value” parts in the request is specified with unique names in the form:
◦ ${aaaa.bbbb.cccc…..}
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]
set the scene, the automated data-driven platform proposed can be visualised as shown below:

9.  Overview – the RS Exemplar
 {InterfaceVendor}_{InterfaceCollection}_{Version}_ExemplarRS.xml
 construct from a SoapUI dump file or by copy-pasting directly from SoapUI response window, using any valid RQ for the
operation
 exemplar is used to get the correct set of response namespaces for use in test validation process
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

10.  SoapUI project Layout
 A number of Groovy steps are used in each test case to facilitate the test (starred elements above)
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

11.  Groovy Scripts
◦ Interact with Hub object where the “heavy lifting” is done
◦ Setup the test
◦ Build the specific RQ given the external data and RQ exemplar
◦ Performs the specific RS validation given the external data and RS
exemplar
◦ Performs simple reporting of test outcome
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

12.  Outcome
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

13.  Possible Improvements
◦ Extend to cover RESTful Web Services
◦ Incorporate a better reporting approach
 Extent ?: https://extentreports.com/
◦ Extend to provide test annotations
 Scope tests within a DevOps pipeline
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]

14.  Want to know more?
 https://www.codeproject.com/Articles/1110799/Data-Driven-Web-Service-Testing-with-Assertive-Val
 e: dharrison_ch@yahoo.co.uk
Test Automation of Web Services
(c) 2017-2020 D. Harrison [dharrison_ch@yahoo.co.uk]