Readyapi & Soapui Pro Training a 2 Day Seminar

ReadyAPI & SoapUI Pro Training A 2 Day Seminar

Sample - worbkook customized for each class

This publication is protected by copyright. No part of this publication may be reproduced in any form by any means without prior written authorization by WiseClouds, LLC.

This publication is provided “as is” without warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose or non-infringement.

This publication is provided for educational purposes only.

Any product specifications are subject to change without notice.

WiseClouds and the WiseClouds logo are trademarks of WiseClouds, LLC in the United States, other countries, or both. SmartBear, its logo, and the products listed below are registered trademarks of SmartBear Software in the United States, other countries, or both. All other company or product names are registered trademarks or trademarks of their respective companies.

ReadyAPI SoapUI SoapUI Pro SoapUI Pro LoadUI LoadUI Pro LoadUI Pro SecureSample Pro - worbkook customized for each class ServiceV Pro

Table of Contents Lab: Configure and personalize your SoapUI Pro environment ...... 4 Lab: New Web service project creation ...... 6 Lab: Interacting with SOAP requests ...... 9 Lab: New REST API project creation ...... 11 Lab: REST style and payloads ...... 14 Lab: Advanced project creation ...... 16 Lab: File system interaction ...... 17 Lab: Working with properties ...... 19 Lab: Design a TestCase with multiple inter-related TestSteps ...... 23 Lab: Assertions to evaluate property contents ...... 27 Lab: Assertions to determine message compliance ...... 31 Lab: Other assertions ...... 34 Lab: Apply multiple assertions to a Web service ...... 36 Lab: Apply multiple content assertions to a REST API call ...... 37 Lab: Apply Boolean logic to a Request & Response ...... 38 Lab: Data driven testing ...... 43 Lab: Data generation ...... 48 Lab: Introduction to Groovy scripts ...... 50 Lab: Place a REST API under load ...... 54 Case study: Design a comprehensive testing plan ...... 55

Sample - worbkook customized for each class

Lab: Configure and personalize your SoapUI Pro environment

In this lab, you’ll explore SoapUI Pro’s preferences menu, and configure a few of the more than 100 settings that help drive the product’s behavior. To access these preferences, choose the File -> Preferences menu, or click on the Preferences icon.

Switch to each tab, and follow the instructions for adjusting these options. Note that aside from the preferences in these instructions, you may leave everything else unchanged.

HTTP Tab (no need to adjust any other settings here)

Preference Setting Reason Request compression None Transmit messages to services/APIs without compressing them – less chance of a server- side issue Response compression Unchecked Don’t automatically attempt to compress responses from services/APIs – aids with readability Include request in Checked Increases performance statistical consistency time taken across all tests Include response in Checked Increases performance statistical consistency time taken across all tests Leave virt Checked Keeps internal Jetty web server running even after halting a virtual API

WSDL Tab (no need to adjust any other settings here)

Preference Setting Reason Sample values Checked Have SoapUI automatically create basic Sample - worbkook customizedsample data to transmit for toeach Web services class Pretty print Checked Improves readability of response messages

UI (User interface) Tab (no need to adjust any other settings here)

Preference Setting Reason Sort projects Checked Organize your projects alphabetically Sort services Checked Organize your services alphabetically Sort REST resources Checked Organize your REST resources alphabetically Show descriptions Checked Display supporting descriptive information whenever available Wrap content in Raw Checked Makes it easier to review raw responses from message viewers your services & APIs Disable message on Checked Don’t have SoapUI automatically generate DataSource creation DataSource Loop TestSteps

Editor Tab (no need to adjust any other settings here)

Preference Setting Reason XML line numbers Checked Aids with XML readability Tabbed request view Unchecked Places requests and responses side-by-side. Later, your instructor will demonstrate multiple ways to organize requests and responses.

ReadyAPI Tab (no need to adjust any other settings here)

Preference Setting Reason Default SOAP request Form Provides a user-friendly way to enter request editor details Default REST request Request Displays an editor that makes it easy to add editor URI parameters DefaultSample response - worbkookOutline customizedArranges responses for in an each easy-to-understand class editor format Complete error logs Checked Include comprehensive details about errors when generating reports

Lab: New Web service project creation

In this lab, you’ll gain hands-on experience in creating and understanding the major components in a Web service testing project.

You’ll begin by creating a new SOAP project (File -> New -> Project) and selecting the Description File option and WSDL definition (SOAP). Paste in the Lottery endpoint, making sure that the Create sample requests… box is checked, and everything else is unchecked. Accept all the subsequent defaults and your project will be ready.

Once the project has been created, enter a description for it (found in the Project Properties section)

Sample - worbkook customized for each class

Next, it’s time to get comfortable with the major Web service details that SoapUI Pro loads from your WSDL. Begin by double-clicking on the LotterySOAPBinding interface)

Spend a few minutes exploring the interface’s tabs, such as Overview, Operations, and Endpoints.

Since understanding your WSDL is essential for writing meaningful tests, pay particular attention to the project’s WSDL Content tab.

Sample - worbkook customized for each class

Even though SoapUI Pro presents a basic WSDL viewer, it also offers a nice tool for presenting a more readable version of your WSDL. You can check it out by clicking on the Generate simple HTML documentation… icon at the top of the window. Provide a destination directory for the file (making sure you have permission to write to it) and then navigate to the directory and view your output in a browser.

You can also export your WSDL to your local file system. Try it out by clicking on the Export icon at the top of the screen (found to the right of the Generate simple HTML documentation… icon).

Finally,Sample save your -project worbkook by right clicking customized on it and selecting for Save each. Choose class any directory you like, or just use the default.

If you have issues with any of these steps, the instructor can demonstrate afterwards.

Lab: Interacting with SOAP requests

In this lab, you’ll learn about how to work with SOAP requests, including validating their contents, creating multiple instances, appending standard SOAP headers, and adding requests to tests.

You’ll begin by creating a new SOAP project (File -> New -> Project) and selecting the Description File option. Paste in the Complaints endpoint, making sure that the Create sample requests… box is checked, and everything else is unchecked. Accept all the subsequent defaults and your project will be ready.

Once the project has been created, navigate to Request 1, which is found within the PostComplaint operation, located under the ComplaintSOAPBinding interface.

Enter some data of your choice in each of the fields. Hint: if you place your mouse over certain (but not all) fields, you’ll receive a tooltip message from SoapUI Pro based on what the WSDL states are acceptable values for that field. Once you’ve entered your data, click on the validate icon (checkmark) to see if what you’ve typed in will match what the WSDL expects. Note that no data is transmitted to the service; all validation is happening locally.

Try experimenting with different values to cause and then resolve validation errors.

Sample - worbkook customized for each class

It’s easy to create a copy of your request; simply right click on it and choose the Clone Request option. Once it’s created, you can enter some different data in the new request. This is very useful when you have a baseline request and then want to quickly create several variations of it.

Many Web services expect to receive SOAP headers (either standardized or site- specific) in their incoming messages. SoapUI Pro makes it simple to add them to your requests. For example, view any request and click on the WS-A tab at the bottom of the screen. Check these boxes:

• Enable WS-A addressing • Add default wsa:Action • Add default wsa:To • Generate MessageID

Run the request, and then examine its Raw tab. You should see how your headers were sent with the message.

Finally, you can add any request to an existing or new TestCase by right clicking on it and choosing the Add to TestCase menu option. If you’ve already created TestCases, you can add this request to them; otherwise, you can build a new TestSuite and TestCase around the request. Try adding one of your requests to a new TestCase.

If youSample have issues - with worbkook any of these steps,customized the instructor canfor demonstrate each class afterwards.

Lab: New REST API project creation

In this lab, you’ll gain hands-on experience in creating and understanding the major components in a REST API testing project.

You’ll begin by creating a new REST project (File -> New -> Project) and selecting the URL option. Paste in the Temperature GET active sensor endpoint, and be sure that the default method is set to GET. Choose the Continue to describe your API option and your project will be ready. Click the green Run icon at the top, and you can view the response to this API call.

Take some time to look at the tabs for the request and response. You’ll notice that the JSON tab on the response won’t have any data.

Sample - worbkook customized for each class

To work with JSON messages, create another REST project using the Temperature GET last 100 readings for device #2 (JSON) URL. Once again, look at the request and response tabs. What you’ll notice is that SoapUI Pro will render JSON data as XML, thus giving you access to the full collection of XPath assertions (which we’ll discuss later).

The APIs you’ve worked with so far in this lab use the HTTP GET method to retrieve data. HTTP offers several other methods for transmitting data to your REST API. You can see this for yourself by creating another REST project, using the Temperature PUT (XML) this time. Once again, continue straight on to the API, but make sure to change the method type from GET to PUT in the dropdown. Enter some values for id and reading, transmit the message, and then view raw request and response messages.

Sample - worbkook customized for each class

Finally, many REST APIs expect messages to include HTTP headers. To supply these headers to your outgoing messages, just click on the Headers tab in the request. Try adding a header called Token, and give it a value of ABC123.

Send the message and look at the request’s Raw tab to see how the header was transmitted. If you view the Headers tab on the response, you’ll notice that these are different: there’s no guarantee that your REST API will return any transmitted headers to you.

If you have issues with any of these steps, the instructor can demonstrate afterwards. Sample - worbkook customized for each class

Lab: REST style and payloads

SoapUI Pro offers great flexibility when discovering and configuring interactions with your REST API. In this lab, you’ll see how to adjust your request parameters, along with supplying a JSON message payload.

To complete this assignment, follow these steps:

1. Create a new project using the Weather report POST (JSON) URI. There’s no need to create a TestCase, so just work with the API directly. 2. Change the method from GET to POST. 3. Download and open the text file identified as Single weather report. This contains the payload of your message. 4. Copy the contents of the text file and paste it into the section at the bottom of the screen. Make sure that the Media Type dropdown is set to application/json. 5. Provide any values you like for id and auth_code. 6. Transmit the request, and look at its Raw tab to see what was sent. 7. Adjust the style of each parameter (including using different settings for each one). After each change, run the request and examine what was sent. Try to explore all of the styles.

If you have any issues, the instructor will demonstrate afterwards.

Sample - worbkook customized for each class

Lab: Advanced project creation

Many tests must interact with multiple services and/or APIs. Fortunately, it’s easy to add as many of these references as you like to your project. In addition, SoapUI Pro supports project options that relate to security and caching.

To complete this assignment, follow these steps:

1. Create a new project, but choose the Create Empty Project option. 2. Once the project has been created, right click on it and choose the Add WSDL option. Use the Complaint service endpoint. 3. Once the WSDL has been loaded, right click on the project and choose the New REST Service from URL option. Use the Warehouse Status (JSON) URL. The project now includes references to a SOAP service and a REST API. 4. To encrypt your project, click on it and enter a password in the Project Password property. Notice that the project icon has changed to reflect its encryption. 5. WSDL and REST definitions may be cached, or refreshed whenever you ask to view the definition. To force SoapUI Pro to get a fresh copy each time, set the Cache Definitions project property to False. 6. Save the project and then remove it from the Navigator. 7. Open the project using your password. If you don’t supply your password now, you’re able to decrypt the project by right clicking on it and choosing Open and Decrypt.

If you have any issues, the instructor will demonstrate the solution afterwards.

Sample - worbkook customized for each class

Lab: File system interaction

There may be occasions where you need to communicate with the file system from within SoapUI Pro. Two specialized TestSteps – Create File and File Wait – make these interactions easy. This lab shows you how to work with them.

To complete this assignment, follow these steps:

1. Before beginning, identify (or create) a working directory where your file will be placed and then read. On Windows computers, c:\tmp is a good candidate. 2. Create a new project in ReadyAPI, and choose the Create Empty Project option. 3. Create a new TestSuite and TestCase. 4. Add a Create File TestStep. Call the file soapui.txt, and place it in the working directory from step 1. Enter This file can be created inside SoapUI as well as from any other process as the file content, and check the Overwrite existing file.

Sample - worbkook customized for each class

5. Add a Delay TestStep beneath the Create File TestStep. Set its delay to 30000 milliseconds (30 seconds). This will give you enough time to view the file while the TestCase is running.

6. Finally, add a File Wait TestStep as the last step in the TestCase. Configure this TestStep to point at the directory and filename from step 4. Set its timeout to 600 seconds, and check the Delete File box.

7. Run the TestCase. While it’s running, view the file with a text editor. You should see the message you entered in step 4. 8. After the TestCase is finished, the file should be gone (because you configured the last TestStep to delete it). Sample - worbkook customized for each class If you have any issues, the instructor will demonstrate the solution afterwards.

Lab: Working with properties

You can use SoapUI properties to store all sorts of information, whether it’s data that you’re planning to transmit to your API, extracted details from responses, or just simply variables that you want to keep track of. In addition, locating and utilizing a property is quite straightforward via the SoapUI Get Data capability.

In this lab, you’ll explore working with properties at the following levels:

• Global • Project • TestSuite • TestCase • TestStep

To complete this assignment, follow these steps:

1. Create a new project (URL) using the Repeat API, found in the REST APIs section. Accept the GET method from the Default method dropdown.

2. Choose the Create a test case option.

Your TestCase is now in place; the next steps will entail creating properties at various levels and then transmitting their contents to the API.

3.Sample Create a global - worbkook property (File -customized> Preferences -> Global for each Properties class) by clicking on the . Name your property MyGlobal and give it a value of This data is available everywhere in SoapUI. Tab out of the field once you’ve entered its data.

4. Create a Project property by clicking on the project and navigating to the Custom Properties tab. Name this property MyProject, and give it a value of This data is available anywhere in this project.

5. Create a TestSuite property by clicking on the TestSuite and navigating to its Custom Properties tab. Name this property MyTestSuite, and give it a value of This data is available anywhere in this TestSuite.

Sample - worbkook customized for each class 6. Create a TestCase property by clicking on the TestCase and navigating to its Custom Properties tab. Name this property MyTestCase, and give it a value of This data is available anywhere in this TestCase.

7. Finally, create a specialized Properties TestStep by right-clicking on the TestCase and choosing Add TestStep. Select the Properties TestStep; use the default name. Once the TestStep is in place, create a property within it called MyTestStep, and give it a value of This data is from a single TestStep. Be sure the Properties TestStep is above the Request 1 TestStep; use drag-and-drop if necessary.

Now you have multiple properties available to transmit to the API. To do that, following these steps:

8. Double-click on the Request 1 operation. Switch to the Form view, and

click on the ellipses next to the value field. This will invoke the Get Data dialog.

9.Sample Take some - time worbkook to explore this customized dialog. The first data for that each you should class select will be the MyGlobal property, found in the Global Properties section.

10. Click Add to associate this property with the request, and notice that the field has now been filled in with the name of this property.

11. Transmit the request to the API by clicking the button. Review the Raw Request and Raw Response tabs to see what was transmitted and received. You may notice additional characters such as %20: these represent spaces.

12. Repeat steps 9, 10, and 11 for the Project, TestSuite, and TestCase properties you created earlier.

13. To transmit the TestStep property, run the entire TestCase. Sample - worbkook customized for each class

If you have any issues, the instructor will demonstrate the solution afterwards.

Lab: Design a TestCase with multiple inter-related TestSteps

In this lab, you’ll be setting up a TestCase that will validate the process of obtaining authorization to re-ship a package. In a nutshell, here’s what will happen:

1. You’ll create a new project that contains a TestSuite, which in turn contains a TestCase. 2. You’ll set up a Properties TestStep to store what you’ll be sending to the PostComplaint operation of the Complaint service. 3. You’ll transfer these properties into a SOAP Request, and then transmit them. 4. You’ll take portions of the response that comes back from the SOAP Request and feed them to the ReshipPackage operation of the Complaint service.

Here’s how to proceed:

1. Create a new SOAP project, and use the Complaint service endpoint. Only check the Create Requests box.

2. Switch to the SoapUI Pro section, right-click on the project, and choose New TestSuite. Accept the default name.

3. Right-click on the TestSuite, and choose New TestCase. Accept the default name.

4. Right-click on the TestCase, and choose Add Step. Select the Properties TestStep. Name it Inbound Properties.

5. Add each of the following properties to the Inbound Properties TestStep Sample - worbkook customized for each class (click on the symbol within the TestStep to create each one):

• ShipmentID • Name • Phone • Email • ComplaintDate • ComplaintReason • ComplaintDescription

You may need to hit the Escape key to switch between properties.

6. For each of the properties listed above, provide a value. Be sure to use 987654321 for ShipmentID; you can use anything you like for the rest of the properties.

When you’ve finished preparing the Inbound Properties TestStep, it should look something like this:

Now it’s time to feed these properties to the Web service.

7. Right click on the TestCase and choose Add Step. Choose the SOAP Request TestStep, call it Post Complaint, and select the ComplaintSOAPBinding -> PostComplaint operation. Accept the defaults and click OK.

8. Make sure that the new SOAP Request is below the Inbound Properties TestStep. Use drag and drop if you need to rearrange the TestSteps.

9. Open the Post Complaint SOAP Request, and choose the Form view. Sample - worbkook customized for each class 10. For each field on the form, associate the appropriate property from the Inbound Properties TestStep (step 5 above). Your instructor will demonstrate how to do this. Finally, note that the ComplaintReason field won’t have ellipses next to it. This is because it’s an enumerated value. Just right-click in the field and choose Get Data to link the property with this field.

Your TestCase is now set up to send a single message to the service. Let’s see how to process return values from the service.

11. Double-click on your TestCase and run it. This will call the service using your sample data and set up the result structures that you’ll need for the next few steps.

12. Right-click on your TestCase, and choose Add Step. Select the Properties TestStep. Call it Outbound Properties and make sure that this TestStep is beneath the Post Complaint SOAP Request step you added earlier.

13. Add the following properties to your new Outbound Properties TestStep. Leave their values blank for now; SoapUI Pro will automatically fill them in a little later in this lab.

• ShipmentIDAck • ComplaintStatus • ComplaintMessage

14. Double-click on the Post Complaint SOAP Request (its icon should be green, meaning that it’s been run). Make sure to view the Response. You will be transferring a few fields from the response to the Outbound Properties TestStep. These will be used in a subsequent call to a different part of the Web service.

15. For each of the following three fields in the Response:

ShipmentIDAck ComplaintStatus ComplaintMessage

Click on it and choose the Transfer to dropdown (at the top of the window). Select the corresponding Outbound Properties destination that you entered in step 13. Accept the default values.

Notice that SoapUI Pro has automatically set up a PropertyTransfer TestStep to facilitate moving this information. Sample - worbkook customized for each class 16. Run your TestCase again. If everything has been configured correctly, you should see the Response values transferred into the Outbound Properties TestStep you created in step 13.

The final set of steps involves setting up a call to the ReshipPackage operation, and populating it with the appropriate data.

17. Right click on the TestCase and choose Add Step. Choose the SOAP Request TestStep, call it Reship, and select ComplaintSOAPBinding -> ReshipPackage operation. Accept the defaults and click OK. Make sure that this TestStep is the last one in the TestCase.

18. Double-click on the Reship SOAP Request, make sure you’re using the Form view, and associate ReshipID with the ShipmentIDAck property from step 13. Do the same for ReshipAuth and ComplaintMessage.

Everything is now connected. To see it in action, simply run the TestCase again. All properties should be transferred correctly, and the response from the last SOAP operation (Reship) should indicate a successful request (Reship: success).

The completed TestCase should look something like this:

Your instructor will now demonstrate how to use the SoapUI Pro Step-by-Step RunSample utility to examine - worbkook this workflow in customized more detail. for each class

Lab: Assertions to evaluate property contents

In this lab, you’ll learn how to apply several of SoapUI’s powerful property content assertions to evaluate the presence (or lack) of certain values within your messages.

To begin, you’ll use the Contains assertion to check for existence of a value anywhere in a response (including its XML tags):

1. Create a new project (Description File -> WSDL) using the Complaint service endpoint. Check the Create a test case… box. 2. Add a new Contains assertion, choosing the Contains assertion from the Property Content group. 3. Fill in the assertion data that you want to test. In other words, what do you want to assert that the results do contain anywhere in the message? In this case, enter OK (which indicates a normal completion for your service call). 4. Run the test and review the output. 5. Bonus: Try different ShipmentIDs (using 9 digit numbers including 111111111 and 123456789 and others). This may cause response messages that make this assertion fail.

Sample - worbkook customized for each class

Next, you’ll use the Not Contains assertion to ensure that a specific value is not present anywhere in the message.

1. Remove any existing assertions, and then add a Not Contains assertion. 2. Fill in the assertion data that you want to test. In other words, what do you want to assert that the results do not contain? For this example, enter INCORRECT in the dialog box. If this word turns up anywhere in your results, the assertion will fail. 3. Run the test and review the output. Note that if you send a ShipmentID of 111111111 to the example service, it will return this result, thereby causing the assertion to fail. 4. Experiment with the data you provide to your test, and review the assertion results.

Sample - worbkook customized for each class

The XPath Match (and JSONPath Match) assertions are extremely helpful. They let you pinpoint and evaluate a specific node within your response.

1. Remove all assertions, then add an XPath Match assertion. 2. Click on the Select node… icon (located on upper left) to identify the information source node. 3. Select the ComplaintMessage entry (last item in the XML document) and click OK. 4. Notice that SoapUI has constructed a full XPath expression and filled in the matching value based on what you selected. 5. Click Save to complete preparing the assertion. 6. Run the test and review the results.

Important: DO NOT use 123456789 as your ShipmentID: it will throw a SOAP Fault and make it difficult to complete this exercise. Use any other value in this field.

Sample - worbkook customized for each class

The XPath Match assertion is used to check nodes in an XML message; the JSONPath Match assertion does the same for a JSON message.

1. Create a new REST project, using the URL option and the Temperature GET last 100 readings for device #2 (JSON) endpoint. Create a TestCase as well, and navigate to the TestCase’s REST request. 2. Run the request once to set up the response message structure. 3. Create a new JsonPath Match assertion. 4. Click on the Select node… icon (located on upper left) to identify the information source node. Choose the device node, and check that it’s set to 2. 5. Create a second JsonPath Match assertion, and this time evaluate the first instance of the timestamp (value is 2882194). 6. Run your TestCase to check the results.

Sample - worbkook customized for each class

If you have any issues, the instructor can demonstrate afterwards.

Lab: Assertions to determine message compliance

For interoperability, reliability, and many other reasons, it’s important that your APIs return properly formatted messages that conform to pre-defined standards (either your own, provided by third parties, or both). In this lab, you’ll see how to easily determine whether your messages are compliant.

First, here are some examples of checking a SOAP response for compliance:

1. Create a new project (Description File -> WSDL) using the Complaint service endpoint. Check the Create a test case… box. 2. Add a SOAP Response assertion. 3. Enter some sample data (e.g. ShipmentID, Name, Phone, etc.) to send to the service, and then run your TestStep. Review your results. 4. Next, add the schema compliance and Not SOAP Fault assertions. 5. Run your TestStep again, and review your results. One of the assertions in this exercise (Schema Compliance) will fail; this is expected. Depending on what you entered, another one might fail as well. 6. Bonus: Experiment with different ShipmentIDs (using 9 digit numbers including 111111111 and 123456789).

Note that if you receive a schema compliance failure with your real APIs, your only option is to make note of the message and alert your developer.

SOAP faults are a very common way of receiving errors from your Web service. SoapUI has good support for monitoring when these conditions occur:

1. Remove all assertions and then add a SOAP Fault assertion. 2. Run your test and monitor the results. Unless you provide a ShipmentID of 123456789 (which triggers a SOAP Fault), this assertion will normally fail (in other words, there is no SOAP Fault error message returned).

You can use the SOAP Fault assertion to ensure that your service correctly returns a fault when it receives bad data or encounters another problem. Sample - worbkook customized for each class

Next, you’ll check the HTTP headers of your response to determine whether a specific code is returned (or not).

The following assertion should be used when you expect a response to return a specific HTTP status code from one or more potential values.

1. Remove all assertions, and then add a Valid HTTP Status Codes assertion. 2. This brings up a dialog box where you can add all HTTP status codes that indicate success. For now, just enter 200 and click OK. 3. Run the test and review the results. 4. To see the actual HTTP header contents, click on the Headers tab at the bottom of the Response tab.

Sample - worbkook customized for each class

On the other hand, you may want to check that a response did not include an HTTP status code from a list of potential candidates.

1. Remove all assertions, and then add an Invalid HTTP Status Codes assertion. 2. This brings up a dialog box where you can add all HTTP status codes that should not be returned when you successfully call the API. 3. Enter 400, 401, 404, and 500 on one line and click OK. These are the HTTP codes that you do not expect to come back from a normal API call. 4. Run the test and review the results.

Sample - worbkook customized for each class

Lab: Other assertions

Response time is one of the most important factors in determining if an API is ready for production. It’s easy to use the Response SLA assertion to quickly learn if there are performance problems.

1. Using any of your recent SOAP or REST projects, remove any existing assertions, and then add a Response SLA assertion. 2. Enter the required response time (in milliseconds). For the purposes of this example, use a value of 500 (which is a half-second). 3. Run the test and review the output. Note that the API was designed with a random, built in delay, which should cause the assertion to fail periodically. 4. Bonus: Experiment with the required response time, and review the assertion results.

Sample - worbkook customized for each class

If you’re faced with a situation where there are no applicable built-in SoapUI assertions, you’re always free to write your own assertion using Groovy script:

1. Remove any existing assertions, and then add a Script assertion. 2. Fill in the contents of your script. Use this example to check response time: assert messageExchange.timeTaken < 100

Note that you would likely use a Response SLA assertion to check response time. However, this example does illustrate how easy it is to create a script assertion.

4. Run the test and review the output. 5. Bonus: try adjusting the time value and re-running the test.

Sample - worbkook customized for each class

Lab: Apply multiple assertions to a Web service

In this scenario, you’ll connect to a Web service and create a TestCase with a series of assertions to see if the service is performing properly.

This Web service has the following parameters:

• Input – RequestReport

• Output – ResortName – Conditions – CurrentWeather – BaseSnow – NewSnow – BeginnerRuns – IntermediateRuns – AdvancedRuns

(Note that you can provide any input for the RequestReport parameter).

Your task is to create a new project, TestSuite, and TestCase. You’ll use the Ski service endpoint.

Create assertions to test the following:

1. The service returns a valid SOAP response 2. The service doesn’t return any standardized Web service faults 3. The service’s reply conforms to its schema 4.Sample The service - returnsworbkook data within customized 500 milliseconds for each class 5. The service doesn’t return the word ‘Error’ anywhere in the message 6. Bonus: That the BaseSnow element is greater than the NewSnow element 7. Bonus: That the Conditions element returns neither Icy nor Closed 8. Bonus: That the Conditions element doesn’t return Powder when the CurrentWeather element returns Rain 9. Bonus: That the BaseSnow element is less than a TestCase property that you create and set named MaxBase

Run your test several times to get a variety of responses. Review the assertion results.

Lab: Apply multiple content assertions to a REST API call

In this scenario, you’ll interact with a REST API and apply a collection of assertions (JSONPath and Equals) to validate the response.

1. Set up a new REST project using the Warehouse Status (JSON) API. Request a TestSuite when creating the project.

2. Once the project and TestSuite, and TestCase are in place, run the REST Request to get back a response.

3. Add a JSONPath Count assertion to affirm that there are exactly 10 node entries in the $.response.warehouses portion of the response. Bonus: try using a property containing a value of 10 instead of directly entering ‘10’ in the assertion configuration dialog. Hint: here’s some sample syntax assuming a project property named mycount: ${#Project#mycount}

4. Add a JSONPath Existence assertion to check that the $.response.warehouses[0].Name node (Hyderabad) node exists. The assertion should evaluate to true. Bonus: try using a property instead of hard-coding true.

5. Try adding some additional JSONPath Existence assertions, but use false this time. In other words, create assertions that check for the non-existence of nodes and/or values within those nodes.

6. Add an Equals assertion. Choose a target of Text, and paste in the Raw JSON response message (not counting headers). Note that the text in question begins with the first { and ends with the last }

If you have any problems, your instructor will demonstrate the solution.

Sample - worbkook customized for each class

Lab: Apply Boolean logic to a Request & Response

The Assertion TestStep offers limitless possibilities for constructing sophisticated evaluations, which may focus on a single protocol TestStep or span multiple TestSteps.

In this simple scenario, you’ll use this TestStep to create several validations for your API, including applying Boolean logic to examine your results. You’ll also assess both the Response and the Request, which is another unique and very helpful facet of the Assertions TestStep. These assertions will cover multiple scenarios and will highlight the power and flexibility of this TestStep.

You’ll begin by creating a new project, TestSuite, and TestCase. Please use the Aviation service endpoint, and make sure your Turbulence TestCase includes the Turbulence operation.

Once your project is in place, add an Assertion TestStep after the Turbulence SOAP Request in the Turbulence TestCase. In this Assertion TestStep, begin by creating a series of assertions in the order shown in the table below (click the

to add each one). Note that the ‘Source’ of each assertion will be Step 1 [Turbulence]:

Property Assertion Value Response SLA -> Response SLA 1000 Request Property Content -> Contains Extreme Response Property Content -> Contains warning Request Property Content -> Not Contains Extreme Response Property Content -> Not Contains warning

Sample - worbkook customized for each class

The resulting TestStep should look like the following. Note that the Message is UNKNOWN because the TestCase hasn’t been run yet:

With the individual assertions in place, it’s now time to group them and apply Boolean logic.

First, highlight the second and third entries in the list (Contains, Contains 2),

and click the icon to group them. Name this group Extreme Conditions, and use the AND operation:

Sample - worbkook customized for each class

This means that SoapUI will ensure that Contains AND Contains 2 are true when evaluating this group.

Next, highlight the Not Contains and Not Contains 2 entries and group them. Label this group Non-extreme Conditions, and once again use the AND operation:

Here’s how the TestStep should appear now:

Sample - worbkook customized for each class

Finally, it’s time to associate the two groups and evaluate them. Collapse the Extreme Conditions and Non-extreme Conditions groups highlight them both. Click on the group icon, and name this group All Conditions using the OR operation.

Here’s how the TestStep should appear now:

Sample - worbkook customized for each class

The Response SLA assertion stands alone; it will be evaluated by itself in all scenarios. Everything else is part of a group; the All Conditions group contains two subgroups: one that will be valid for Extreme turbulence reports, and one that will be valid for all other conditions.

Once your groups are in place, run the complete TestCase a few times. Experiment with different data in the conditions element to see how the Assertions TestStep is evaluated. Be sure to examine the Assertion TestStep after each run to get an idea of how it was processed:

Sample - worbkook customized for each class

Lab: Data driven testing

In this lab, you’ll see how to use several types of data sources to send test data to your APIs. You’ll also learn how to take responses and save them to your local file system.

1. Create a new SOAP project (description file) using the Echo service endpoint. Check the Create sample requests… and Create a test case boxes. Accept all the defaults. 2. Add a new DataSource TestStep to the Forward TestCase. Say ‘No’ if SoapUI Pro asks to create a data-driven loop. Make sure the new DataSource TestStep is above the Forward TestStep. 3. Once the new DataSource is visible and in place, choose the Grid option from the DataSource drop-down. 4. Click on the + icon in the DataSource’s Properties section, and create a new property called Vacation. You’ll transmit a series of values for this property to your service. 5. In the Configuration section, enter five of your favorite vacation locations, one per row. 6. Double-click on the Forward TestStep, and choose the Form view. 7. Link the Vacation property from the DataSource TestStep to the FwdInput field. 8. Add another TestStep, this time choosing the DataSource Loop type. Make sure it’s beneath the Forward TestStep. 9. Double-click on the new DataSource Loop. Select the DataSource you created earlier as the DataSource step, and the Forward TestStep as the target step. 10. Run your TestCase. When finished, look at the transaction log to view individual messages. 11. Save your project; you’ll use it next.

Sample - worbkook customized for each class

1. Using the project you just saved, double click on the Forward TestStep. 2. Add a new Contains Assertion. 3. Enter ${DataSource#Vacation} in the assertion dialog. This will evaluate the entire response message for the value of this property for each message iteration. 4. Run your TestCase. Once it’s done, take a look at the transaction log to view individual Request/Response messages. You should observe that the assertion has been successful for every message.

Sample - worbkook customized for each class

Next, you’ll use an external data source (in this case, a CSV file) to transmit larger and more complex messages to your API:

1. Create a new SOAP project using the Complaint service endpoint. Check the Create sample requests… and Create a test case boxes. Accept all the defaults. 2. Add a new DataSource to the PostComplaint TestCase. Say ‘No’ if SoapUI Pro asks to create a data-driven loop. Choose the File option from the drop-down. Make sure the new DataSource is above the PostComplaint TestRequest. 3. Download the ComplaintsData.csv file, and remember where you save it. 4. In the Configuration section for the data source, browse to the ComplaintsData.csv file. 5. Enter Yes to import the properties, which are found on the first line of the CSV file. Accept the defaults, and you’ll notice that SoapUI Pro has automatically created the property names for you. 6. To make sure everything is configured correctly, click on the green Run icon in the configuration section. You should be able to see some rows from the file. Note that this doesn’t run the entire TestCase; it only loads some sample data. 7. Double-click on the PostComplaint TestStep, and choose the Form view. 8. For each field in the form, link the matching property from the DataSource TestStep. For the ComplaintReason field, right-click in it and choose Get Data to find the property. 9. Add another TestStep, this time choosing the DataSource Loop type. Make sure it’s beneath the PostComplaint TestStep. 10. Double-click on the new DataSource Loop. Choose the DataSource you created earlier as the DataSource, and the PostComplaint TestStep as the target step. 11. Run your TestCase. View the transaction log to see individual Request/Response messages. 12. Save your project; you’ll be using it next.

Sample - worbkook customized for each class

Along with feeding information to send to your APIs, SoapUI lets you save responses (all or part of a message) from your APIs:

1. Continue using the current project. 2. Add an additional DataSink TestStep, and make sure it’s just above the DataSource Loop TestStep. 3. Configure this new TestStep. First, select File from the DataSink dropdown, and then browse to an output file in a directory where you have write privileges. You can either use an existing file, or just enter something like “c:\output.txt”. 4. Next, add two properties (on the left side of the window). Call the first one ShipmentID; call the second one ComplaintStatus. You’ll fill in these properties from your results in a moment. 5.Sample For each property, - worbkook double-click customized in the Value column, for then each right-click class and choose the Get Data menu option. 6. Navigate to the Response property from the PostComplaint TestStep. For the first property, choose the ShipmentIDAck entry from the XPath editor. For the second property, select the ComplaintStatus entry. 7. Run your TestCase and review the output file.

Sample - worbkook customized for each class

Lab: Data generation

SoapUI includes powerful data generation capabilities via its Data Generator data source. While it’s always better to use meaningful test data that you create, it’s helpful to have the option of letting SoapUI produce data for you. In this lab, you’ll see how to do just that. The use case here is feeding data to an API call that reports turbulence conditions for in-progress flights.

1. Create a new SOAP project (description file) using the Aviation service endpoint. Check the Create sample requests… and Create a test case boxes. Accept all the defaults. 2. Add a new DataSource TestStep to the Turbulence TestCase. Say ‘No’ if SoapUI Pro asks to create a data-driven loop. Make sure the new DataSource TestStep is above the Turbulence TestStep. 3. Once the new DataSource is visible and in place, choose the Data Generator option from the DataSource drop-down. 4. Click on the + icon in the DataSource’s Properties section, and create four new properties (one at a time): • altitude • latitude • longitude • conditions

5. With the properties in place, the next step is to instruct SoapUI about what kind of values you want to use. Click on each property and configure its data generation appropriately, as shown in the table below:

Property name Property Minimum Maximum Decimal type value value places altitude Integer 0 99999 N/A latitude Real -90 90 5 longitude Real -180 180 5

For conditions, choose the Values from Set option, and create these five values: Sample - worbkook customized for each class • None • Light • Moderate • Severe • Extreme

6. You can click the green run icon at the top of the Data Source dialog to see some sample values:

7. Complete configuring your TestCase by adding a DataSource Loop TestStep, and associating the properties you just created with their input fields on the Turbulence TestStep. Note that you’ll have to right-click in the conditions field and choose Get Data to make the association between the DataSource property and the message. 8. Run your TestCase. When finished, look at the transaction log to view individual messages.

Sample - worbkook customized for each class

Lab: Introduction to Groovy scripts

In this lab, you’ll write several scripts that will give you a foundation in some basic Groovy concepts. Begin by creating an empty project, followed by a TestSuite, TestCase(s), and Groovy Script TestStep. You don't need any WSDL or a REST URL for these exercises.

For each exercise, you’ll enter code into the Groovy TestStep’s script editor. Once you’ve entered the code, just click on the Run icon at the top of the screen and view the ‘Log Output’ tab.

Exercise 1: A ‘Hello World’ script

Exercise 2: Create a message box

Exercise 3: A script that loops and evaluates a condition

Sample - worbkook customized for each class

Exercise 4: Branch script execution using the switch statement

Exercise 5: Programmatically determine TestCase & TestSteps

Sample - worbkook customized for each class

Exercise 6: Dynamically create TestSteps

Exercise 7: View testRunner information

Sample - worbkook customized for each class

Exercise 8: Create an input form, populate a property with user-supplied data

For this exercise, add a Properties TestStep to the current TestCase, and then add a property within the TestStep called Lookup. Leave the value blank. Enter and run the following code:

After running the code, examine the Lookup property’s value: it should match what you entered in the dialog box.

Sample - worbkook customized for each class

Lab: Place a REST API under load

In this scenario, you’ll create a new REST project, along with a TestSuite, and TestCase. Your test will send a clientid (a number between 1 and 1000), username, and password to an authentication service that will return an authorization token.

Note that:

• You’ll find the REST API endpoint next to the Temperature Authentication API entry. Paste that into the URL field when you create your project, use the default GET method, and then select the Create TestCase option. • Optional: instead of hardcoding your input values, consider using a DataSource TestStep using the Data Generator. Make sure it’s placed above the REST Request TestStep, and remember to link its properties with the input fields for the REST request TestStep. Don’t forget the DataSource Loop. • Once your TestCase is ready, right-click on it and generate a new LoadUI test by choosing the Create Load Test option. • When you configure your load test, use the following values o Run scenario on your own computer o Test duration: 60 seconds o Profile: Fixed o Virtual users: 5

Once you’ve set up your TestCase and related load test, run it and evaluate your results.

If you get stuck, your instructor will demonstrate the complete solution.

Sample - worbkook customized for each class

Case study: Design a comprehensive testing plan

In this scenario, you’ve just joined the staff of Pay-n-Pray Motors, a deep- discount car rental agency. The company is expanding operations to serve some of the largest airports in the world, including:

• Beijing (PEK) • Chicago (ORD) • Dubai (DXB) • London (LHR) • Los Angeles (LAX) • Mumbai (BOM) • New York (JFK) • San Francisco (SFO)

Pay-n-Pray categorizes its battered, dented fleet of vehicles in the following classes:

• Subcompact • Compact • Intermediate • Full-size • SUV • Van • Luxury

To interact with major online reservations systems, Pay-n-Pray will be creating a series of Web services and REST APIs.

The first Web service (Availability) contains only one operation (CheckCarInventory) that reports on the immediate availability of a particular vehicle at a particular airport for a given number of days. It will accept the following inputs: Sample - worbkook customized for each class • Airport (must be in the airport list above) • VehicleClass (must be in the vehicle class above) • NumberOfDays (must be greater than or equal to 1, and less than or equal to 30)

The Web service will return two results elements:

• NumberOfVehicles (either the number of available vehicles (0 means none available), or -1 to indicate an error)

• Message (either ‘Success: vehicles are available’ or a SOAP fault error message)

The REST API (Location) returns details about the rental location. It accepts the following parameter:

• Airport (must be in the airport list above)

It returns two results, in JSON format:

• The location’s GPS coordinates • Today’s hours for the location

Now that we’ve described the background, let’s look at your tasks. For each one, take a few minutes to write down (at a high level) how you would go about performing it.

1) Your first responsibility is to connect to the Web service and the REST API to just make sure that they return some data. What’s the quickest and easiest way to do this?

2) Next, it’s time to get more formal with your testing and create the proper container(s). What should you create to hold your TestSteps? a. What’s the right sequence of these containers? b. What kind of TestStep should you use to communicate with the Web service? What about for the API?

3)Sample Now that you’ve - worbkook got a working customizedtest, it’s time to experiment for each and send class the Web service some different data and see what happens. For now, you’ll send the service hard-coded data, one call at a time as follows: a. BOM, Subcompact, 2 b. DXB, Luxury, 33 c. SFO, Van, 0 d. ALB, Compact, 3 e. ORD, Intermediate, 10 f. LHR, Full-size, 5 g. LAX, Ferrari, 7

Looking at these examples, can you identify which ones should trigger an error from the service? What would you do to verify that a standardized Web service error has indeed been created?

For the valid entries, how can you test that the service is returning the proper results?

How would you structure your tests to ascertain results for both good and bad data?

4) With your tests in place, it’s now time to test the Web service for other important attributes, including: a. Results returned within a certain number of milliseconds b. Results are in a well-formed message c. Results match their schema

How would you modify your tests to reflect these new requirements?

5) For the REST API, you already know the GPS coordinates for each location. How can you evaluate a particular position in the response message to make sure it’s correct? How can you automate this so that you don’t need to check it visually?

6) You arrive at work one morning to learn that management wants you to test the Web service using 150,000 combinations of airport, vehicle, and Samplenumber of days.- worbkook After catching customized your breath, you realize for thateach there’s class a fairly straightforward way of doing this. What would you do next? How would you go about it?

7) Once your new testing plan is in place, management informs you that it’s now necessary to keep a permanent record of the results returned from the Web service as well as the REST API. What would you do next? How would you go about it?