How to add elements and verification points to a Web service test using IBM Rational Tester for SOA Quality

Learn how to use IBM® Rational® Tester for SOA Quality to add verification points and other elements to your Web service tests. This Rational tool automates the process of creating, running, and analyzing functional, regression, and performance tests for Web services and applications based on SOA (service-oriented architecture).

Share:

Michael Kelly (Mike@MichaelDKelly.com), Consultant, www.MichaelDKelly.com

Mike Kelly is an independent consultant located in the Midwest of the United States. Mike also writes and speaks about topics in software testing. You can find most of his articles and his blog on his Web site, www.MichaelDKelly.com.



09 October 2007

Also available in Chinese

Testing services and SOA applications

Author's Note

This article was written using IBM® Rational® Functional Tester version 7.0.0, IBM Rational Tester for SOA Quality version 7.0.0, Microsoft® Windows® 2000 Professional SP2, and the current (as of the initial publication date of this article) Google Web API.

IBM® Rational® Tester for SOA Quality automates the process of creating, running, and analyzing functional, regression, and performance tests for Web services and SOA-based applications. In this article, you will learn how to use this tool to add verification points and other elements to your Web service tests. Specifically, you'll look at the details of each verification point and each element, and you'll and a real example from a past project where everything had to come together to get even a simple test working. If you are not already familiar with Rational Tester for SOA Quality, take some time to read some of the introductory articles listed at the end of this article in Resources.


Verifying application behavior

To check the expected behavior of the application during a Web service test, you can add verification points after a message return. When you add verification points, the results from a Web service message return are compared with the expected data specified in the verification point test element. During the run, verification points produce a pass, fail, error, or inconclusive status in the Web Service Verification Point report.

There are three types of verification points that you can use:

  • equal or contain verification points
  • Xpath query verification points
  • attachment verification points

Adding equal or contain verification points

Web service equal or contain verification points enable you to check that the contents of a message return match the expected criteria. Equal or contain verification points enable you to directly compare the XML document that the Web service returns to the expected values. Like IBM® Rational® Functional Tester and IBM® Rational® Performance Tester, Rational Tester for SOA Quality supports regular expressions for verification points of this type.

To add an equal or contain verification point to a Web service test, follow these steps:

  1. Open the test editor, and select a Web service message return element.
  2. Click Add, and select either Contain Verification Point or Equal Verification Point, as shown in Figure 1.
Figure 1. Adding a verification point to your test
Adding a verification point to your test
  1. In the Test Element Details section of the test editor, type a name for the verification point, and select whether to include the namespace XML data in the check (as shown in Figure 2):
    • Enable Namespace aware to perform the verification on the qualified structure of the XML document, including the namespace tagging, instead of the simple name.
    • Disable Namespace aware to ignore the namespace tagging in the XML document, and to check only the simple name of the element and the final return value.
Figure 2. Equal verification point
Equal verification point screen capture
  1. In the Detailed, Overview, or Source pages, specify the expected XML data:
    • For an equal verification point, the expected XML data contains the XML document from the message return test element. If necessary, you can edit the expected XML data.
    • For a contain verification point, add the XML elements that you expect to find in the returned XML document during the test.

Adding Xpath query verification points

Web service query verification points enable you to check that a message return matches an Xpath query. XPath is a language for finding information in an XML document, and can be used to navigate through elements and attributes in an XML document. Query verification points enable you to check that the number of nodes returned by an XML path language query matches the expected number of nodes specified in the verification point. See Resources for a link to an article about creating XPath expressions.

To add XPath query verification points to a Web service test:

  1. Open the test editor and select a Web service message return element.
  2. Click Add and select Query verification point. You will see the dialog shown in Figure 3.
Figure 3. Query verification point
Query verification point screen capture
  1. In the Test Element Details section of the test editor, enter a name for the verification point.
  2. Type a valid XPath expression (a reference on XPath is included in the Resources section following), a comparison operator (=, >, or <), and the expected number of nodes that the query should return.

Adding attachment verification points

Web service attachment verification points enable you to check that the attachment of a Web service message return matches the specified criteria. Attachment verification points enable you to verify that an expected attachment is delivered with the message return. Attachment verification points return a Pass status when all of the criteria of an attachment match the expected criteria specified in the verification point test element. If any of the criteria do not match, the verification point returns a Fail status.

To add attachment verification points to a Web service test:

  1. Open the test editor and select a Web service message return element.
  2. Click Add, and select Attachment verification point (Figure 4).
Figure 4. Attachment verification point
Attachment verification point screen capture
  1. In the Test Element Details section of the test editor, type a name for the verification point, and specify the criteria to be verified. All criteria must match for the verification point to pass.
    • If you have multiple attachments, set the Index of the attachment to be verified to the index number of the attachment to be checked.
    • Specify the expected Attachment Size in bytes.
    • Specify the Mime type and Encoding of the attachment.

For any of these verification points, you can enable or disable each Web service verification point by selecting Enable Verification Point in the test editor.


Adding elements to a Web service test

You can add a variety of elements to a test, such as Web service calls, message returns, comments, loops, or conditions:

  • You can use Web service call elements in tests to send a request to the Web service.
  • You can use Web service message return elements to receive the results of a Web service call.
  • You can insert IF-THEN logic around portions of a test to run those portions only if a specific condition is met.
  • You can define part of a test as a loop that runs a specified number of times.
  • A transaction is a specific group of test elements whose performance you are interested in. Transactions can contain Web service test elements or other transactions.

You can add an element to a Web service test either of these ways:

  1. Right-click the root element in the Test Contents and select Add.
  2. Or right-click any of the request elements and click Insert, as Figure 5 shows.
Figure 5. Adding elements to a Web service test
Adding elements to a Web service test screen capture

Adding custom code

Custom code (shown in Figure 6) uses references in the test as input, and then returns modified values to the test. Custom code input values reside in references or field references. These references must be included in the tests. Within the tests, the references must precede the code that they affect. Verify that the test contains the references that are required for customized inputs to your code. For details about creating references and field references, see the article on adding dynamic data to your Web service tests in the Resources section. If you log custom verification point verdicts in your custom code, these are reflected in the overall schedule verdict.

Figure 6. Adding custom code to a Web service test
Adding custom code to a Web service test screen capture

If you click Generate Code, you'll see that you use the ICustomCode2 interface to create your custom code (shown in Listing 1), and the ITestExecutionServices interface to extend test execution. These interfaces are contained in the com.ibm.rational.test.lt.kernel.services package. You should be able to find the javadoc file for the ICustomCode2 and the ITestExecutionServices interfaces in the Help file. If the code that you want to call already exists, just change the class name to match its name. Click View Code to open the code in the Java™ editor.

Listing 1. Generated custom code
package test;

import com.ibm.rational.test.lt.kernel.services.ITestExecutionServices;

public class Class1176656623734 implements
		com.ibm.rational.test.lt.kernel.custom.ICustomCode2 {

	public Class1176656623734() {
	}

	public String exec(ITestExecutionServices tes, String[] args) {
		return null;
	}
}

To pass arguments to your code:

  1. Click Add.
  2. In the Custom Code window, select all inputs that your code needs. The Custom Code window lists all values in the test that can be used as inputs (references or field references in the test that precede the code) to your code.
  3. Click OK. The window closes, the selected references are added to the Arguments field, and the Used by table is updated with this information.

In the test, after your custom code:

  1. Locate a value that your code returns to the test.
  2. Highlight the value: Hold the left mouse button down and drag your mouse pointer over the value.
  3. Right-click the highlighted value, click Substitute from, and select the class name of your custom code. The custom code classes that you have added are listed. After you have made your selection, the value to be returned to the test is highlighted in orange, and the Used by table is updated with this information.

So why use custom code? Because you can use it to extend test execution in some way, including these common uses:

  • Manage the behavior of loops
  • Write custom results to a log
  • Run a batch file or program that sets up the environment needed for a test and resets the environment afterward
  • Correlate custom data

Adding a loop

You can define part of a test as a loop that runs a specified number of times, as shown in Figure 7. By adding a loop, you can repeat any part of your test for a set number of iterations. Loops can provide more sophisticated control than running a simple sequence of consecutive tests. The advantages of adding a loop are that the loop is visible, and that you can control the rate of iterations through the loop if needed.

Figure 7. Adding a loop to a Web service test
Adding a loop to a Web service test screen capture

If you select Control the rate of iterations, you can set the rate of iterations per millisecond, second, minute, or hour. You can also choose to have those iterations either Randomly vary the delay between iterations or use a constant rate. If you really need to model users accurately (that is, spread out randomly over a certain period of time), then it's also a good idea to select the Delay before the first iteration of the loop check box, which staggers the first delay in each iteration. These options are used mostly during a load test, but there are some situations where timing may be important on your functional test, and you may need to set the transaction rate.

Adding a condition

You can insert IF-THEN logic around portions of a test to run those portions only if a specific condition is met. In most cases, a conditional block issues user input actions depending on the value of a reference. The reference must exist in the test and precede the conditional block. If the reference that the conditional block will use for input does not exist, create it (as explained in the article on adding dynamic data to your Web service tests in the Resources section). On the other hand, the test might already contain the Web service call or message return elements that are to be used by the conditional logic.

When you select Conditional (If), you receive a prompt asking you if you would like to move the selected item into the IF logic. If you select Yes, the elements that you selected are copied under If in the Test Contents area (as shown in Figure 8) and into the Then field in the Test Element Details area (as shown in Figure 9).

Figure 8. Web service request nested within an IF conditional
screen capture with tree view
Figure 9. Test Element Details for the IF conditional
screen capture with conditional IF details

To add an Else block, select the elements under If that you want to copy to the Else block, right-click and select Insert > ELSE Block. You will again be asked whether you want to move the selected elements into the new block.

In the Test Element Details area, the First operand field is the reference that contains a string value to be compared with the Second operand, or a field reference to be used with the contains operator. The Operator field indicates the basis of comparison of the two operands (note that the two operands are strings). In the Second operand field, you can either select the input for the block (a reference that contains a string value to be compared with the First operand), or you can type in a value. When the defaults are used (both operand fields set to true and the Operator field set to Equals), the block is always processed. You can negate operators and perform case-sensitive comparisons if desired by selecting the appropriate boxes under Options.

Adding transactions, comments, and delays

Transactions, comments, and delays are fairly straight-forward:

  • A transaction is a specific group of test elements whose performance you are interested in. Transactions can contain Web service test elements or other transactions. You can use transaction elements to group Web service elements together to make the test easier to read.
  • During recording or editing, you can insert comments into your Web service test. Comments are helpful for documenting the scripts. Given that many tests are just XML, a small comment can go a long way towards explaining the intent of your test.
  • By adding a delay to your test, you can control the Web service calls. Delays can be set for milliseconds, seconds, minutes, and hours.

Putting it all together

On a recent project, we had an interesting scenario for our testing. The service worked like this:

  1. Submit an XML request to the service providing information.
  2. Receive an XML acknowledgement containing a confirmation number.
  3. Wait up to 60 seconds (the SLA, or Service Level Agreement, response time).
  4. Use the confirmation number to submit a second request to a different service to pick up the actual information you requested.
  5. Validate the XML response that is returned,

That's a bit more involved then your normal request-and-response Web service test case. Figure 10 shows how we put it together (the example uses the Google Web API).

Figure 10. Using multiple elements together in one test
Using multiple elements together in one test screen capture with tree view

In test suite shown in Figure 10, the following takes place:

  1. A request is sent to doSpellingSuggestion.
  2. The response from doSpellingSuggestion is verified to ensure that it contains a correct spelling suggestion.
  3. If the response contains a spelling suggestion, we wait 60 seconds and then submit the suggested spelling to doGoogleSearch.
  4. We check the response from doGoogleSearch for the correct search results.

Sometimes, you can get by with a simple verification point, but sometimes you need conditionals, and sometimes you need to add a delay or a loop. It all depends on the service that you're testing. Use the various elements available to you to develop the test that's right for you. If you find that you can't do what you need with the standard tools, ask yourself if you can do what you need with a custom code element.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=259625
ArticleTitle=How to add elements and verification points to a Web service test using IBM Rational Tester for SOA Quality
publish-date=10092007