Testing SOA services using Rational Service Tester for SOA Quality

This article shows you how to use IBM Rational Service Tester for SOA Quality testing. You can use this tool to perform functional regression testing. Its unique, code-free design supports testers of all experience levels.

Rational Service Tester for SOA Quality is a functional regression testing tool for Web services. With this tool, you can create tests to validate the proper functioning of a single Web service or a group of Web services. Unique to this tool is that you can create these tests without having to program any special code. With this unique, code-free design, testers of all experience levels can test the simplest or the most complex Web services. It also enables testers to simulate a large volume of simultaneous calls to a Web service. With this tool, testers can assure themselves that their Web services can withstand any given transaction volume, from hundreds to hundreds of thousands.

The Rational Service Tester tool is well suited to the rigors of SOA testing. You can use heaps of XML messages for sending input to Queues residing in Queue managers, which pass the input XML to appropriate listeners and update the database. After the update, you need to check the acknowledgment message sent back from the process and the correctness of the data inserted into the database.

Each XML message is a representation of input data. If you executed the scrips manually, each test script takes approximately 2 - 4 hours for execution. However, using Rational Service Tester reduces this time to a few minutes. This involves simulating an XML call, creating configuration for IBM® WebSphere® MQ (message queuing) protocol, data driving the script, creating references, adding custom code, and so on.

Share:

Mohit Thareja (mohit.thareja@in.ibm.com), Test Manager-TFL, IBM

author photoMohit Thareja is a Test Specialist, leading the Transport for London (TFL) Test team. He has total of 7 years of experience. For past 5 years, he has been working with IBM. This includes approx 4 years with India Software Labs and the past 1 year with IBM Global Business Services. He is Certified Software Tester (CSTE) certified, and has worked on various forms of testing like functional testing, system, reliability, and so on. He is currently working with the TFL team, where he started working on the new version of IBM Rational Service Tester, introduced it to the whole team, and is now leading the team of 15 people. Initially he was working on the proof of concept (POC) for automation the test scripts, now he has a team of 4 people working full time on automation. Mohit has worked on automation tools like Rational Functional Tester, Rational Robot, Rational Test Manager and HP Quick Test Professional. He has also worked on defect fixing and PMR (Problem Management Record) fixing work for the DCS (Document Conversion Services) component for WebSphere Portal Server and Quickr. He has also received congratulations for saving IBM hundreds of dollars by helping reduce the number of PMRs for WebSphere Portal Server and Quickr.



Abhishek Kumar Verma (abhiverma@in.ibm.com), Automation Lead-TFL, IBM

author photoAbhishek is an application developer. He has almost 3 years of experience in IBM as well as IT. He is Sun Certified Java Programmer (SCJP), IBM AIX (Advanced Interactive eXecutive), and SQL certified. He is currently in TFL test team as Automation Test Lead, where he is working in Rational Service Tester Version 8. He has initially automated a number of scripts alone as Proof of Concept and now he has prepared a regression suite to run automated scripts against each build. Abhishek works full time to automate test scripts and train his team members on how to use Rational Service Tester. He has been leading a team of 5 automation testers. He has also worked on number of automations tools like Rational Functional Tester, SOAP UI Tool and Rational Performance Tester.



15 June 2010

Also available in Chinese

Functionality overview

This article covers the following topics:

  • Introduction to IBM® Rational® Service Tester for SOA Quality
  • Key features of Rational Service Tester
  • Creating an automated test script
  • Creating a schedule
  • Creating a data pool
  • Creating a configuration protocol for IBM® WebSphere® MQ
  • Adding custom code
  • Types of verification points
  • Optional elements
  • Executing a script
  • Analyze logs

Introduction to Rational Service Tester

Rational Service Tester is an automated Web services testing and SOA testing tool. It is a functional and regression testing tool that enables relatively code-free testing of non-GUI Web services. It also provides a single client to interact with any service-oriented architecture (SOA) service type. It supports both Linux® and Microsoft® Windows® operating systems.


Key features of Rational Service Tester

Rational Service Tester:

  • Supports Web services standards including SOAP (Simple Object Access Protocol), HTTP and HTTPS (Hypertext Transfer Protocol Secure), JMS (Java™ Message Service), WS-Security (Web Services security), and UDDI (Universal Description, Discovery and Integration)
  • Simplifies how you create, understand, modify, and execute Web services testing
  • Supports the use of XML calls and SOAP over WebSphere MQ
  • Supports custom security APIs to ensure message integrity
  • Generates customized reports
  • Provides testers with automated script-free testing capabilities for functional testing, regression testing, and performance testing of non-GUI Web services.
  • Offers many options for validating Web service responses
  • Provides a visual test editor that delivers both high-level and detailed test views

Creating an automated test script

To create a new automated script, you first need to create a Web Service project.

  1. Select File > New > Others > Test > Service Test Project, as shown in Figure 1. Click Next.
Figure 1. Creating a Service Test project
Image displays the creation of Web Service Project
  1. After you create the Web service project, select File > New > Others > Test > Web Service Test. The following series of screen captures illustrate the steps to create a complete test.
  2. Select the project folder in which you want to create the testsuite, in below figure All_IMG has been selected and then provide a Test file name. By default it shows the name as New Service Test.testsuite, here we'll provide it as New Serive Test.testsuite, as shown in Figure 2. Click Next.
Figure 2. Provide the name of the test
Select Location and name of the test
  1. Next, select the type of call that you want to create (in this example, XML call), as shown in Figure 3. Click Next.
Figure 3. Select the type of service call
Select Type of Service call
  1. Choose the WebSphere MQ protocol radio button. Select Default MQ Protocol from the Protocol configuration drop-down list, as shown in Figure 4. Click Next.
Figure 4. Protocol selection
Choose type of protocol or create new

While creating the Web Service test, you need to configure the protocol for the test script. You can also use the existing protocol settings. In MQs, you have a dedicated WebSphere MQ listener process that monitors the request queue for incoming messages and then routes them through to the target Web Service. To configure MQs, you need to provide information like the Queue Manager name, Queue name, and IP address (the IP address is localhost in this case, because you are using port forwarding).

  1. Click Finish and add the XML message in the source under the Message tab, as shown in Figure 5.
  2. Update node name automatically updates the name of the response message automatically, uncheck it in case you want to provide user specific names to the request and response XML messages.
Figure 5. Adding XML message
Adding XML message and its source view
  1. When you click the Update Return button, it sends the XML request on to the Queue mentioned in the protocol configuration. When you get a response, you are prompted to choose the display content format. You can choose either XML Content or Text Content. Select either of the formats and click OK, as shown in Figure 6.
Figure 6. Update Return and select view format
Adding response to the test by update Return
  1. Figure 7 shows the response message in XML format. This is the actual content returned by the service. There are 3 different views:
    • Form
    • Tree
    • Source
Figure 7. Adding response message in the test
Source view of Response message.
  1. To add the response to your Web service test, click Update Test. After the response is added into your test, you can add verification points to it.

Creating a schedule

A schedule specifies which tests to run and in which sequence. In this example, you create a schedule that loops your test five times, using the first five values in your datapool.

Follow these steps to create your schedule:

  1. Select File > New > Performance Schedule.
  2. In the Performance Schedule dialog, click your Web Service Tests project to select it as the parent folder.
  3. In the Name field of the Performance Schedule dialog, enter the name: Web Service Test Schedule.
  4. Click Finish to create the schedule. You will see the beginnings of your schedule, as shown in Figure 8.
  5. On your schedule in the Schedule Contents section, right-click the <User Group 1> (100%) branch (in this case, Abhishek), and select Add > Loop or Add > Test.
  6. In the Schedule Element Details section, enter Number of iterations.
  7. On your schedule if you want to add Test under the loop, create a loop as described in above step and right-click the Loop (n iterations) branch, and select Add > Test.
Figure 8. Schedule
Creation of schedule which contains 2 tests.

Creating a datapool

Rational Service Tester automatically parameterizes generated tests so that the same Web service call can be validated with multiple sets of test data. Additional data is stored in a spreadsheet-style table. This ensures maximum code coverage without having to modify any test code. A datapool like that shown in Figure 9 is nothing but a table that contains the data that you need to substitute in your XML message. Datapools provide tests with variable data during a run.

Figure 9. Datapool overview
Sample Data pool which is being used in test

These are the steps that you follow to create a datapool:

  1. Select the test suite.
  2. Click New and then select Datapool.
  3. Define the name and location of the datapool.
  4. Define the description of the datapool (that is, the number of records and number of variables).
  5. References are used to pass on information from a field to variable.

A Reference is used to pass the data from the XML message to a variable being used in your custom code. Substitutions are used to replace the values of different elements of XML with each iteration. You can substitute a value either from the custom code (on success it is highlighted in pale yellow) or from the datapool (on success it is highlighted in dark green, as shown in Figure 10).

Figure 10. Substitution from datapool and code
Substitution from datapool and code

Creating a configuration protocol for IBM WebSphere MQ

  1. Choose Protocol and set the corresponding configuration options.
  2. Select the type of protocol to be used (either HTTP, JMS, or WebSphere MQ).
  3. In this case the protocol used is WebSphere MQ as shown in Figure 11.
  4. For Protocol Configuration, click New and provide the necessary information such as Queue Manager Name, Queue Name, Queue Manager Address, port and Client Channel
  5. Click OK and press Next.
  6. The information used to create this Protocol is available from IBM WebSphere MQ.
Figure 11. Protocol Config Setting
Creating new protocol configuration using MQ

Adding custom code

The custom code implements the ICustomCode2 interface for the creation of the custom code and the ITestExecutionServices interface to add custom messages and custom verification points in the test logs. Verification points are reflected in the overall schedule verdict. The ICustomCode2 interface requires an implementation of the exec method. This is the method which is called to execute the user Java class. The ITestExecutionServices interface provides a mechanism by which the user Java test code can gain access to support services (such as verification points, custom messages, verdicts, and so on).

Properties of custom code

  • Custom code 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.

Code listing

Listing 1 Custom code shows how to pass parameters to your code for eg. in the sample code 2 command line arguments are passed MessageVRM and ListId. It also shows DB2 connectivity and execution of SQL queries.

A string variable contains the complete SQL query which needs to be executed. Class CustomDB2Connection contains all the methods required to connect to the database and execute SQL queries.

In the sample code we create a object of CustomDB2Connection class (db2c) and use connect () to connect to the database then query(QUERY) is used to execute the SQL query which is passed as an String argument to the method. query is the method name and QUERY is the string argument passed into it.

Result of SQL query is store in a String variable numberOfRecords.

Listing 1. Sample code for DB2 connectivity
package test;
import java.sql.ResultSet;
import org.eclipse.hyades.test.common.event.VerdictEvent;
import com.ibm.rational.test.lt.kernel.services.ITestExecutionServices;
public class VEH003_010_preEvidence implements
		com.ibm.rational.test.lt.kernel.custom.ICustomCode2 {
	public VEH003_010_preEvidence() {
	}

	/**
	 * For javadoc of ICustomCode2 and ITestExecutionServices interfaces,
	  select 'Help Contents' in the
	 * Help menu and select 'Extending Rational Performance Tester 
	 functionality' -> 'Extending test execution with custom code'
	 BY Abhishek*/
	public String exec(ITestExecutionServices tes, String[] args) {
		String MessageVRM = args[0];
		String ListId=args[1];
		String numberOfRecords=null;

		String QUERY = "SELECT COUNT(*) FROM LRUCCORE.vehiclelistentry
		 WHERE VRM='"+MessageVRM+"' and vehiclelistid="+ListId+" and 
		 Effectivetodatetime='2999-12-31 00:00:00.00000'";
		tes.getTestLogManager().reportMessage(QUERY);
		CustomDB2Connection db2c = new CustomDB2Connection
		("IPAddress", "port no", "database", "userID", "Password");
		ResultSet results;

		try
		{
			db2c.connect();
			results = db2c.query(QUERY);

			// goto the last row (if more than one)
			results.last();
			numberOfRecords = results.getString(1);

Optional elements

There is a set of optional elements that you can use in a test to enhance its functionality:

  • You can use service call elements in tests to send a request to the service, which is an XML message.
  • In the test editor, return message elements are located after the service call. It displays the content returned by the service.
  • You can automatically generate or update the contents of a message return by clicking Update Return in the call element.
  • A conditional block issues portions of a test depending on the value of a reference. The reference must exist in the test and precede the conditional block.
  • You can define part of a test or schedule as a loop that runs a specified number of times. Loops can be time based, count based, or infinite.
  • You have not implemented transactions in a TFL project, because transactions are basically used to test the performance of a specific group of test elements. When you view the test results, you can view performance data about any transactions that you have added.

Types of verification points

  • Equal verification point enables you to check that the contents returned by a service exactly match the contents specified in the verification point
  • Contain verification point checks that part of the contents that are returned by a service matches the contents specified in the verification point. It passes even if the actual value is a substring of what is expected.
  • Attachment verification points enable you to verify that an expected attachment is delivered with the message return. This verification point is useful when you expect any attachment in response message. It enables you to check that the attachment of a Web service message return matches the specified criteria. This verification point returns 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.
  • With Query verification points, you can check that the number of nodes returned by an XML Path language query matches the expected number of nodes specified in the verification point.

To add a verification point, right-click and select the type that you want, as shown in Figure 12.

Figure 12. Add a verification point
Adding of verification point on response XML

Executing a script

At this point, you've created your test and you've scheduled it for execution. For the most part, your work is done. From here on in, Rational Service Tester will launch and execute the test and present you with the test results.

Execute the test

Executing the test is very simple. Just follow these steps to launch the test:

  1. In the Test Navigator view, right-click the Web Service Test Schedule and select Run As > Performance Schedule.
  2. The Launch Schedule dialog is displayed as Rational Tester prepares to run your test. Next, you will start to see live results from your test accumulate in the Web Service Test Schedule - Web Services Performance Report view.
  3. Your test is complete when you see the status turn to green in the Overall tab of the view, as shown in Figure 13.
Figure 13. Execution is complete
Completed execution of single test

Analyze Test Results: Functional

You can analyze test results from a functional test or a performance test perspective. From a functional test perspective, the objective is to ensure that the Web service returned the proper results for a given set of inputs. The test log is your main means of ensuring that you received the correct results. The test log gives you detailed information about every message sent and received between Rational Service Tester and the Web service. To analyze your results:

  1. In the Performance Test Runs view, right-click the Web Service Test Schedule [Time Stamp Information] and select Display Test Log.
  2. The test log includes two tabs: Overview and Events. The log opens to the Overview page, where you will see the pass or fail verdict and the timing information for the test. Your log should look something like that shown in Figure 14.
Figure 14. Logs
View of Test Logs for detailed messages
  1. Click the Events tab to see more detailed information.
  2. Expand the Events tree so that it looks like that shown in Figure 15.
Figure 15. Expanded test log events
Expanded view of Test logs

What you have learned

In this article, you learned about the key features of IBM® Rational®Service Tester. Then we saw how to use Rational Service Tester for SOA Quality to create an automated test script using IBM® WebSphere® MQ (message queuing) as a protocol for communication and datapool which can be used to test a functionality with variaton of data without changing automated test script. This article also includes the use of custom code in automated script and demonstrate a piece of it with an explaination. It also includes various verification points and optional elements which can be used to enhance scope of your automated script and execution of a indiviual script or schedule. At the later part of the article we learn how to analyse the logs.

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, XML
ArticleID=494630
ArticleTitle=Testing SOA services using Rational Service Tester for SOA Quality
publish-date=06152010