Architecture of Rational Functional Tester

This section introduces the general architecture of Rational Functional Tester, which is described in detail throughout the rest of the book. You can think of Rational Functional Tester as having three different modes of operation: normal edit mode, recording mode, and playback mode. Most of the time, you will work in edit mode. Recording and playback modes are significant because they are not passive about what you do with the keyboard and mouse of your computer.

How Test Assets Are Stored

Rational Functional Tester is a desktop file-based tool and does not have a server component. All Rational Functional Tester information is stored in files, primarily Java™ and XML, which users typically access from shared folders. You can use a configuration management tool such as Rational Team Concert, IBM® Rational ClearCase®, or simpler tools such as PVS to version control individual test assets. There is no database component, although it is possible to get test data directly from a database table. This is less common, however, and you will typically keep test data in files along with the other test assets.

If you use Rational Functional Tester Java scripting, your Functional Test project is a special kind of Java project in Eclipse™. If you use Rational Functional Tester Visual Basic®.NET scripting, your Functional Test project is a special kind of Visual Basic project in Microsoft® Visual Studio®. Both kinds of projects are created through Rational Functional Tester.

You can become highly proficient with Rational Functional Tester, even an expert user, without needing to concern yourself with most of the underlying files created by the tool. All of the test assets that you work with are created, edited, and maintained through the Rational Functional Tester interfaces. Most of the test assets, such as a test script, consist of different underlying files on the file system. The exact file structure for the Java scripting and Visual Basic .NET scripting versions are almost exactly the same with only minor differences.

How Test Results are Stored

Test results are stored in test logs, which can be stored in several different formats of your choice. You can choose how to save test logs based on the nature of the particular testing effort and what you use for test management. For example, a small informal testing effort might simply save all test results into HTML files. Another larger testing effort might send the test results to a test management tool, such as IBM Rational Quality Manager. Following are the options for storing test logs in Rational Functional Tester:
  • HTML
  • Text
  • Test and Performance Tools Platform (TPTP)
  • XML
  • Rational Quality Manager
IBM Rational Quality Manager is not required for test logging or for any other functions or uses described in this book. This is presented only as an optional tool for test management, which is often employed in testing efforts.

How Tests Are Recorded

You are likely to use the recorder in Rational Functional Tester to create new test scripts. The reason for this is that the recorder is usually the fastest and easiest way to generate lines of test script, even if that script is extensively modified later. Whether you capture long linear test procedures, developing a keyword-driven test framework, or do something in between, the recording mode is the same. When Rational Functional Tester goes into recording mode, it captures all keyboard and mouse input that goes to all enabled applications and environments. Every time you press a key or perform anything with a mouse, other than simply moving the pointer, it gets captured into the test recording. The exceptions to this are: Rational Functional Tester does not record itself and it does not record applications that are not enabled. You must be careful when you are recording and be sure that you do not click or type anything that you do not want to be part of your test.

Rational Functional Tester creates the test script as it is recording; there are no intermediate files or steps to generate the test script, and you can view the steps as you record. Some information about the test is stored in files that are different from the test script; this includes test objects, verification points, and test data. These files are hidden, and you see abstractions of them only as test assets in the test script.

The test scripts are either Java or Visual Basic .NET files, which must be executed through Rational Functional Tester. These are not just any Java or Visual Basic .NET files, however. They are extensions of the com.rational.test.ft.script package and include several other packages for functional testing, which is what makes them automated tests. Using the recorder or creating a new blank test from within Rational Functional Tester automatically sets up the required packages so you do not have to manually do this.

Although there are many techniques for recording tests, you always capture steps that interact with an application or system interface. Unlike many unit testing or developer testing tools, there is nothing that automatically generates tests by “pointing” to a class, interface, or package.

How Tests Are Executed

When you run a test in Rational Functional Tester, the machine goes into playback mode. In playback mode, Rational Functional Tester sends all of the mouse and keyboard actions that you recorded to the application under test. While Rational Functional Tester is “driving” the computer, it does not lock the user out from also using the mouse and keyboard. In general, you should not touch the keyboard or mouse when Rational Functional Tester is in playback mode. However, at times you can run tests in interactive mode to manipulate potential playback issues.

A test script is comprised largely of statements that interact, including performing tests, with various objects in the application under test. When you execute a test script, Rational Functional Tester first has to identify and find each object by matching recognition properties in the script’s saved test object map against the actual objects that are present at runtime. If Rational Functional Tester cannot find a close enough match, it logs an error and either attempts to continue or aborts. If Rational Functional Tester does find a matching object, it performs the action on the object. These actions might be user interactions, such as clicking, selections, or other operations such as getting or setting values. Finally, the actions performed on the object might be a test (a verification point), in which case Rational Functional Tester compares some saved expected value or range with an actual runtime result. Although every statement (line of code) in the script produces a result, you normally see only verification points (the tests) and other key results in the test log that are created for every test run.

You can either play a test back on the same machine or on any other machine running a Rational Agent, which gets installed by default with Rational Functional Tester. You can also run multiple tests on multiple remote machines for distributed functional testing. This makes it possible to complete much more testing in a shorter period of time. A given machine can run only one test at a time, or many sequentially, but you cannot run multiple tests in parallel on the same machine. Although it is not required, you can also execute Rational Functional Tester tests on remote machines using test management tools, such as Rational Quality Manager.

Integrations with Other Applications

Rational Functional Tester is a stand alone product that does not require other tools or applications. Integration with other tools or applications is optional and based on your particular needs. Following are some of the common types of applications that you can integrate with Rational Functional Tester:
  • Test management or quality management, such as IBM Rational Quality Manager
  • Defect tracking or change request management, such as IBM Rational ClearQuest
  • Configuration management or version control, such as IBM Rational Team Concert and IBM Rational ClearCase
  • Unit or developer testing tools, such as JUnit
  • Automated testing tools, such as IBM Rational Performance Tester
  • Development tools, such as IBM Rational Application Developer
Most of the applications listed previously, especially those developed by IBM, require little or no work to set up the integration. Many applications and tools, such as JUnit, Rational Service Tester, Rational Software Architect, or WebSphere® Integration Developer (to name a few) run in the Eclipse shell and can share the same interface as Rational Functional Tester. With these tools, you can switch between Rational Functional Tester and the other tools simply by switching perspectives (tabs).

In addition to these applications, you can also integrate Rational Functional Tester with many other kinds of applications. This requires varying amounts of work to implement the integration, although you can find existing examples on IBM developerWorks® (\developerworks\rational\). These include:
  • Custom-built test harnesses (extending the test execution)
  • Spreadsheets (for logging or simple test management)
  • Email notifications