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.
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]
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]