Soap UI - Getting started
•Descargar como PPTX, PDF•
4 recomendaciones•2,128 vistas
Lesson 1 http://www.qualitestgroup.com/
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (10)
Similar a Soap UI - Getting started
Similar a Soap UI - Getting started (20)
Más de Qualitest
Más de Qualitest (20)
Último
Último (20)
Soap UI - Getting started
- 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
Notas del editor
- Many organizations use multiple software systems for management. Different software systems often need to exchange data with each other, and a web service is a method of communication that allows two software systems to exchange this data over the internet. The software system that requests data is called a service requester, whereas the software system that would process the request and provide the data is called a service provider. Different software might be built using different programming languages, and hence there is a need for a method of data exchange that doesn't depend upon a particular programming language. Most types of software can, however, interpret XML tags. Thus, web services can use XML files for data exchange. Rules for communication between different systems need to be defined, such as: How one system can request data from another system Which specific parameters are needed in the data request What would be the structure of the data produced. Normally, data is exchanged in XML files, and the structure of the XML file is validated against an .xsd file. What error messages to display when a certain rule for communication is not observed, to make troubleshooting easier
- Google search is one example of a web service – google sends out multple web service request to pull back the information from multiple sources at the same time
- Weather.com serves up content based on your specific location; sales tax is(and shipping charges are calculated based on where you live) stock quote pages also serve up information based on specific requests
- Let’s review a bit about XML before we start looking at the SOAP and rest requests
- Here are a couple of simple XML examples – in the example on the left we have a catalog of CDs – note that the pattern repeats for each CD – there is a parent object CD which has the elements of title, artist, country, company, price and year – all of these are repeated with different data; elements are everything from the start tag to the end tag
- In this example in login is the parent of the elements UserName and Password
- In XML, it is illegal to omit the closing tag. All elements must have a closing tag: XML tags are case sensitive. The tag <Letter> is different from the tag <letter>. Opening and closing tags must be written with the same case In HTML, you might see improperly nested elements: <b><i>This text is bold and italic</b></i> In XML, all elements must be properly nested within each other: <b><i>This text is bold and italic</i></b>e:
- XML documents must contain one element that is the parent of all other elements. This element is called the root element.
- There are elements and attributes defined in XML- the attribute is inside the < > of an element – in this case book has the attribute of category – attributes can get lost sometimes in the XML, so something to consider when testing.
- In this XML file we have 4 different name spaces; urn, urn1, urn2, urn3 – urn is used for the operation names which the others are used for the details
- While each of these seems like a small thing, we have to remember that web services are machines exchanging information, so that information has to be very - precise other wise the receiving machine could be confused about what to do with it – even a simple thing such as a whitespace at the end of a name >Smith < instead of >Smith< could cause a new record Smith (with the space) to be created in the DB because a match wasn’t found
- We are mentioning Xpaths here as they are used extensively in the SOAPUI tool
- 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
- SOAP, originally defined as Simple Object Access Protocol, is a protocolspecification for exchanging structured information in the implementation of web servicesin computer networks. It relies on XML Information Set for its message format, and usually relies on other application layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
- This XML-based protocol consists of three parts: an envelope, which defines what is in the message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing procedure calls and responses. SOAP can be used over any transport protocol such as HTTP, SMTP, TCP, UDP, or JMS.
- There are only 2 parts of a SOAP message that are actually required, the Envelope and the Body – while not required, SOAP does have a built in mechanism for handling faults- these are typically issues that conflict with the schema of the SOAP request itself
- Example of a soap request containing the envelope and the body – in this example, the header contains no elements, but since it’s a required field it shows up as a null value. The body elements are between the 2 purple highlighted sections – the operation name is the name that will be called when you want to call the soap request. A soap definition can contain one or more operations–
- The SOAP syntax rules are important because if they are followed the SOAP request will be rejected and fail
- SOAP Messages are defined in a WSDL WSDL stands for Web Services Description Language. WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes.
- WSDL Ports The <portType> element is the most important WSDL element. It describes a web service, the operations that can be performed, and the messages that are involved. The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language. WSDL Messages The <message> element defines the data elements of an operation. Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language. WSDL Types The <types> element defines the data types that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types WSDL Bindings The <binding> element defines the data format and protocol for each port type..
- We can actually start static testing of a web service just by inspecting the wsdl – if an element is defined as a string, but we need it’s supposed to be a boolean, we can question the implementation and if the wsdl shows a minOccurs = 0 for a field that should always be required, we also know that there is likely to be an issue.
- The wsdl can define the operation types for the request as well – the request-response is the most common type where a request will be sent and the sender will wait for a response – normally there is some sort of timeout where if the response doesn’t come back within a certain amount of time then the request will error out. For the one-way operation, a request is sent but no response is expected, the sender makes the assumption that the requested operation will be processed.
- 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
- RESTful web services are built to work best on the Web. Representational State Transfer (REST) is an architectural style that specifies constraints, such as the uniform interface, that if applied to a web service induce desirable properties, such as performance, scalability, and modifiability, that enable services to work best on the Web. In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web. The resources are acted upon by using a set of simple, well-defined operations. The REST architectural style constrains an architecture to a client/server architecture and is designed to use a stateless communication protocol, typically HTTP. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations you must provide additional information in special ways, but most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks..
- A PUT Request usually includes the whole path to the resource, where a POST request just sends it to the server and lets the server determine the actual location ; if you use 2 POSTS in a row with the same parameters, it will create 2 new instances; if you use 2 PUTS in a row, it will either create new (if doesn’t exist) or updating the existing resource, but not create another instance
- REST requests can be typed directly into the URI in a web browser to get the response- they are very lightweight and very quick
- Typing in http://www.thomas-bayer.com/sqlrest/INVOICE/14/ into your browser will return information on invoice 14 and entering http://www.thomas-bayer.com/sqlrest/PRODUCT/30/ will return the name and price of product 30. In this case, the response is XML
- WADL is pronounced ‘waddle’
- The service is described using a set of resource elements. Each resource contains param elements to describe the inputs, and methodelements which describe the request and response of a resource. The request element specifies how to represent the input, what types are required and any specific HTTP headers that are required. The response describes the representation of the service's response, as well as any fault information, to deal with errors. This is an example of a WADL description for the https://tmog.uspto.gov application.
- As you can see the REST request is much smaller, has less baggage, but also less structure
- Other differences include the transport layer used, how it’s used and how efficient it ; Just to review a few of the differences by attribute are based on Language, environments, standardization, error handling, format & speed
- One of the biggest differences between SOAP & REST requests are that the output in SOAP is always XML, but the format of the output for REST can be varied for the applications
- Using this REST call in a browser you can change the ending to be .json to get a json response or .xml to get the XML response
- 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
- Almost everything you want to get to is under the File level menu – for everything else, right-click the element
- 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.
- The Sample Values will generates example values in requests when creating from schema – which is useful sometimes depending on how clearly defined the schema is in the wsdl. If you have a lot of optional fields that aren’t used a lot, you can uncheck the box to always include optional elements when creating a request. The Name with Binding Tells SoapUI to name imported interfaces with the name of their corresponding soap/http binding, and not with their portType This ensures that WSDL containing bindings for both SOAP 1.1 and SOAP 1.2 will get unique names during import..
- Some of the SoapUI preferences are important – these are the UI settings by default – for example, save all projects on exit – you also might want to consider setting up the backups and autosave- (note however with the auto-save, you will get popups for new projects creating during the window of time) this is also where you can turn off the startup page if you don’t want it to show up all the time.
- If you select the checkbox for the tabbed request view, the request and response will be on different tabs
- Select File > New Project
- Select File > New Project And then you can select the type of project you want to create
- For a Soap Project, a dialog box pops up – enter the project name and browse to the wsdl
- There are 2 versions of the same service in this wsdl – one for soap 1.1 & one for soap 1.2 – version 1.2 came out in 2003 so if you want, delete the older one. The older one is maintained for purposes of backward compatability.
- The port type name is CurrencyConverterSoap, the operation name is ConversionRate, there is an input and output; there are 2 input elements both of type Currency and the Currency element is defined as an enum type and the response has one element defined as a double
- Under each component is an operation name and by default a request is created for each operation. You can look at the requests in a form or in XML. The endpoint as defined in the wsdl is also loaded by default- this may or may not be the endpoint that you want to use for testing
- Endpoints usually contain a server and a port – you can set up multiple endpoints on the . same server, the only difference is the port they connect to. We will discuss how to use each of these options later on
- You can have multiple endpoints stored within a project – you can create them by editing existing or just creating new ones
- If you have a lot of requests to test and/or a lot of projects opened, all of the requests will be named exactly the same – easier to rename them
- Rename Request 1 to ConvertV11
- When you create your project names, remember that they will sort alphabetically By default you are saving your files on a local drive – not optimal for a team or for source code control – you can also manager your projects within a workspace or within environments – we will talk about that later
- Some services require a username password to connect – to make sure that you have permission to use the service – there are many different types of security implementations which we will discuss in more detail later
- When you use the form and your wsdl had enum values then those are available as dropdowns in the form – prevents you from submitting invalid data
- One of the efficiencies of using the forms is to be able to just submit the mandatory fields
- The response can be viewed in the Outline form or the XML form
- Click on the wsdl content tab provides you with information on the structure of the request wsld – you can also load the url in a browser and see the same information
- The first item in the list is the simple types. Expand on this and we can select the simple type Currency which takes us to the definition in the wsld Currency is a enumerated list which means that the wsdl verification itself should prevent a request with something not on the list being submitted – since the form only allows a drop down, we have to input the invalid data via the xml view
- Since this error first violates the wsdl definition it will be captured as a soap exception
- Since this is a soap wsdl violation and since error handling is built into this wsdl, the error message comes back explaining what went wrong
- The complex object Conversion Rate contains 2 elements, each which must occur once and only one
- The syntax for commenting out a line is to use <!– and . (2 dashes and >) it seems to ignore the fact that there is a missing element – should this be a defect? Depends on the specification of the requirements – however since this is a wsdl requirement that is violated, I would think that this should be an error – if you right-click on the input with one of the elements commented out and select Validate – you get an error
- You can duplicate any element if you are in the XML view – it appears to just ignore it and keep processing
- Copying the entire complex object and submitting it – you would expect a soap Fault- however, it appears to just process the second one- it probably processes both but then overwrites the results of the first one with the results of the 2nd one
- The wsdl also include the information for the response- in this case the conversionRateReponse is a complex type but of only appears once – which explains why if we submit multiple copies on the request, we only get one response
- 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
- Operation properties apply to all of the requests under the operation
- One of the more interesting request properties is the strip whitespaces property as it is each to have extra spaces at the beginning or end of your data. Note that the request properties only applies to that one request – if you create another request, you can set it up with different properties
- There are many ways to create multiple request – you can create a default request, an empty request or a copy of an existing request
- You can validate the request to see if it follows all of the rules of the wsdl before you submit the request. Note that the Validate only works if you are in the XML view.
- Double-clicking on any validation errors will take you directly to the line with the issue
- Removing the tag > at the end of the From Currency causes a structural issue