Soap UI - Lesson3
•Download as PPTX, PDF•
0 likes•517 views
Lesson 3 http://www.qualitestgroup.com/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Soap UI - Lesson3
Similar to Soap UI - Lesson3 (20)
More from Qualitest
More from Qualitest (20)
Recently uploaded
Recently uploaded (20)
Soap UI - Lesson3
- 1. Introduction to SOAPUI ANY QUESTIONS?? 1
- 2. Introduction to SOAPUI WORKING WITH TEST STEPS 2
- 3. Protocol Oriented Test Steps • SOAP request • REST request • JDBC Request 3
- 4. Protocol Test Steps • All of the requests within a Test Suite have to come from the same project • Requests from different protocols can be loaded into the same project 4
- 5. Flow Control-oriented Test Steps • Properties • Delay • Groovy script intro • Manual • GoTo 5
- 6. Properties 6
- 7. Transfer Properties • Once properties are created, use a transfer properties test step to pass on the information 7
- 9. Transfer to hand off session id • This property transfer is set up to hand off the sessionid from the login response to the logout request • 9
- 10. Exercise • It would be nice to have the application id from the GetAllBibDataInfo request to pass on to the GetApplicationInfo request so let’s add in the application id as a transfer property and add it as another test step in the test case between GetAllBibDataInfo and GetApplicationInfo. • Then add an assertion on the GetApplication info request to make sure that it is also working correctly. Since Patent Number is one of the fields in the response for the GetApplicationInfo, add an assertion that this matches the original Patent Number input 10
- 11. Delay 11
- 12. Exercise – Delay Step • Add in a Delay Step in the previous exercise before the Property Transfer step – this will allow time for the response from GetAllBibDataInfo to be completed before transferring the data to GetApplicantInfo is executed. 12
- 13. Manual Test Step 13
- 14. Executing w/ a Manual Step • If you have any manual test steps in your test case/test suite, you will get a dialog pop-up that provides instructions and requests information before moving on to the next test step 14
- 15. Exercise – Manual Step • Add a manual step in the previous exercise before the DataSource Loop with the following actions and expected outcome: • Action: Get up from your chair and walk one time clockwise around the conference table, returning to your seat. • Expected outcome: You feel refreshed and ready to take on more challenging exercises. • Run your test suite, recording the actual results and Pass/Fail status for the manual step 15
- 16. Go To 16
- 17. GoTo XPath 17
- 18. Data-Oriented Test Steps • Data Source • Data Source Loop • Data Sink • Data Gen 18
- 19. Data Sink • Allows you to parse values from your test and write them to output file • If you want to use some of the data in the response of a request, start with a valid executed response 19
- 20. Setting up Data Sync 20
- 21. Sample Template File • Data Input file with new header for actual results 21
- 22. Create File • If Excel needs to be .xls 22
- 23. Create Property for Actual Value 23
- 24. Select Element 24 Verify test step order
- 25. After Running 25
- 26. Data Sink Exercise • Using the currency conversion project and the previous steps, add a Data Sink to capture the actual results in your test suite 26
- 27. Data Gen 27
- 28. DataGen Script for Today’s Date 28 ${DataGen#today}
- 31. List DataGen 31
- 32. Mode & Shared • Mode – READ pulls a new value every time it is referenced – STEP pulls a new value every time DataGen is called – Call DataGen prior to use as in the initial state, the property has no value • Shared – For use in load tests – value can be shared across multiple threads 32
- 33. Set up REST project • Can create a REST project by – Using URI – Importing WADL – Discover REST services 33
- 34. REST – URI Address 34 http://maps.googleapis.com/maps/api/geocode/xml?address=1600+Amphit heatre+Parkway,+Mountain+View,+CA&sensor=false
- 35. Project is Set up 35 Can create multiple resources at this level
- 36. Request Tab • Includes the fields – you could put in additional fields in this form as well 36
- 37. Parameter Types • QUERY • TEMPLATE • HEADER • MATRIX • PLAIN 37
- 38. Resource or Method Level 38
- 39. QUERY 39
- 40. HEADER 40
- 41. TEMPLATE 41
- 42. MATRIX 42
- 43. Exercise • Building the correct URI • Create a separate REST project for each of the following URIs and adjust the parameters as needed to build the correct URI: • http://www.thomas-bayer. com/sqlrest/CUSTOMER/18/ (remember that any number can be used after CUSTOMER) • http://fqt-tmng-cms. etc.uspto.gov/trademark/cms/rest/metadata/ca ses/id;sn=76705762 43
- 44. REST Uses Path for Resource Names 44
- 45. SOAP/REST • Project – Service • Resource – Method • Project 45 – Interface • Operation – Request
- 46. Note the Method Options 46
- 47. Submit the Request 47
- 48. Optional parameters • https://spreadsheets.google.com/pub?key=p9 pdwsai2hDMsLkXsoM05KQ&gid=1 48
- 49. Exercise • Create new project using REST service - https://maps.googleapis.com/maps/api/geoco de/xml?address=1600+Amphitheatre+Parkwa y,+Mountain+View,+CA&sensor=false – Change xml > json for different format in response • Create multiple requests with different optional input parameters and different output formats – Input parameters: language (see previous sheet), region (2 char country code that would be used in url such as ca, gb, gr, jp, etc.) 49
- 50. Discover REST APIs 50 1 2 3
- 51. Discover REST API (cnt) 4 51 5 6
- 52. Discover REST (cnt 2) 52
Editor's Notes
- Within one test suite /test case you can have multiple protocols, however all of those protocols must reside in the same project. So if you wanted to have both a SOAP and REST request in the same test case, the definitions for both the SOAP and REST requests must exist in the project. The JDBC requests are to talk to a DB.
- Functional Testing properties are used to parameterize the execution and functionality of your tests, for example: Properties can be used to hold the endpoints of your services, making it easy to change the actual endpoints used during test execution Properties can be used to hold authentication credentials, making it easy to manage these in a central place or external file Properties can be used to transfer and share session ids during test execution, so multiple test steps or test cases can share the same sessions Properties can easily be both read and written from scripts and also transferred between Test Steps with the Property-Transfer Test Steps . The property values can be typed in the rows or they can be loaded from a txt file
- Setting up the properties isn’t enough, a transfer properties test step must be used as well.
- Each variable to be transferred is listed on the left – can only select/view one at a time. The checkboxes at the bottom provide additional options. The options are shown in their default state. Note that the source is the properties that we just set up and the destination is the next test step that needs the information
- There are many reasons for setting up a delay test step- maybe you want to wait for other processes to catch up or maybe you want to test what happens if the there is too long a delay between step – for example, suppose once you first initialize the login process to a system you are given a token and that token is only good for 30 seconds and if you don’t complete the login process in 30 seconds, then you have to start over again – in that case you might want to set up the tests as GetToken, wait 31 seconds, Login – with the expected results of a failure on the 3 step where you try to complete the login
- A manual test step is just that – doing some step(s) manually in order to complete the test
- One the test execution hits a manual test it will sit there indefinitely until the test completes the form and presses ok to continue with the next step or cancel to stop the execution at that point
- The goto logic can be useful for following different paths depending on what is returned from the previous request- for example, if nothing is found to buy during our search, then we don’t want to go through the buy process, we just want to skip to the end and logout (note that logout is picked in the target step). Additionally if we have different logic depending on what is returned, the goto test step can also be useful for that.
- Clicking on the bottom right hand icon in the Conditional Xpath window brings up the Xpath tree from the last response so you can easily find the element you want to add – once you select the element, you have to add in the conditional logic as well – in this case was wanted exists
- We’ve already covered Data Source and Data Source Loop, so we will just look at Data Sink and Data Gen
- 1. Give it a name; 2. pick file type; 3. Add output file info; 4. Add input if you want a template file and change start at cell value
- Once you have the data sink set up, make sure that the test step is located after the step that generates the data that you want to capture and run the test suite Note that if you run the tests again unless you change the start at cell value (or the Out File name), it will overwrite your previous results
- DataGen allows you to dynamically generate data that is needed by your test cases such as a current date or time. Start by clicking on the icon in the test case editor, then add the DataGen and click on the Add icon on the top left to bring up the Add generated property dialog Script : specifies a property whose value is created by a groovy script Template : specified a block of content to be used when building other values Number : allows for number-based sequential creation of property values (integers, dates, etc) List : specifies a list of possible values to return when the property is read
- Inorder to use this value in a property, just use ${DataGen#today}
- Xml template to use the date field
- Numbers can be sequential or random and persisted from run to run
- Mode controls the evaluation of the property value and has two possible values; READ and STEP. READ will re-evaluate the property each time it is referenced. This works ok with (for example) our today property created above and any other property that can/should have its value recreated every time. This may not always be desired though; for example, you might be using a Number property to generate a unique ID to use during the entire run of a TestCase. If you are referring to this ID in several requests or scripts etc, setting it to READ would give you a new value every time, instead of one value that is always the same. In this case set the Mode to STEP and the property will be evaluated when the DataGen TestStep is executed during the execution of the containing TestCase. Note: Prior to execution the property has no set value. Place the DataGen step before any steps that may be referring it.
- Select File > New REST Project then enter URI and click OK http://maps.googleapis.com/maps/api/geocode/xml?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&sensor=false
- Note that you don’t get a chance to name the project when you create it, but you can go back and rename it after the fact. Also note that SOAPUI has pulled in the fields from the URI
- Prepopulates the parameters with the ones found in the REST request – many of the parameters associated with REST requests aren’t required so we can set up different methods to handle the different parameters
- All parameters can be defined either at the RESOURCE level or at the METHOD level. Defining a parameter at the RESOURCE level means that it is inherited by all method nodes under it, and by all requests under the METHOD nodes. Defining it on the METHOD level only propagates the parameters to the requests; it does not affect the RESOURCE level.
- Parameters that are defined at the resource level can be used by all methods created underneath it while parameters created at the method level will only apply to any requests created in that method – you can have as many methods underneath a resource as you want just as you can have as many requests underneath a method as you want. And just like with naming requests, you can name the methods anything that you want as well
- QUERY parameters are the most common type of parameter, which is appended to the path of the URL when submitting a request. You can see them added to the path after a ‘?’ in the path preview at the top of the REST Request editor. If you are simulating HTML Form submits, you might want to them to use the POST method instead. If we create a corresponding REST Method using the POST (or PUT) verb you will get an option to post query-parameters in the body instead
- HEADER parameters are instead added as HTTP Headers to the outgoing request. Let’s define one at the Method level:
- TEMPLATE parameters are a flexible way of parameterizing the actual path of the request. Now we can just change this parameter to run queries using different IP addresses. TEMPLATE parameters really only make sense on the RESOURCE level. It is technically possible to have them on the METHOD level, but it isn’t recommended. If you define a TEMPLATE parameter on the METHOD level, it will not be automatically appended to the resource path — you will have to manage it manually.
- MATRIX parameters are another way of defining parameters to be added to the actual path of the resource, but before the query string. They are not as common but never the less specified in the WADL spec and thus supported by soapUI. Add a MATRIX parameter for date to the Metadata for eOG
- note that you can also hand edit the endpoint and or resource if needed
- As you build your REST services methods and resources SOAPUI will append the URI to the name of each Resource – you can also click on the Resource Param tab to see the parameters for this Resource
- While SOAP and REST have similar hierarchies, they have different names for the different levels
- -Methods for GET, POST, PUT, etc are available in the drop down. The one that you will actually be using will depend on the type and purpose of the request
- Click the green arrow to submit the request and then review the output in the different formats
- Adding parameters to the REST request is done by clicking on the add button and filling in the information on the next row in the table. Typically order doesn’t matter for REST request
- Don’t forget to rename your project – to get the output in json the request becomes https://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&sensor=false
- 1) From the starter page, click on Discover REST APIs, 2) enter the URL – by default the recorder is running; 3) hit enter and wait for the recorded requests to stop loading, then click Done
- 4) Pick just the application/json content types and click generate services, 5) then pick services and click OK; 6) the method parameters are set up automatically
- Request is set up and ready to submit – at this point can parameterize the inputs to the request also shown is the response in JSON format