Introduction to IBM Rational Tester for SOA Quality V7.0 and IBM Rational Performance Tester Extension for SOA Quality V7.0

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

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

27 Mar 2007

IBM Rational Tester for SOA Quality automates the creation, execution, and analysis of functional and regression tests for service-oriented architecture (SOA) applications. IBM Rational Performance Tester Extension for SOA Quality provides performance testing capabilities for those same SOA applications. This article covers some of the basic functionality of both offerings and shows a real example of testing a Web service.

Author's Note:
This article was written using IBM® Rational® Performance Tester Version 7.0.0, IBM® Rational® Tester for SOA Quality Version 7.0.0 Open Beta, Microsoft® Windows® 2000 Professional SP2, and the Google Web API that was available when this article was initially published.

The Rational Tester for SOA Quality is an extension of Rational Performance Tester. If you are not familiar with it already, taking time to the basics will help you here, because this article does not cover using that software. For more information on using Rational Performance Tester, see the links included in Resources.

When you get started, you set up your test environment with the libraries and configuration files required for your Java™ Message Service (JMS) or Simple Object Access Protocol (SOAP) Web services. For the example here, you will import a Web Services Description Language (WSDL) definition file that is required by the Web service that you will test. If you need to, you can also import security certificates and create SOAP security configurations with security algorithms for the Web service calls and message returns.

Before you can record your first test, you will need a WSDL file in your workbench. For this article, you are going to use the Google Web API to test the Google Spelling Suggestion. To add the WSDL file to your workbench, you are going to use the Web Services Explorer, a handy little tool that you will find that you use quite a bit.

Adding a WSDL file to your workbench

There are several ways to add a WSDL file to your workbench, but the easiest way is to use the Web Services Explorer. To launch the Web Services Explorer:

1. From the Menu, Select Run > Launch the Web Services Explorer (See Figure 1.)

2. This opens the Web Services Explorer, as Figure 2 shows.

3. Select the WSDL Page button in the top-right corner as shown in Figure 3.

4. In the Web Services Explorer Navigator view, select the WSDL Main element . This will display the Open WSDL action (See Figure 4.).

5. In the WSDL URL field, enter the URL to the Web service that you want to test. For this example, use http://api.google.com/GoogleSearch.wsdl. After you have entered the URL, select Go. (See Figure 5.)

After the WSDL binding details load, you should see the Operations (doGoogleSerach, doSpellingSuggestion, and doGetCachedPage) and Endpoints (http://api.google.com/search/beta2). In the Status view, you should also see a message that says "... was successfully opened."

Testing the new WSDL page

Now that you have your new WSDL page, you need to test it. This will tell you whether you have everything configured correctly in your environment. Your WSDL file may have security settings that you need to deal with, or you may need to configure proxy information in your configuration settings, or any number of other possible difficulties may arise. This way, you know that things are working before you record your first test. To test your service:

1. Click the doSpellingSuggestion link in the Actions view (See Figure 6.).

This opens the Invoke a WSDL Operation pane under the Actions view. There are two ways to use this action. One is the Form view (the view that you just saw in Figure 6), and the other is the Source view, which shows the XML code. To switch between views, click the Source link in the upper-left corner of the Actions view. You can toggle back and forth to use the view that you like best or need for the task at hand. For this example, stick with the Form view.

Note:
The Google API requires a license key, which you can create in the account registration section.

2. Enter your Google authorization key and the phrase that you want to spell-check. When you have entered that information, click Go. (See Figure 7.)

While you are making the call to the Web service, you will see a progress bar at the bottom of the screen. When the result returns, you will see it in the Status view, as Figure 8 shows. (You can toggle between Source and Form formats in this view also.)

3. Now that you know that your Web service works, add it to your workbench. To do this, in the Web Services Explorer Navigator view, select the root WSDL node for the Google API. This will display the WSDL Details view that Figure 9 shows.

4. In the upper-right corner of the Actions view, select the Import WSDL to workbench button shown in Figure 10. This opens the Import WSDL to workbench action.

5. Select your workbench project, check the Import WSDL document check box, ender a WSDL file name, and select Go. (See Figure 11.)

In the Status view, you should see a confirmation message. (See Figure 12.)

In Test Navigator view, you should see the WSDL file added under the project that you selected. (See Figure 13.)

Now you have a working Web service in your workbench that you can use for your testing. Next, you learn how to record a new test by using Rational Tester for SOA Quality.

Creating a new test from a recording

You create your test by recording Web service calls and message returns (similar to what you did above). You can do this through an HTTP proxy, a generated Java™ test client, or an existing Java client that is instrumented with API probes. When you start the recording, you interact with the Web service by generating calls. The session ends when you log out. The recorded session is a series of calls and message returns. You can also create Web service tests manually or from a Business Process Execution Language (BPEL) model.

In the example here, this will not be an issue, but for other Web services, must set up your test environment and incorporate these guidelines before you test you to be able to produce reliable tests:

• Configure the environment for testing JMS Web services: The JMS protocol requires access to the libraries that the server relies on. You must prepare an environment with these libraries to build a heavy JMS client, set the class path of the virtual machine that the workbench uses, and set the class path of the virtual machine that the Agent Controller uses.

• Configure the environment for SOAP security: SOAP security protocols require access to the libraries that implement SOAP security algorithms. You must prepare an environment with these libraries to use SOAP security, set the class path of the virtual machine used by Eclipse, and set the class path of the virtual machine used by the Agent Controller.

• Verify WSDL syntax compliance for JMS Web services: Various JMS providers vary in the syntax that they use for describing Web services. Before testing JMS Web services, you must ensure that your WSDL files are compliant with the requirements of the tool.

After the setup is complete, there are five ways to create a test:

• Record a Web service test by using the Web Services Explorer: You can record a Web service test through an HTTP proxy. When you record, the HTTP proxy (located on the local computer) records all of the message calls and message returns that occur between the workbench Web Services Explorer and the Web service.

• Record a Web service test by instrumenting a Java client: You can record a Web service test by instrumenting the source code of an existing Java standalone client. When you record, the recorder adds API probe source code to the source code of the Java client. When you run the client, the API probes record all of the message calls and message returns that occur between the client and the Web service. The original source code of the client is not modified.

• Record a Web service test by using an HTTP proxy: You can record a Web service test through a dedicated HTTP proxy. When you record, the proxy intercepts the Web service calls and message returns between the Java standalone client and the Web service

• Create a Web service test from a BPEL model: You can use Business Process Execution Language resources from your workbench to automatically generate a set of Web service tests that corresponds to the paths that are executed in the BPEL model.

• Create a Web service test manually: You can create a Web service test without recording by simply adding the test elements as required and manually editing the test element details in the test editor.

The next example describes recording a Web service test by using the Web Services Explorer. (Also se Figure 14.)

1. Select Create New Test From Recording from the File menu or the toolbar.
2. In the Create New Test From Recording dialog, select Web Service Recording using the Web Service Explorer, and then select Next.

3. Select the location for the test suite and enter a name for the suite. Select Next. (See Figure 15.)

4. The next dialog lists the WSDL files that you can record against. There are currently no files listed, so select Add (See Figure 16.).

5. This opens the WSDL resources in the workspace dialog. Select the GoogleSearch WSDL, and then select OK. (See Figure 17.)

6. You should now see the WSDL file listed. Select Next. See Figure 18.

7. Enter any port, timeout, or proxy settings for the test, and then select Next. (See Figure 19.)

8. Read the Privacy Warning, click the I accept check box, and select Finish. (See Figure 20.)

When you click Finish, a few different things will happen. First, the test recorder will initialize. You should see the Initializing Recording dialog while the recorder files are being deployed and started (See Figure 21.).

When the recorder has started, you will see the Recorder Control view in the bottom-right of the screen. It tells you where the recorder is listening and contains the Stop Recording button for when you are finished (See Figure 22.).

The Web Services Explorer will open with the WSDL page from your workbench (See Figure 23.).

At this point, you are recording. Go ahead and run any tests that you want to record. You can do this the same way that you did previously while testing the WSDL file in Web Services Explorer:

1. Select the operation that you want to use, fill in the form, and click Go. You will know that your tests are being recorded, because each time you make a call, an event will be logged in the Recorder Control.
2. When you are finished, click the Stop Recording button in the Recorder Control view, and a Performance Test Generator will display while your tests are generated. (See Figure 24.)

After the test generation process is complete, the test suite will open in the Test Editor view. You are now ready to make changes to your tests.

Editing your test

After recording, you can edit the calls and message returns in the test. You can replace recorded test values with variable test data, or add dynamic data to the test. You can also set verification points for the contents of the XML documents in the message returns.

Changing Test Element details

There are more items to change in a test than you can cover in this article, but here are some of the basics:

If you select one of your test elements in Test Element Details, the Overview tab is displayed by default. (See Figure 25.)

On the Test Element Details Overview tab, you should be aware of Time Out and Think Time.

• Time Out is the timeout value in milliseconds. If no response is received after the specified time, an error is produced.

• Think Time specifies the programmatically-calculated time delay that is observed for each user when this test is run with multiple virtual users. Think Time is a statistical emulation of the amount of time actual users spend reading or thinking before performing an action.

Note:
If you want to change the defaults for these fields, you can do that by clicking Window > Preferences > expand Test > expand Performance Test, and then clicking Web Service Test Generation. After changing a setting, click Apply.

If you look at the other views, the Source view allows you to view the source XML document for the call. The ID tags shown in the Source page refer to an internal representation for the test. If you remove these tags, you will remove any existing references and substitutions. You cannot recreate these tags after they have been deleted.

The Detailed view provides a detailed tree view of the call elements. The Attributes and Namespaces tabs enable you to edit element attributes and namespaces by using the Add, Edit, and Remove buttons. And the Attachments view lists any MIME (Multipurpose Internet Mail Extensions) attachments that are attached to the call.

When you look at the various tabs, you're going to see some values in green. Values in green are potential datapool candidates. There is more on datapools under Adding dynamic data to a Web service test, which follows.

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 add:

• 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 to be sure that 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. Like IBM® Rational® Functional Tester and Rational Performance Tester, Rational Tester for SOA Quality also supports regular expressions for verification points of this type.

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, so it 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. There is a reference on creating XPath expressions included in Resources.

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 for 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.

You can find more information on each of these verification points in the Help file for Rational Tester for SOA Quality.

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. For example:

• 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 portions only if those parts meet a specific condition.
• You can define part of a test as a loop that runs a specified number of times.

A transaction is the performance element that you are interested in within a specific group of test elements. Transactions can contain Web service test elements or other transactions.

To add an element to a Web service test, you can right-click on the root element in the Test Contents and select Add, or you can right-click on any of the request elements and click Insert. (See Figure 26.)

You can find more information on each of these elements in the Help file for Rational Tester for SOA Quality.

Adding dynamic data to a Web service test

The Web service protocol data view enables you to view the XML documents that form Web service calls and message returns. It also allows you to compare expected and actual XML data after test execution. If you navigate to the Detailed view in Test Element Details, you can add a data substitution for each value contained in the request.

If you right-click on the value that you want to substitute and select Substitute From, you can then select from Datapool Variables and Built-in Datasources. (See Figure 27.)

The available datapools are listed under the Common Options view of the Test Element Details when you select the root test element. You can associate datapools here, or you can associate them when you make the substitution. You can find more information on adding dynamic data in Help for both IBM Rational Performance Tester and Rational Tester for SOA Quality.

Running your test

Rational Tester for SOA Quality is a functional regression test tool. To run your test quickly with one user, all you need to do is right-click on the test suite, select Run As, and then select Performance Test. (See Figure 28.)

Rational Performance Tester Extension for SOA Quality is simply an extension to Rational Tester for SOA Quality that enables you to evaluate the performance of your SOA and Web services by playing back the same tests in a multi-user emulation environment. You emulate workload with Performance Schedules. Then you execute those schedules just as you would any other Rational Performance Tester test. Your tests can run repeatedly; you can specify an execution schedule and user groups to emulate a workload that is generated by a large number of virtual users.

Once you have those schedules, you can deploy test execution over virtual users that can be hosted on remote computers. Each virtual user runs an instance of the test client. Response times are measured and recorded. Verification points are checked and recorded.

Evaluating your results

You evaluate the results that the tests produce through the various reports that are generated during execution. You can also design custom reports. The default report that you see is the Overall Web Service Performance Report. That report is a bit simplistic in nature. Given this sample test, it's really only a percent complete indicator. However, if you flip over to the Summary Web Service Performance Report shown in Figure 29, you willl see a bit more detail.

In this report, you see how many users completed, how long the test took to execute, how many calls were executed, and how many calls were successful. If you have verification points, summary information for those tests will be shown here, as well as in Figure 30.

The other Web Service Performance reports available won't really make much sense in this context, given the simplicity of these test examples and given that these tests are based on only one user. However, there are other reports that you need to review. If you right-click on the performance test that you executed, you can display the test log for that run. (See Figure 31.)

In the test log, you can see all of the common properties that were used when the test was executed, you can see a detailed list of the events executed, and you can drill down to detailed properties for each event. If you have a verification point that fails (See Figure 32.), you can see the high-level properties for the verification point, the actual and expected result, and (if you have IBM® Rational® ClearQuest® integration enabled), any defects associated with the verification point. You can also add defects if necessary.

To see the details of verification points, use the Web Service Protocol Data view, as shown in Figure 33. In this view, you can see the details of the returned message envelope and the verification point.

For some reason, this view isn't shown by default, so you may need to open it by selecting Window > Show View > Other, and then, in the Show View window, selecting Test > WS Protocol Data.

Next steps

This article presents a beginner's look at service testing with IBM Rational Tester for SOA Quality and IBM Rational Performance Tester Extension for SOA Quality. If you are completely new to testing SOA and Web services, you will also benefit by taking the time to read and learn about the basics of XML, Web services, and Rational Performance Tester. The links in Resources section below will help you get started.

Resources

• Visit the Rational Tester for SOA Quality resource page on developerWorks for technical articles, free tutorials, and more.
  
  
• IBM Rational Performance Tester: "Introduction to IBM Rational Performance Tester V7.0" (developerWorks, Jan 2007) is an overview article that explores the product's features and shows them in action with a step-by-step example.
  
  
• IBM Rational Performance Tester: "Handling test data with IBM Rational Performance Tester 7.0: Part 1" (developerWorks, Jan 2007) shows you how to use datapools for test data.
  
  
• IBM Rational Performance Tester: "Handling test data with IBM Rational Performance Tester 7.0: Part 2" (developerWorks, Jan 2007) is an in-depth look at using files for very large sets of test data
  
  
• IBM Rational Performance Tester: Visit the Performance Tester resource page on developerWorks for training, technical articles, free tutorials, and more.
  
  
• SOA and Web services: " Deploying Web services with WSDL, Part 1" (developerWorks, Nov 2001) offers an introduction to Web services and WSDL.
  
  
• SOA and Web services: Learn about Simple Object Access Protocol (SOAP) in "Deploying Web services with WSDL, Part 2" (developerWorks, Mar 2002).
  
  
• SOA and Web services: Check out the XPath specification for details on expressing an XPath query.
  
  
• SOA and Web services: Visit the SOA area on developerWorks to get the resources you need to advance your knowledge and skills.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

• Get a trial download of IBM Rational Tester for SOA Quality V7.0.
  
  
• Get a trial download of IBM Rational Performance Tester V7.0.
  
  

• Get involved in the developerWorks Rational community by participating in the forums and more.

About the author

		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.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top