Create modular performance tests to save time and increase reuse: Part 2. Tutorial

A real-world example of using Rational Performance Tester test variables

This is Part 2 of a two-part series on creating modular performance tests by using the IBM® Rational® Performance Tester split test functionality and then dynamically exchanging data between tests by using the test variable functionality. This part is a step-by-step tutorial for how to use the functionality to exchange data between tests at run time, without using a user-generated data pool.

Karline Vilme (kvilme@us.ibm.com), Software Quality Engineer, IBM

Author photoKarline is a staff software quality engineer with the IBM Software Group. She focuses primarily on system verification, integration, and performance testing for the Rational Performance Tester tool. She joined IBM in 2000 and has held several system administrator and senior customer support positions with the IBM Global Services group.



05 October 2010

Also available in Chinese

Introduction

This tutorial provides step-by-step instructions for how to use the Rational Performance Tester test variable functionality to exchange data between tests at run time without using a user-generated data pool.

Before you start

Be sure to read Part 1 of this two-part series first: "Use Rational Performance Tester split test and test variable functionality to exchange data between modular tests." See "View more content in this series," under the Summary, for a link to that article.


In this example, you will see how four SAP test modules are combined and used in a real-world user scenario. The test modules include Login, Create order (VA01), Delete order (VA02), and Logout tests. They were derived by using Rational Performance Tester split test functionality. The test variable functionality is used to exchange data between the Create and Delete order test module.

Step 1. Declaring a test variable

The first step of defining a test variable is to declare it. To declare a variable follow these steps:

  • Right-click on the Test Variables container.
  • Click Add.
  • Click Variable Declaration and enter a variable name.
Figure 1. Variable declaration
Declaring test variables, drop-down menu selections

Step 2. Setting test variable scope

After the test variable is declared, you need to set its scope. The test variable scope determines whether it is visible to other tests or not. You can set it to either of these options:

  • Visible in "This test only"
  • Visible in "All tests for this user"

When a test variable is set to be visible in "This test only," this means that it is a local variable and can be referenced only within the test for which it is declared. The test variable is stored in the data area and is not visible to other tests. It can be accessed only through custom code.

When a test variable is set to be visible in "All tests for this user," it is a per-user (global) variable. Its value can be persisted between tests.

A test variable can be set to a text string or other data source value. You can also handle runtime errors when the test variable is not initialized.

For this example, the test variable scope is set to "All test for this user," because it will be shared with other tests.

Figure 2. Setting the scope of the variable
Fields associated with a test variable

Step 3. Creating a "SAP get" element

For this particular example, it is necessary to create a SAP Get element because the response is embedded into a SAP GUI object (screen). The SAP Get element retrieves the string from the screen to be used as a reference

To create a SAP get element, follow these steps (illustrated in the screen capture in Figure 3):

  1. With the test already opened, expand a transaction.
  2. Click the test element (screen) that you want to retrieve the string from, and the screen is automatically displayed in the SAP Protocol Data view.
  3. Click to select the string from the screen.
  4. Right-click the string and select Create element.
  5. Select SAP Get on the next screen.
  6. Click the Finish button to create the element.
Figure 3. Creating a SAP test element
The SAP create element screen

Step 4. Creating a field reference

For this particular example, it is necessary to create a field reference rather than a reference, because the entire string needs to be passed as an argument to the custom code to extract the order number from it.

To create a field reference, follow these steps (also see Figure 4):

  1. Select the SAP Get element that you created in Step 3.
  2. Right-click the SAP Get element in the test element details view.
  3. Select Create Field Reference and provide a name for the reference. This example keeps the default name, but always use names that are meaningful for your references. This will make it easier to identify them later.
Figure 4. Creating a field reference
SAP create field reference screen

Step 5. Passing a field reference to custom code

Given that the Delete order (VA02) test cannot use the response from the Create order (VA01) test in its current form, a custom code is used to extract the order number from the field reference created in Step 4. The field reference is passed as an argument to the custom code.

To pass an argument to a custom code (see Figure 5):

  1. Click the custom code. The custom code properties are displayed in Test Element Details area.
  2. Click the Add button in the arguments section, and another screen will be displayed.
  3. Click the reference and click the Select button. The reference will appear in the argument section.
  4. Save the test.
Figure 5. Passing a field reference argument to custom code
Passing argument to Custom code

Custom code uses in this example

The first block of the custom code extracts the order number from the field reference, assigns it to the orderNumber variable, and returns orderNumber so that its value can be used by the test. The second block of the custom code writes the value of orderNumber to a file (see code Listing 1). This part is not necessary, but it serves as validation that the code is working correctly.

Listing 1. Custom code example
package test;

import com.ibm.rational.test.lt.kernel.services.ITestExecutionServices;
import java.io.*;
import java.util.StringTokenizer;

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

    private static Object mutex = new Object();
    /**
     * Instances of this will be created using the no-arg constructor.
     */
    public Extracting_OrderNumber() {
    }

    public String exec(ITestExecutionServices tes, String[] args) {
        
        StringTokenizer userVarTokens = new StringTokenizer(args[0], " "); 
            //$NON-NLS-1$
        String orderNumber = "";
        String tempStr = "";
        while (userVarTokens.hasMoreTokens()) {
            tempStr = userVarTokens.nextToken(); //$NON-NLS-1$
            //tes.getTestLogManager().reportMessage(tempStr);
            try {
                long i = Long.parseLong(tempStr);
                orderNumber = tempStr;
            //    return orderNumber; //new statement added 5/06/09.
                
            }
            catch (NumberFormatException ne) {
            }
        } //Writing orderNumber to a file
        try {
            synchronized (mutex) {
            FileWriter outFile = 
                new FileWriter("C:\\SAP_OrderNumberI4_99U.csv", true);
            outFile.write(orderNumber + "\r\n");
            outFile.close();
            }
        } catch (IOException e) {
            tes.getTestLogManager().reportMessage(
               "Unable to write to C:\\SAP_OrderNumberI4_99U.csv");
        }
        return orderNumber; //change from return null, 
            to return orderNumber on 5/06/09
       }            

    }

Step 6. Assigning the custom code to a test variable

In this last step, the test variable orderNumber variable in the Create order (VA01) test module is assigned the custom code returns value. The value stored in the orderNumber variable will be used as input to a request in the Delete order (VA02) test module.

To set the test variable in the "Create order" (VA01) test module:

  1. Right-click on a test element and click Insert (as shown in Figure 6). Optionally, you can click Add. Ensure that the set variable statement is placed immediately after the custom code. You can use the Up and Down buttons to move the custom code to the appropriate location.
  2. Select Variable Assignment.
  3. Select the test variable (orderNumber in this case).
  4. Click OK.
Figure 6. Assigning custom code to a test variable
Setting test variable value

Figure 7 shows a complete test depicting all of the steps for creating and setting a test variable in a test.

Figure 7. A test showing Steps 1 through 5
Screen capture with Steps 1 through 5 labeled

The next two steps show how to reference test variables between the test modules.

Step 7. Declaring a test variable for the second test

In the second test module (Delete order), declare a variable with the same name as in the first test module (Create order).

Step 8. Substituting test data within variable

In this example, the second test's data (orderNumber) is substituted with the variable declared in Step 7.

Figure 8. Substituting test data with the test variable
Test Contents and Test Element Details selections

Step 9. Using the test modules in a schedule

This step shows a schedule modeled using the test modules. This workload emulates a user scenario that creates and deletes orders from a SAP system.

Figure 9. SAP schedule models using SAP test modules
Example of a schedule using SAP test modules

When reusing test modules in a schedule, it is essential to maintain the general structure of a test. For example, SAP test structure will need to include a Login, some other tasks, and a Logout. It is also important to review the tests modules before running the test to ensure that test variables have been defined and set appropriately between the test modules.

For SAP tests, the Login and Logout test modules do not need to be linked with other test modules. This is because transactions are often used to navigate through a SAP system, and SAP tests are already segmented in transactions. The execution will flow sequentially from one transaction to the next. However, you need to ensure that the first test ends on the appropriate screen, which will provide an entry point for the subsequent test. This is why it's important to always return to the SAP Easy Access screen at the end of each transaction when recording the test.

The user scenario models in this schedule can be expanded by adding more test modules or made smaller by removing one of the modules.


Applying these steps for an HTTP scenario

The steps described in the previous section can be used for an HTTP scenario but with a few differences. Steps 3 and 4 are specific to SAP GUI tests. You can check Rational Performance Tester Help (documentation) to learn more about creating references and data correlation for HTTP tests.

When combining split test modules from different HTTP tests, it is critical to ensure that links exist between the test modules. Rational Performance Tester automatically creates links between test modules split from the same test recording for HTTP through test variables, and they are saved in the test variables container, Variables Created by Split Test, as shown in Figure 10. However, you will need to manually link test modules that are created from different test recordings to use them with other test modules (see Figure 11).

To manually link test modules that are created from different recording, you need to make sure that variables are created and assigned with values by a test module that is executed before and after that particular test module.

Figure 10 shows a scenario that combines three test modules derived from the same HTTP test recording. The links between the test modules were created automatically by the Rational Performance Tester split test process. Notice the test variables that are declared and set by the Login test module, which are then used by the second test module. In addition, the second test module also declares and sets test variables that are then used by the Logout test module.

Figure 10. HTTP Test modules linked through test variables
Linking test modules through test variables

Figure 11 shows a scenario that combines three test modules derived from different HTTP test recordings. The first (Login) and third (Logout) test modules are from the same recording, but the second test module is from a different test recording. The links between these test modules were created manually.

Figure 11. Example of linking test modules from a different test
Linking tests from different test recording

This tutorial has demonstrated how you can link test modules from various test recordings through test variables and combine them to construct a user scenario. See the Resources section for more useful information.

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=548642
ArticleTitle=Create modular performance tests to save time and increase reuse: Part 2. Tutorial
publish-date=10052010