Test terminal-based applications with Rational Functional Tester



This tutorial is intended to introduce the first-time user to the Rational Functional Tester Extension for Terminal-Based Applications. What is this tool and why does it deserve such a long name? The Rational Functional Tester Extension for Terminal-Based Applications is an add-on, or extension, to Rational Functional Tester that enables the latter to perform functional regression testing on terminal-based applications. While the product name is very descriptive and utilitarian, it is a bit cumbersome in conversation. For brevity's sake, in this tutorial we'll generally just refer to it as the Extension.

This tutorial will help you record, edit, and execute your first regression test against a terminal-based application using the Extension. We will touch on some of the challenges of testing terminal-based applications and see how many of the core capabilities of Rational Functional Tester and the Extension meet those challenges. This is by no means an exhaustive tour of all the capabilities of Rational Functional Tester and the Extension. That could take days! This tutorial is really intended to give you a jump-start on the basics in about an hour.

Upon completion of this tutorial, you will have learned:

  • How to record a Functional Tester regression test against a sample terminal-based application
  • How Functional Tester captures your interactions with the application into a Java script
  • How ScriptAssure Technology makes your tests robust against user interface (UI) changes in the application under test
  • How to verify both static and dynamic content in your application

Who should take this tutorial?

If you are already an IBM Rational Functional Tester user and you would like to learn a little about the Extension that makes it possible to test terminal-based applications with that same tool, you are in the right place.

If you are searching for a way to automate the functional regression testing of terminal-based applications and have never used Rational Functional Tester -- or any automated testing tool, for that matter -- you might want to do a little homework before running through this tutorial.

If you already use the Extension and want to get a deep knowledge of how it works and can solve problems specific to your environment, you are probably not in the right place. As noted in the previous section, this tutorial will start at the beginning and quickly make you competent in the basics of recording and playing scripts against a terminal-based application. For more Rational tutorials, see Related topics.

System requirements

You are going to need a few things to complete the steps in this tutorial.

  • If you don't already own the Rational Functional Tester Extension for Terminal-Based Applications, you can download a fully functional trial version of Rational Functional Tester. The installation process is described later in this tutorial.
  • Functional Tester supports two scripting languages: the Java™ language and Visual Basic .NET. For crafting tests using the Java language, Functional Tester includes the Eclipse open source development environment. No further installation steps are required. If you want to use the Visual Basic .NET scripting language, Visual Studio .NET must be installed on your system before you install IBM Rational Functional Tester. Visual Studio .NET is available for purchase from Microsoft®.
  • In addition to Rational Functional Tester and the Extension, you will also need a small package,, for the purposes of this tutorial. This package will simulate the 3270 traffic from a host-based application.

Why use the Extension?

Functional regression testing

When I bought my house, the backyard fence was in pretty bad shape. One summer, I decided to build a new one. After a couple of days of hard work, the fence looked great. The next day, my neighbor came home from a trip and asked, "Is your phone working?" I knew immediately what had happened: when digging a post hole for my new fence, I had cut my neighbor's phone line. In trying to fix one problem (an old fence), I had created another problem without realizing it (my neighbor now had no phone service).

I tell you that story to illustrate a regression. Sometimes developing and maintaining software can be similar. When a developer adds a new feature or fixes a bug in the system, it is quite possible that the code being modified is used by a seemingly unrelated feature. How was I to know that the same patch of dirt I wanted for my fence post was also used for my neighbor's phone line? If we test only the new features each time we modify our code, we can't say for sure that all the things that used to work still do. In my case, the completed fence looked great, but unknown to me, my neighbor was no longer able to make phone calls.

The only way to know for sure that we have not broken existing functionality is to retest everything on every revision or iteration of our system. This is what's known as functional regression testing.

The challenge

Functional regression testing can be performed manually. The problem is that as a project evolves, that functional test suite becomes longer and longer. At some point, it may take more time to run the test suite manually than you actually have between builds!

When this happens, test teams are faced with tough choices. They have to find a way to decide which tests are less critical and can be omitted on some or all build tests. Now the door has been opened for regressions to slip into those untested capabilities of an application.

What is Rational Functional Tester?

Rational Functional Tester is an automated functional regression tool. This means that it uses a computer to execute the tests much faster than you could manually. The key to doing this is to have a way to capture interactions with an application and make those interactions available to be repeated later. You will be doing just that in a few moments.

Note that Rational Functional Tester is a functional regression tool. Rational Functional Tester is not intended to provide load for stress testing. For that, you need to look to Rational Performance Tester. In this tutorial, we will see how use the Extension to test the functionality of the application, not its scalability.

Getting started

Installation overview

There are a few things you need to do to prepare for this tutorial:

  1. Install Rational Functional Tester.
  2. Install the Java Runtime Environment.
  3. Install this tutorial's sample Host Simulator.
  4. Create a test project.

You may be able to skip some of these steps if you already have the software installed. But, we'll walk through each of them in the following panels.

Install Functional Tester

If you haven't already, install Functional Tester now. A fully functional trial version of Rational Functional Tester is available from developerWorks.

The Rational Functional Tester package includes both the Rational Functional Tester product (including the Extension for Terminal-Based Applications) as well as Rational Manual Tester. For this tutorial, you will only really need to download the two parts for Rational Functional Tester, but you may want to also download and evaluate Rational Manual Tester to see how it can help you organize and improve your manual testing as well.

Use the launchpad executable to get started installing. If you have not already installed a Rational product on your machine, the launchpad will start by installing the IBM Installation Manager which will then guide you through the rest of the installation.

On the screen where you are asked which packages to install, select only Rational Functional Tester. Complete the installation of Rational Functional Tester, then repeat the installation process and select Rational Functional Tester Extension for Terminal-Based Applications. The installation must be done in two passes in order to ensure proper installation.

Note again that if you intend to use Visual Basic .NET as a scripting language, Visual Studio .NET must be installed on your system before you install Functional Tester.

In this tutorial, you'll use the Java scripting language variant of Rational Functional Tester, but the Terminal-Based Application Extension works equally well with Visual Basic .NET scripting and Java scripting. Some of the menu paths will differ slightly if you are working with Visual Studio. Interestingly, the scripts created by Rational Functional Tester will be nearly identical in both languages. The only real difference is that Java is a semicolon-based language, so every Java command will end with a semicolon, whereas Visual Basic .NET commands will not.

Install the Java Runtime Environment

As you'll soon see, Functional Tester creates logs to inform you of what has transpired during test execution. By default, these logs are HTML documents. However, to provide additional information, Functional Tester will launch an application called the comparator that highlights any differences between expected and actual results. In order for Functional Tester to run the comparator, the Java Runtime Environment must be installed and configured.

Is the Java Runtime Environment already installed on my machine?

It's quite possible that you have a Java Runtime Environment (JRE) on your machine. If you do, you'll see a Java configuration icon in your control panel. Select Start > Settings > Control Panel. If you see a Java Plug-in option in the list of applications, then the JRE is installed on your machine. You do not need to install a second JRE.

Installing the Java Runtime Environment

The Java Runtime Environment is available from Sun to download. Select the appropriate link for your environment.

Install the host simulator

Writing an evaluation guide for a terminal-based application testing tool has one significant challenge: it is difficult to package up a sample application. To simplify the process while still providing the most value, we've made a Host Simulator available for this tutorial to download.

To install it, walk through the following steps:

  1. Extract the file into any directory of your choosing.
  2. Double-click the HostSim.bat file. This will launch a Windows command prompt window which will in turn launch two small Java applications. Each application is simulating a mainframe application, one on port 23, the other on port 24. You can minimize these two windows during the rest of the tutorial.
  3. To stop the simulators, simply close their Java console windows.

This Host Simulator is pretty simplistic. It provides a 3270E data stream that will serve as your application under test. Keep in mind that this Host Simulator is not a real application. You will find that it will progress from screen to screen in response to your keystroke commands, but these screens are static: the simulator does not actually analyze your keyboard input. It will work fine for the path outlined in this tutorial, but you cannot really deviate from that path. Stick to the script here and you will do fine. Once you have completed this tutorial, you will be ready to experiment with your own real terminal-based application.

Remember, this Host Simulator is only necessary to simulate a mainframe. At the end of this tutorial, in Clean-up, are instructions on how to remove or disable it from your system. You will never need the Host Simulator to test a real terminal-based application.

Create a test project

A test project is the location where Functional Tester will keep all of your scripts, along with expected and actual results. The format of the project is dictated by the environment you are using -- either Eclipse for Java scripting or Visual Studio .NET for Visual Basic .NET scripting. Again, you will be using Java scripting in this tutorial, but you can certainly use the Extension with Functional Tester Visual Basic .NET scripting.

  1. Start Functional Tester if it is not already running.
  2. Close the Welcome view, if it opens.
  3. You are now in the main editing environment for Functional Tester.
  4. Select File > New > Functional Test Project to create a new project.
  5. Name the project RFT Extension Tutorial and click Finish to create your project.
  6. If you are using the evaluation version of Functional Tester, a window will appear indicating the number of days remaining on your trial license. Click OK to acknowledge the message.

Create your test

View the terminal emulator

Let's start with a tour of the application you will be testing. This gives you a chance to see the Extension's terminal emulator before you actually record a script.

The Rational Functional Tester Extension for Terminal-Based Applications comes complete with its own terminal emulator. There is no danger of incompatibility with third-party emulators or risk of version incompatibility because the Extension's emulator is tightly integrated with Rational Functional Tester to ensure proper synchronization and data recognition with your mainframe application. You can still use any third-party emulator for your manual testing, if you want. You simply use the Extension's emulator to record your scripts, and Functional Tester will use it when it plays those scripts.

  1. Click Launch the Extension for Terminal-based Applications on the toolbar.

    This starts the Extension's terminal emulator. The top half of the screen has several controls that affect the ways in which the emulator connects to your application. You set the connection properties you need on the screen to connect to the mainframe that hosts your application. In the following steps, you'll connect to the simulated mainframe.

  2. Your simulated mainframe application is running on your local computer, known as localhost. Enter localhost in the Host field.
  3. The emulator supports testing applications that use 3270, 3270 Enhanced, and 5250 protocols. The simulated application uses 3270 Enhanced, so select TN3270E in the Terminal Type drop-down menu.
  4. Click Connect on the toolbar.

    You should see a screen like the one below.

If you get a Communication Error window, it's probably because the Host Simulator is not running. Go back to the HostSim folder and double-click HostSim.bat.

If the emulator appears to connect but the screen is blank, it is likely that you are attempting to connect using the 3270 protocol instead of 3270E. To return to the configuration screen, click Disconnect.

Then change to TN3270E and reconnect.

Notice the two rows of buttons across the bottom of the emulator. These are soft keys used to represent the PF keys and other special keys on a terminal. You will use these keys later during recording.

Let's take a little tour of the application you will be testing. If you have followed all the steps in the previous section, you should see the DEMOnet welcome screen in the terminal emulator. This will be the starting point for your application walk-through.

  1. Type cicsa in the terminal emulator window. You should see the characters you type displayed on the screen after the selection prompt. If not, make sure the terminal emulator is in focus. Cicsa is the name of the transaction server you want to use. To invoke the command, you can either press the Enter key on your keyboard or click Enter on the bottom of the screen.
  2. On the next screen, type the user ID dnet256. Press the Tab key twice. Now type secret as the password. Press the Enter key.
  3. Now you are logged into CICS. On the next screen, type RCTD. This is the transaction ID for a demo share trading application. Press the Enter key.
  4. This brings you to the Share Trading Manager: Logon screen. The screen ID, shown in blue in the upper right corner of the screen, should be TRADER.T001. On this screen, you need to enter the username and password for the Share Trading application. Type jan, press the Tab key, and then type janpwd as the password. Then press the Enter key.
  5. On the next screen, TRADER.T002, choose the company whose stock you wish to trade. Type the number 1 to select Casey Import/Export and press Enter.
  6. The next screen, TRADER.T003, presents the main option menu. Issue a real-time quote by typing 1 and pressing Enter.
  7. The next screen, TRADER.T004, presents several pieces of information. You will use this screen several times to test out the functionality of this application. Note that Jan holds no shares in this company. This would be a good baseline to check -- to ensure there are no shares held in this company when you start your test scenario. For now, back out to the main option menu by clicking the PF3 button along the bottom of the screen.
  8. Next, you want to buy 100 shares and verify that the order is placed properly. Option number 2 will take you to a screen where you can do just that. Type 2 and press the Enter key.
  9. You should now see screen TRADER.T005, the Buy screen. Type 100 and press Enter.
  10. You are immediately returned to the main option menu. Note the message across the bottom of the screen that indicates that the request was completed successfully. This is probably another thing you would like to verify -- that the request completes properly. You also want to make sure your holdings now reflect the newly purchased shares. You can use the Real-time Quote screen again to verify that your holdings have increased. Main menu option number 1 will take you to a screen where you can get a new quote, so type 1 and press the Enter key.
  11. Note on the real-time quote screen that the number of shares now held is 100.
  12. Click Disconnect to disconnect from the simulated host.
  13. You can save all the connection parameters you used into a connection configuration file. This doesn't just save you the effort of completing the setup every time you run a test; it also provides a consistent connection profile that all the testers on your team can share. To save the current connection settings, choose File > Save. Provide a name for the connection configuration file, such as ShareTraderV1.conn. (Note that the Save As window adds the .conn extension automatically.)
  14. Close the terminal emulator.

You just tested this application's buy capability manually. You dealt with a pretty simple scenario here, but you can see that if you needed to manually rerun this test -- along with dozens or hundreds of additional regression tests -- each time your developers modified the application, you would quickly run out of time between builds. Are you ready to record an automated script that can test the same functionality in a fraction of the time? Then let's do it!

Record your first script

To create an automated script, all you need to do is put Functional Tester in record mode while you repeat the same steps you walked through previously. The only difference will be that you will insert a couple verification points as you go along.

  1. Click Record a Functional Test Script on the Functional Tester toolbar. It looks like a red circle.

    You will be prompted to give the script you are about to record a name. Name it Buy100SharesCasey. (Note that script names are in fact Java class names in Functional Tester. Thus, they must conform to Java class naming rules. If you attempt to violate these rules, a warning message will pop up near the top of the window.)

  2. Click Finish.
  3. Functional Tester minimizes itself and begins recording any object interactions you perform. Remember this! Anything you do now will be recorded into your script. It is easy enough to edit any extraneous interactions out of the script, but for this first recording at least, try to avoid any distractions.

    Functional Tester presents you with a small Recording toolbar. There are many tools and utilities available here that you might want to use during the recording process: for instance, you can pause recording, insert comments and calls to other scripts, and insert verification points. This tutorial will not cover all the utilities. Just be aware there are many things you can do through wizards and windows during recording without writing any script code.

  4. The first thing you want to do during recording is to start the terminal emulator and connect to our simulated mainframe. To start the terminal emulator, click Start Application in the Recording toolbar.
  5. In the Application Name drop-down menu, choose Extension for Terminal Applications and click OK.
  6. Click in the Host field of the terminal emulator. Enter “localhost”, without the quotes.
  7. Use the Terminal type combo box to select TN3270E.
  8. Click in the Port field after the number 23. Press Backspace twice to erase the 23, then type 23 again. (This may seem strange right now, but the reason for this will become evident later.)
  9. Click Connect on the toolbar.
  10. Type cicsa and press Enter.
  11. Enter the user ID dnet256. Press the Tab key twice. Now enter secret as the password. Press the Enter key.
  12. Type RCTD and press Enter.
  13. Type jan, press the Tab key, then type janpwd as the password. Press the Enter key.
  14. At this point, it might be helpful to insert a comment into the script that is being recorded. Comments have no impact on the playback of the script, but can greatly improve its readability. Terminal-based scripts can sometimes be more difficult to read because so much of the interaction is done through the keyboard. Click the Insert Script Support Commands button on the Recording toolbar. Click the Comment tab and enter Company Selection Screen as the comment. This indicates what you are about to do in the script. Click Insert Code and then click Close in the Exit the Script Support Functions window.
  15. Press Alt-Tab to return focus to the terminal emulator. Type the number 1 to select Casey Import/Export and press Enter.
  16. Type 1 and press Enter to request a real-time quote.
  17. To verify that there are no shares held here on the Real-Time Quote screen, use a verification point on the red status information message. On the Recording toolbar, drag the Insert Verification Point or Action Command button over the red information text in the terminal emulator until the red box encircles only that text, then release the mouse button.
  18. You don't just want to verify the text of this message; you also want to verify its properties, such as the red color. On the window that appears, select Perform Properties Verification Point and click Next twice. You can verify any of the properties you see in the wizard. Note that many of these properties map directly to attribute bit settings on the 3270 field. You don't need to verify all these properties, just a few. Click the check boxes next to foreground, highIntensity, and text. Then click Finish.
  19. Back out to the main option menu by clicking the PF3 button along the bottom of the screen.
  20. Next, you want to buy 100 shares. Type 2 and press the Enter key.
  21. Type 100 and press Enter.
  22. Now you should insert a verification point on the status message to verify that the request was processed successfully. Drag the Insert Verification Point or Action Command button over the information text in the terminal emulator again. This time, keep the default Perform Data Verification Point and click Next twice.
  23. This verification point type only verifies the data in an object. You can see there will be a problem, however: each time you play this script, the request number will be different. You can't just compare against static text. Regular expressions come to the rescue! Regular expressions are a pattern-matching language that can be used in your verification points to make them capable of handling dynamic data such as this request ID. Click Convert Value to Regular Expression in the wizard. Now replace the five-digit number in the data with the following string:

    This expression says that you want to look for a sequence that is five characters long, and that the characters in that sequence should only be digits. Your data should look like this:

  24. Click Finish to complete the verification point.
  25. Press Alt-Tab to return to the terminal emulator. Type 1 and press Enter to get a new quote.
  26. You want to insert one last verification point. This will be a data verification point on the number of shares held. Drag the Insert Verification Point or Action Command button over the shares value, 0100.
  27. Click Next twice, then Finish to complete the verification point.
  28. Click Disconnect to disconnect from the simulated host and close the terminal emulator.
  29. Click Stop Recording on the Recording toolbar.

Okay, let's review what you just did. Simply put, you had Functional Tester record everything you did while you performed a test manually on your application. You performed a few extra steps to tell Functional Tester what was important to verify. Now you have a test that can be run again and again to do the same thing you did manually. In the next section, you will investigate what Functional Tester did behind the scenes to capture this test.

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:


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


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


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

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

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

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:

    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:

  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 Related topics for a link). This tutorial leads you through the process of setting up a data-driven test against a Java application.


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.

Run your test

Ready the script for version 2

In Navigate the application under test, you erased and retyped the port number. It's time now to make a slight edit to the script to cause it to use a different port so that it plays back against the second version of the application.

  1. In the Test Script view -- the center pane of the Functional Tester window -- locate the line that edits the port number:
  2. Edit the line to type the number 24. Your line should now look like this:

Before you play back the script, check a couple of things:

  • Verify that there are no terminal emulators open. Your script will open a terminal emulator session and you don't want it to get confused if multiple emulators are open.
  • Verify that the Host Simulator is running. You can verify this by verifying the two Java applications are visible on your Windows launch bar.

Play back the script

To play back the script, click Run Functional Test ScriptRun Functional Test Script button

You will be prompted for the name of a log in which to store the results of the test. Functional Tester will use the name of the script as the default name for the test log. Click Finish to accept the default.

Now you can sit back and watch as Functional Tester repeats your test steps against the newer version of your application. Do not attempt to use the mouse or keyboard until Functional Tester finishes playback of the script.

Examine the test log

When Functional Tester finishes, you should be presented with an HTML log of the test results. Again, this is similar to the logs you've already seen if you've tested Java, Web, or .NET applications with Functional Tester. The log records major events, such as the script and application launch and termination, as well as the status of all verification points. If you had any script failures or warnings, those would be logged here as well.

The left navigator frame gives you quick access to the most important parts of the log. You should note that there is one failure. One of your verification points has failed. Click [Field_16_63_text] failed in the Failures area of the left navigator frame. This will cause the log to scroll to the appropriate failure entry. To get more detail on this failure, click the View Results link. This brings up the Verification Point Comparator.

The Verification Point Comparator highlights in red the differences between the expected value and the actual results. Here you see that, although we clearly purchased 100 shares, the final real-time quote screen shows only 10 shares held in the account. Mission accomplished! Your simple regression test has exposed a regression in the application. This functionality worked in version 1, but fails in version 2. It's time to file a defect report.

Wrap up


So what did you accomplish in this tutorial?

  • You recorded an automated test for your terminal-based application in Functional Tester simply by recording yourself executing a manual test.
  • You used wizards during recording to insert a few commands to verify on-screen data.
  • You made those verification points flexible enough to deal with dynamic data returned by the application.
  • You replaced literal data in your script with references to data in a new datapool you created, thereby increasing your return on investment by reusing a single script to run multiple data sets.
  • You exposed a defect in a new build of your application by simply playing the test you recorded.

You've really just begun. There are many, many more capabilities in Rational Functional Tester and the Rational Functional Tester Extension for Terminal-Based Applications that we didn't have time to cover in this tutorial. You are now ready to explore these capabilities on your own terminal-based application.


Once you have completed this tutorial, you have no more need for the Host Simulator you installed earlier. Close the two Java Host Simulator windows then delete the entire HostSim folder you installed earlier.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Test terminal-based applications with Rational Functional Tester