Request test steps are the workhorses of soapUI. Don't let the name fool you-- soapUI isn't just limited to SOAP test requests; request test steps are also available for HTTP, AMF (Action Message Format), and REST (REpresentational State Transfer) services and JDBC database queries. The general idea is roughly the same for all of these request test steps: enter information for the service or database you're trying to test, create a test request, query, etc., and validate the response.
See the soapUI starter articles for REST and JDBC for more information. One nifty extra feature (I think) worth mentioning is a web session recorder for HTTP/website testing; it allows you to click through a given web site and generates test steps based on your actions.
The MockResponse test step allows you to mimic a web service response, specifying the data returned via a script, a literal value, etc.
Like the test request test steps, MockResponses and MockServices are deep topics-- I'd recommend checking out soapUI's own MockServices help pages for more details.
Property-related test steps, not surprisingly, allow manipulation of properties. The Properties test step is fairly straightforward, allowing you to introduce properties mid-test case. Remember that if you reference the properties in a subsequent test step (which must be in the same test case), the property expansion syntax is "${PropertyTestStepName#PropertyName}". For example, to reference ElName1 in the screenshot below in another test step later in the test case, you'd use the property expansion "${ElementProperties#ElName1}".
The Property Transfer test step lets you copy properties between test components. When creating Transfers in a Property Transfer step you specify a source component (project, test step, etc.) and property and a target component and property.
The screenshot above illustrates an important way that properties and property transfers or references can be used. The source component in this case is a SOAP Request test step. The request test step's response is exposed in soapUI as a property. Using an XPATH expression, you can "drill down" further into the response to extract data from a specific XML node and transfer it to another component's property. This functionality is useful in situations where the response from a test request may need to be used as an input parameter elsewhere (a common example cited in soapUI's help is getting a session token from a login response that needs to be passed in a subsequent request).
Flow control test steps include Delay, Run Test Case, and Conditional GoTo test steps. The Delay test step is self-explanatory-- you're just specifying a time period (in milliseconds) to pause during a test run. Run TestCase test steps allow you to call one test case from within another. Configuring a Run TestCase step involves specifying the test case to run, providing properties to use when the test case is called, and specifying which properties you want returned from the test case being called.
In the Run TestCase test step shown above, the GetAtomicWeight test case is being called from within another test case. AtomicWeight, ElNameIn, and AtomicWeightCData are all properties of the GetAtomicWeight test case. When the test case is called, the ElNameIn property is set to "Helium", and the AtomicWeight property (in this case, extracted from a SOAP response) is returned from the test case run. You can use property transfers or references to work with that returned AtomicWeight value (with the property expansion "${Run TestCase#AtomicWeight}", for example).
A practical example of where this might be useful is with a test suite where you have a login test case that retrieves a session token that's sent with other requests-- suppose you want to generate session tokens for different users through the course of your test suite. You can just call the same login test case each time, passing in different usernames and passwords and returning their session tokens.
The Conditional GoTo test step evaluates a response (via an XPath expression) or property to control the test case flow-- if the response or property matches a specified condition, the selected target step is launched.
In the screenshot above, the Conditional GoTo test step checks to see if the AtomicWeight property equals 1.00797; once this is confirmed to be the case, the test case skips to the Groovy Script test step designated in the Target step drop-down. A practical use case for a Conditional GoTo might be a situation where you need to keep re-running a request until you get a specific response needed to continue on with the test case.
The last two test step types, Manual test steps and Groovy Script test steps, are their own animals. Manual test steps allow for manual activities that need to be done during the course of executing test cases-- creating a Manual test step is as simple as specifying the manual actions that need to be taken and the expected result(s). During test case execution, soapUI will pause while the actions are performed and the results are recorded.
Last (but certainly not least) is the Groovy Script test step, which should be pretty self-explanatory: you can write scripts in Groovy (described as "an object-oriented language alternative for the Java platform") to do pretty much whatever you want as part of your test suite.
In the next post I'll look at Groovy scripting a little bit more, using it to perform simple data looping...
Very impressed with your web design... very simple and to the point. You're the answer to my XPath issue - though the answer was easy - it took your site to show me! Thank you
ReplyDeleteHi,
ReplyDeletewhat are the possible conditions and its syntax can be used in Conditional Goto steps. For example, i want to check, my previous test step response will display the status code either as '0' (if success) or '1110' (if failure). So based on the response i need to run the respected next test steps. I am new to soapui, so please help me on how to use the syntax.
The conditions are written as XPath expressions; for details on XPath syntax, I recommend the w3schools.com XPath tutorial. As an example, though, if your status codes were contained in a node called "STATUS" in the XML response from your test request, the XPath expression to confirm the step passed might look something like this:
Delete//STATUS="0"
or
//STATUS/text()="0"
You'll also probably have to use namespace prefixes on those expressions (e.g., //ns1:STATUS="0"). You can generate namespace declarations automatically in the Conditional Goto dialog by clicking on the "ns:" button above the window where you enter your expression, then use the appropriate prefix in your XPath expression.