Test terminal-based applications with Rational Functional Tester

Review the script

Script overview

You've created an automated test. In fact, you have created an automated test that can be run again and again on subsequent builds of your application. The more you use this script, the more return on your investment you will see. There are really three components of the test -- the script, the object map, and the datapool. In this section, you'll examine these components in more detail.

The script

The script is the code in the center pane of the Functional Tester window.

If you are familiar with Functional Tester scripts for Web, Java, or .NET applications, this code will be pretty familiar to you. This particular script is recorded in the Java language. (Remember, you could just as easily use Microsoft Visual Studio .NET and record your script in Visual Basic .NET.) This means that if you are comfortable doing some coding, you can do anything in a Functional Tester script that you can do with a Java program. You can link in code that your developers have created, such as algorithms and classes, that can aid in testing. It also means that the scripting languages your testers are learning are an industry-standard languages, not proprietary ones. Testers who want to learn how to read the code will have countless books and online training courses available to help them out.

Even without formal Java training, you can easily read the script and understand what is going on. Let's look in more detail at a few statements. This statement tells Functional Tester to click within the host text box in the emulator:

hostText().click(atPoint(41,11));

This statement sends the keystrokes cicsa to the terminal, followed by the Enter key:

tFrame().inputKeys("cicsa{ENTER}");

This statement performs the properties verification point test on the status message field of the real-time quote screen:

Field_22_2_standardVP().performTest();

Since most terminal-based interaction is through the keyboard, there are fewer indications as to where you are in the script as compared to a Web or Java application. Note that the comment you added helps indicate where you are at this point in the script:

// Company Selection Screen
tFrame(ANY,LOADED).inputKeys("1{ENTER}");

Inserting frequent comments during recording is a good practice to adopt.

Back to top

The object map

So, if the script tells Functional Tester to perform a test on a certain field on the screen, how does Functional Tester know which field to examine? Each object you encounter while recording is cataloged into a test object map. You can see the objects you interacted with in the Script Explorer view to the right of the script view.

The object map does two things for you. First, it provides a single repository of information about the objects in your application. That means that if something significant changes in your application user interface, you have one place to maintain information. You don't need to search through your script for all the references to that object to replace recognition information for it. In this tutorial, you are using a private test object map. In a real project, you would want to use a shared test object map, which can be shared among numerous scripts and testers, reducing your maintenance even further.

The object map also maintains several pieces of information about your application's fields. When you play back your script, Functional Tester will consult the object map to determine which object or field is the right one to use. In this section, you'll take a closer look.

Double-click the object map entry field_16_63 in the Script Explorer view. A window appears that displays the test object map.

Many automated testing tools rely on just one property to identify an object during playback. But what happens if the value of that property changes? That often results in a playback failure and the need to change the expected value of the property in order to continue testing. Functional Tester is different. Here, Functional Tester has captured five properties and their values. Imagine that, in a future build of the application, the text property value is no longer 0100. Not a problem. Functional Tester still has four other properties to use to identify this object. What if a developer moves the field down one row on the screen in the next build? That probably still won't be a problem. Functional Tester uses an advanced object recognition system called ScriptAssure to analyze the fields on the screen and determine which is most likely the correct one, even if multiple properties of the object have changed since the script was recorded. How strict or tolerant you want Functional Tester to be is something you control through the preference and weight settings for each property.

Click the very top element in the Object Map, labeled Java: Frame: TFrame: com.ibm.terminal.tester.gui.panel.TFrame. This object represents the terminal emulator frame. Notice that the .captionText and accessibleContext.accessibleName properties contain the name of the connection configuration used to connect to the application. Functional Tester picked up on the configuration connection name through the caption of the emulator window. In many cases, this is quite handy. It means that you can open multiple terminal emulator windows and interact with them in a single test session. Functional Tester will be able to tell one from another based on these recognition properties.

In your case, you want to use two connection configuration files -- one for version 1 and one for version 2 -- interchangeably. To override Functional Tester's default behavior, change the values in the weight column for the .captionText and accessibleContext.accessibleName properties to zero. You are effectively telling Functional Tester that you don't care about the caption of the emulator window.

Let's conclude our brief tour of the object map. Close the Object Map window. Click Yes when asked if you want to save your changes.

Back to top

The datapool

You probably noticed that the information you entered via the keyboard and the values you tested in your verification points are hardcoded in your script. But what if you wanted to perform the same test you just recorded over and over again, but vary the data you use slightly for each test run? Let's say you want to log in as a different user or buy shares in another company. Would you want to rerecord a new script each time? That seems pretty inefficient.

Data-driven testing and datapools address that need for efficiency. With data-driven testing, you can separate the test data from the test procedure in your scripts. Even though you didn't set up the datapool and data-driven test while recording, you can still do it now. Say you want to vary the username and password used to log into the share trader application. You first need to create an empty datapool, and then replace the literal or static data in the script with references to that datapool. To do so, following these steps:

1. Right-click Test Datapool in the Script Explorer and select Associate with datapool...
2. Select Private Test Datapool in the list of test datapools in the current project. A private test datapool is visible only to this one script. In a real test environment, you most likely want to create a shared test datapool, which would be visible from any number of test scripts. This enables you to efficiently share data sets among multiple tests and testers. Click OK.
3. Terminal-based test scripts will often contain a large number of literal text strings, and they might not always be in the format you want. For example, locate the following lines in your script:

   tFrame().inputKeys("jan{TAB}"); tFrame().inputKeys("janpwd{ENTER}");

   
   

   The first line enters jan as the username and presses the Tab key to move to the password field. The second line enters janpwd as the password and presses the Enter key. You want to extract the username and password text into your datapool, but leave the Tab and Enter commands in the script. Edit these two commands into the following four lines:

   tFrame().inputKeys("jan"); tFrame().inputKeys("{TAB}"); tFrame().inputKeys("janpwd"); tFrame().inputKeys("{ENTER}");

   
   
4. Search through the script looking for literal values that you can replace with datapool references. Functional Tester provides a wizard to do this for you. To allow the wizard to focus on the strings you care about, click near the beginning of the first of the four lines you just entered.
5. Use the Script > Find Literals and Replace with Datapool References menu command to invoke the wizard. If you clicked in the right place, the wizard will immediately find the literal string jan. At this point, you want to provide a name for the datapool variable, or column, to associate with this data. Type username into the Datapool Variable field. Check the Add Literal to Datapool check box. Click Replace to complete the substitution.
6. As soon as you clicked the button in the previous step, the wizard found the next literal string text in the script, which is {TAB}. You don't want to substitute this value, so just click Find to find the next literal.
7. Now the wizard has found janpwd. You do want to substitute this value, but with a new datapool variable. Type password in the Datapool Variable field, overwriting the default username. Click Replace to complete this substitution.
8. This is the last value you need to connect to your datapool, so click Close.

Notice the Test Datapool view in the lower portion of your screen. This is the table of data that can be used to drive your script. It has been pre-populated with the data extracted from the script by the wizard. You can enter more rows of data into this table using the context menu or import from CSV files. Unfortunately, the simulated host application consists of simple, static screens and will not respond to varied data, so this script can't be played back to effectively demonstrate varied usernames and passwords. If you want a more detailed example of datapools use, check out the tutorial mentioned earlier, "Automate regression tests: IBM Rational Functional Tester makes regression testing a snap" (see Resources for a link). This tutorial leads you through the process of setting up a data-driven test against a Java application.

Back to top

Review

You covered a lot of ground in this section, so it is worth taking a few minutes to review what you've done.

• You reviewed the three components of the test: the script, the object map, and the datapool.
• Your script captured the procedures of your test in Java or Visual Basic .NET -- powerful, industry-standard languages.
• Your object map captured the characteristics of the objects and fields you encountered during recording. The advanced playback mechanism called ScriptAssure utilized this map to ensure script resilience against user interface changes in your application under test.
• You created a datapool and used a wizard to extract literal data from the script and into a datapool. This separates the test procedure from the test data and enables you to reuse this script to perform countless similar scripts with unique data sets.

You are probably anxious to see Functional Tester play back the script. After all, that's the whole point, right? The next section will lead you through the process of playing back the test and analyzing the results.

5 of 10 | Previous | Next

Comments

Back to top

Table of contents

• Overview
• Why use the Extension?
• Getting started
• Create your test
• Review the script
• Run your test
• Wrap up
• Download
• Resources
• About the author

---

5 of 10 | Previous | Next

Next steps from IBM

• Try: Rational Functional Tester
• Briefing: Quality driven software delivery
• Buy: Rational Functional Tester

Dig deeper into Rational on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers