Introduction to SoapUI day 1
Download as PPTX, PDF1 like9,999 views
This document provides an introduction and overview of using SoapUI for testing web services. It begins with background on XML, SOAP, REST, and WSDL. It then demonstrates how to create a SoapUI project from a WSDL, view and submit sample requests and responses, validate requests, and create multiple test cases. The document provides guidance on project structure, endpoints, properties, and navigating the SoapUI interface. Finally, it includes an exercise to create test cases for a weather web service.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Introduction to SoapUI day 1 (20)
Ad
More from Qualitest (20)
Recently uploaded (20)
Introduction to SoapUI day 1
- 1. Introduct ion to SoapUI Qu a l i Te s t
- 2. Follow Along with the Slides Slides are located on the Shared Drive at: nsx0862-dm08AED-FTD
- 3. Who are We? Jamie Mitchell - Senior Test Specialist and QA Manager - Architected, Developed and Managed a number of projects with SoapUI - Over 20+ years experience in Testing – eCommerce, finance, healthcare, entertainment, defense, legal, travel, agriculture, education, state registries & databases, utilities, etc… 3
- 4. Introductions (ctd…) Brian Van Stone - Senior Test Specialist - Three years experience automating business processes across varied infrastructure - Load Balancers, Web Infrastructure, Windows/Unix/Linux platforms, Desktop and Web Applications, Source Control Systems 4
- 5. About QualiTest • World’s 2nd largest pure play independent testing company (Nelson Hall - 2012) • QA & Testing focus QA and testing is all that we do! • SLA based Managed Testing services (MTS) Reducing costs, Raising quality, Driving continuous improvement • Right Shore! - Global Service delivery Model Onsite, Onshore, Near-Shore and Offshore • Client centric solutions - Outcome-based testing and pricing Client only pays for testing delivered 5
- 7. Training Agenda • Day 1 – Intro to Protocols & Tool • Day 2 – Data Driven Testing & Assertions • Day 3 – Groovy scripting & Refactoring • Day 4 & 5 – Advanced Topics & Testing Multiple Protocols 7
- 8. Getting to Know You • Who are you? • What’s your background? • What do you do? • What is your experience with SoapUI? • What is your experience with testing web services? 8
- 9. Course Objectives • Strong understanding of Web Services (SOAP & REST) • Imparting the importance of Test Structure, Test Verification and Test Project Management (inputs, environments, results) • A firm understanding of SoapUI. 9
- 10. Key Lessons • Basic Test Creation • Transformation of Keyword Tests to scripted tests. • Basic SoapUI Functionality • Basic Managing a Suite of Tests • A solid understanding of testing web services. 10
- 11. Course Format • This is meant to be a learn along type environment. • The class structure will consist of introductory lessons coupled with on screen demonstration • Individual Exercises will be interspersed. • Questions are Strongly Encouraged!! 11
- 12. Introduction to Web Services GETTING STARTED 12
- 13. What are Web services • A method of communicating between two devices • A software function provided at a network address over the web with the service always on • It has an interface described in a machine-processable format 13
- 14. Some Examples 14
- 15. More examples 15
- 16. Protocols • There are multiple protocols and transport mechanisms for web services- this class will focus on: – SOAP – REST • Before looking at these web services, we need a basic understanding of XML and XML Namespaces 16
- 17. XML • XML stands for eXtensible Markup Language • XML is designed to transport and store data, not to display data • XML tags are not predefined • XML is designed to be self-descriptive • XML does not DO anything. – It is just information wrapped in tags – Need software to send, receive or display it. 17
- 18. XML examples 18
- 19. Another Example 19 Login is parent start tag end tag
- 20. XML Syntax Rules • All XML Elements Must Have a Closing Tag • <p>This is incorrect. • <p>This is a correct.</p> • <p></p> & <p /> are also correct • XML Tags are Case Sensitive • <Message>This is incorrect</message> • <message>This is correct</message> • XML Elements Must be Properly Nested • <b><i>This is incorrect</b></i> • <b><i>This is bold correct</i></b> 20
- 21. XML Rules (cont) • XML Documents Must Have a Root Element <root> <child> <subchild>.....</subchild> </child> </root> • Only the characters "<" and "&" are strictly illegal in XML • <!-- This is a comment --> • White-space is Preserved in XML 21
- 22. Elements and Attributes • Bookstore has an element book • Book has an attribute – category and elements: title, author, year, price 22
- 23. XML Namespaces • XML Namespaces provide a method to avoid element name conflicts and to provide for reusability of elements 23
- 24. Why do we care ? • Errors in XML documents will stop your XML applications • Many of the errors that we find in testing have to do with – Namespace issues – Schema data types – Case – Order – Whitespaces 24
- 25. XPath • XPath (the XML Path language) is a language for finding information in an XML document • XPath is a syntax for defining parts of an XML document • XPath uses path expressions to navigate in XML documents • XPath contains a library of standard functions 25
- 27. SOAP • SOAP stands for Simple Object Access Protocol • SOAP is an XML based protocol for accessing Web Services. • SOAP is based on XML 27
- 28. SOAP • A SOAP message is an ordinary XML document containing the following elements: 28
- 29. SOAP Elements 29
- 30. Example body 30 operation name
- 31. SOAP Syntax Rules • Must be encoded using XML • Must use a SOAP envelope namespace – xmlns:soap="http://www.w3.org/2001/12/soap-envelope" • Must not contain XML processing instructions 31
- 32. SOAP requests defined by WSDL • WSDL stands for Web Services Description Language • WSDL is an XML-based language for describing Web services. • WSDL is written in XML • WSDL is also used to locate Web services 32
- 33. WSDL Document Structure 33
- 34. WSDL Example 34
- 35. Operation Types 35 No output – one way
- 36. Operation Types • Request <> Response • One Way • Solicit < > Response • Notification 36
- 37. REST • REpresentational State Transfer (REST) • Resources are manipulated using a fixed set of four operations -create, read, update, delete : PUT, GET, POST, and DELETE. – PUT creates or updates a new resource, which can be then deleted by using DELETE. – GET retrieves the current state of a resource (read) – POST transfers a new state onto a resource (create). 37
- 38. Using PUT & POST • Either PUT or POST can be used to create a new resource (depends on how your service is defined) – For example creating a new chapter of MPEP (Manual of Patent Examining Procedure) – POST /manual/MPEP/current – PUT /manual/MPEP/current/d0e55397.xml • If you want to update an existing document on the server, then use PUT 38
- 39. Examples • URI: uniform resource identifiers (string of characters to identify resource) • Customer # 18 info: – http://www.thomas-bayer. com/sqlrest/CUSTOMER/18/ • List of invoices – http://www.thomas-bayer.com/sqlrest/INVOICE/ • List of products – http://www.thomas-bayer.com/sqlrest/PRODUCT/ 39
- 40. REST RESPONSES • PRODUCT/30 • INVOICE/14 40
- 41. REST > WADL • Sometimes a REST service has documented information in a WADL • WADL = Web Application Description Language • XML in format • Not Standardized 41
- 42. Sample WADL 42 URI:
- 43. Differences • SOAP REQUEST • SAME AS A REST REQUEST 43
- 44. Differences Attribute SOAP REST Language/Platform Language, platform, and transport independent Only http Environments Works well in distributed enterprise environments Requires point-to-point communication Standardization Standardized Has some standards Error handling Built in error-handling None Format Requires XML Efficient – can use any format Speed Slower Fast (no extensive processing required) 44
- 45. SOAP & REST Responses • REST doesn’t have to use XML to provide the response. REST-based Web services can output the data in – Command Separated Value (CSV) – JavaScript Object Notation (JSON) and – Really Simple Syndication (RSS) • Often when you find a REST service, one of the inputs is the requested format 45
- 46. REST Example • http://api.wunderground.com/api/74e36bb7a 98f6a55/conditions/q/CA/San_Francisco.json • Json Response • XML response 46
- 47. Introduction to SOAPUI USING SOAPUI 47
- 48. Introduction to SOAPUI • Create projects • Add WSDL from sample web service • Setup up security settings • Walk through structure of request and response. • Discuss faults from failed structure vs data errors. • Request structure • Request-level properties • Validating request inputs • Creating multiple requests • Response structure • Working with endpoints 48
- 49. Dashboard 49
- 50. File Menu 50
- 51. 51
- 52. WSDL Settings 52
- 53. Preferences 53
- 54. Editor Settings 54 Tabbed request/response Toggle tabs on/off
- 55. Preferences • Once done with changes, Save Preferences can also import preferences 55
- 56. Create a New Project 56
- 57. 57
- 58. 58
- 59. Can Create Empty Project at this point 59
- 60. Or Add WSDL http://www.webservicex.com/currencyconvertor.asmx?WSDL 60
- 62. This Sample has 2 Versions 62
- 63. SoapUI Parses WSDL SOAPUI looks for port & operation name(s) Input Elements Enums Response 63
- 64. Components 64
- 65. Endpoints • An endpoint allows you to point to different environments for testing • Managing the endpoints can be difficult and it’s very, very easy to test against the wrong endpoint – Manage endpoints within a project – Manage by maintaining Multiple projects – Use environments to manage endpoints – Use workspaces to manage endpoints 65
- 66. Endpoints 66
- 67. A Word About Requests 67
- 68. Renamed 68
- 69. A Word about Project Names • Projects get sorted alphabetically • You can name them anything you want – Having a version or date included in the project name can save you lots of time/frustration later • By default, projects will be saved in My Documents • A saved project is an xml file with the format of project name-soapui-project.xml 69
- 71. Submitting a Request from the Form 71
- 72. Form Request 72 In the form view, you can filter the fields that you want
- 73. Response 73
- 74. Exercise • Create a new soap project and add this wsdl http://www.webservicex.com/currencyconver tor.asmx?WSDL • From the form view, select different currency types from the dropdown and submit the request • View the response in different formats 74
- 75. Structure of the Request 75
- 76. Navigating thru the Structure 76
- 77. Submitting Bad Data 77
- 78. Overview Results View 78
- 79. Complex Types 79
- 80. Faults Structure • Remove one element 80
- 81. Fault - Structure • Duplicate first element 81
- 82. Fault? • Duplicate the entire complex object 82
- 83. Complex Type - Response • Rules for both the request and response are provided in the wsdl 83
- 87. Create Multiple Requests 87
- 89. Validate Request 89 Double click on error to directly navigate
- 91. Exercise • Create new project using wsdl - http://wsf.cdyne.com/WeatherWS/Weather. asmx?WSDL • Look at the structure of the wsdl and create multiple requests for – Valid request – Invalid requests (bad data/bad structure) • Validate the requests before submitting them • Save your work regularly – soap saves internally immediately but no auto save unless you set it up 91
Editor's Notes
- #27: Here are some examples of the syntax for finding specific things within the XML – again we will be using this extensively in the SOAPUI tool
- #37: For the request response operation, the client sends an input request and waits for the response – for the one way operation, the client sends the request but doesn’t wait for a response – this is usually done in the case of a client sending information to the server where it doesn’t matter if every request gets there – for instance if you have a personal weather station that sends weather data to a server that is collecting data from multiple sources – I have a weather station that sends current weather data every 30 secs, so missing a few isn’t a big issue. In the solicit response operation – the request comes from the server and then the client provides the response- these types of operations may happen when you are filling out a form and based on your input additional information is needed. Or it could be used when you sign up for a trial subscription and your subscription is ending, the server can send you a request asking if you want to sign up for the paid service. The notification operation type is used to provide notifications to the client – usually these are operations that the client(customer) signs up for to get the notifications – such as traffic alerts. Notifications are also one way, but one way from the server to the client
- #50: Here is the main screen that comes up when you start SOAPUI – you can set it to not show the start page every time it starts
- #52: For the most part the defaults for the HTTP preference settings are fine – they may change depending on what you are testing. Some of these - Max Response . Size, Max Connections Per Host, Max Total Connections are for load testing. If you don’t care about how long the requests and responses are taking, you can uncheck those boxes to reduce some of the overhead.
- #85: Unfortunately, the wsdl content editor doesn’t allow you to search so if you have a large wsdl and are looking for details about a particular element, sometimes it’s faster just to export it to a file and then search in the file