Professional Documents
Culture Documents
RFT Imp Quesions-Answer
RFT Imp Quesions-Answer
1) Recording of Test Scripts: is done on the fly, as users navigate the application.
Verification points can be inserted to validate the system response. This makes test
scripts data-driven to enable execution of the same script on variety of data inputs.
3) Playing Back the Scripts: Executing the scripts on the application under test to
emulate all actions as already performed by the user during recording. Logging of
the discrepancies and drawing conclusion as to whether application functioned as
desired or some regression issues need to be addressed.
1) Functional Tester- Java Scripting uses the Java language and the IBM Rational
Software Development Platform.
2) Functional Tester - VB.NET Scripting uses the VB.NET language and the Microsoft
Visual Studio .NET development environment.
2) Recording and playing back of scripts navigating through the application and test
the state of objects through verification points.
3) Testing any object in the application, including the object's properties and its
data.
Test object map gets created automatically while recording the script for the
application-under-test. It provides a quick way to add objects to a script.
It lists out the test objects available in the application, whether they are currently
displayed or not.
We can create a new test object map, either by basing it on an existing map or by
adding objects as required.
It contains recognition properties for every object, hence we can update the
recognition information in one central location. Thus any scripts using this test object
map shall be able to share the updated information.
Test object maps created for HTML applications are generally more hierarchical than
those created for Java applications. The top level of the test object map is a browser
and the HTML application is inside the browser.
Verification points can be inserted in the script during the recording to confirm the
state of an object in the application.
The verification point captures the object information based upon the type of the
verification point and stores it in a baseline data file. The information in this base file
becomes the baseline of the expected state of the object during subsequent builds.
Q. 8: How the RFT playback depends upon the platform and the browser?
The test playback in RFT is independent of the platform as well as independent of the
browser. For example, we can record a script on Windows and play it back on Linux.
Since the script contains no references to the browser during the recording, we can
play back the script using any of the supported versions of Firefox, Mozilla, Internet
Explorer or Netscape.
Rational Functional Tester runs on the following Host and Test platforms.
1) Windows XP Professional
1) Parent-child nesting: This takes place when one object is contained within
another, like a button on a form.
2) Owner-owned nesting: This takes place when the owned object has its own
top-level window, like as a dialog box that is owned by a top-level window.
We can test the applications using RFT (Java Scripting) on Linux in following two
ways:
1) We can record a script on Windows and export it to Linux & then play it back on
Linux.
2) We can write our own scripts, by using the Test Object Insert tool. Instead of
creating an object map through recording, we populate it outside of the recorder by
opening the map and selecting objects in the test application.
Limitations of RFT on Linux is that it does not support recording. But we can insert
verification points without recording, by opening the Verification Point wizard from
the Script Explorer.
RFT comes integrated with the two types of Test managers like:
1) TestManager: Includes the TestManager Log, running Windows and Linux remote
playback agents, and test management features like running scripts as part of a test
suite. RFT has its own logs and does not depend on the TestManager log integration.
A Rational Test project is used to store test assets like test plans, test cases, test
logs, reports, and builds.
A Functional Test project stores application test assets like scripts, object maps,
verification point baseline files, and script templates. We need to create a Functional
Test project before recording the scripts.
After creating a Functional Test project, we can use the project stand-alone, or
optionally associate it with the current Rational project to take advantage of the
Functional Tester integration features with TestManager.
1) Creating and playingback the scripts, including Functional Tester scripts, from
Rational TestManager.
2) Using the TestManager Agent for playing back the scripts on a remote computer.
Q. 16: What are the benefits of associating a Functional Tester project with
current Rational Project?
Following are the benefits of associating a Functional Tester project with the current
Rational project:
2) Record and play back all Functional Tester scripts from Rational TestManager.
3) Playing back a Functional Tester script on different computers using Rational Test
Agents set up through TestManager.
4) Management of logs, including Functional Tester logs, using the Test Log window
of TestManager.
When we intend to use Rational TestManager for managing our tests, we need to
associate the Functional Test project with a Rational project.
First of all we need to create a Rational project before we can associate a Functional
Test project with a Rational project so that TestManager can gain access to the
Functional Test project. When we create a Functional Test project, we can associate
it with an existing Rational project at that time.
Remember that we can associate a Functional Test project with a Rational project if
it is currently
not associated with any other project only. To associate a project with a different
project, first of all we need to disassociate the project from the project to which it is
currently associated.
Following restrictions are imposed when we disassociate a project from the current
Rational project:
1) We cannot play back Functional Tester scripts, or test cases or suites that include
Functional Tester scripts in the disassociated project from TestManager.
2) TestManager deletes the test script source from the disassociated project.
3) We cannot undo this operation. If we associate the Functional Test project with a
Rational project again, TestManager creates a new test script source.
Q. 19: How many buttons are available in Functional Tester Projects view
banner?
2) Refresh Projects: This button enables us to repaint the display to reflect changes.
3) Synchronize with Editor: This button scrolls in the tree hierarchy to the name of
the script currently displayed in the Java Editor.
We can export project items like scripts, test object maps, Java files or Visual Basic
files, and datapools to another Functional Tester project.
When we export a script, Functional Tester includes all necessary files, like shared
test object maps, even though it was not selected by us.
Q. 21: What type of file extensions are created while exporting Functional
Test project items?
Functional Tester compresses a copy of the files into a data transfer file with the
name specified by us.
We can import project items like scripts, test object maps, Java files or Visual Basic
files, and datapools into a Functional Tester project.
Functional Tester adds all the project items from the data transfer file into the
project specified by us.
To view and work with items in the data transfer file, we can use any file
compression program which support the .zip format. We do not have to extract files
in the .rftjdtr or .rftvdtr file before importing.
First of all we need to configure our test environments, configure the applications,
and create a project.
During recording a script, Functional Tester records any user actions against our
application, like keystrokes and mouse clicks.
We can insert any features in our script, like a call script command, log entry, timer,
script delay command, or comment by clicking the Insert Script Support Commands
button.
The script and object map are stored in the project directory.
All Functional Tester scripts use a default helper superclass. These scripts extend the
RationalTestScript class, and thereby inherit a number of methods like callScript.
Advanced users can create their own helper superclass if they want to add additional
methods or override the methods within RationalTestScript.
1) One method deletes all cookies for the current profile or user.
2) Second method deletes cookies in a specific page or domain for the current profile
or user.
cookie - The full path of the cookie. This is usually the domain followed by the
directory path in which the intended document resides, for example, http://a.com.
recursive - If set, all cookies that are children of the path specified in cookie
are deleted, for example, a.com/b/.
void deleteCookies()
Deletes all of the browser's cookies for the current profile/user.
A test project is the location where Functional Tester keeps all of the scripts, along
with expected and actual results.
The format of the test project is governed by the environment being used by us i.e.
either Eclipse for Java scripting or Visual Studio.NET for Visual Basic.NET scripting.
If we are using the Java language, we create a Java test project. However If we are
using Visual Basic.NET, we create a .NET test project.
When recording tests, the application can be started by using a startApp command.
This makes playing back the tests more reliable because startApp uses the
application configuration information.
Functional Tester will open either Java applications that we specify or HTML pages in
our browser, or run applications in executable form.
When we don't want to do recording, we can create a script to enter Java code
manually.
In the new script, RFT includes import statements for files we need to compile the
script and comments containing archiving information.
RFT uses the script name as the class name and sets up testMain, where you can
add the commands to include in the script.
We can do the recording in an existing RFT script by bringing our cursor to the
desired location & just start the recording.
In this process we can start the application, insert verification points, and add all
script support functions.
For testing HTML applications on a particular browser scripts are recorded in a usual
way using following two steps:
1) Enabling the Web browser: Before being able to use the particular Web browser
(like any of the supported versions of Firefox, Netscape, Internet Explorer, or
Mozilla) to test with RFT, firstly we need to enable it.
Test Object Inspector is used to get a display of the test object information in the
running application. This information can be about objects like parent hierarchy,
inheritance hierarchy, test object properties, non value properties, and method
information.
The Test Object Inspector does not display the information for the test object under
the cursor. Secondly the Test Object Inspector does not capture the objects in the
application If it is not active.
Test Object Inspector automatically tracks the cursor and performs live updates
immediately after the application is opened.
Q. 32: What is the purpose of wait state feature for the objects during
playback?
This feature is used to set a wait state for an object during playback to check for its
existence. Maximum Wait Time is the maximum number of seconds RFT is made to
wait for the object to appear in the application during playback.
This feature is useful when waiting for an object immediately after starting the
application, or after other actions taking a long time.
To set a wait state for an object, we can either use the defaults, or we can set our
own waiting time value.
Q. 33: What happens to the related files when we rename a test aset?
We can easily rename a RFT script, test object map or other files in a project, with
following consequences:
1) When we rename a script, RFT renames all its related files, like the helper script
files, the private object map, and any verification point files.
2) When we rename a test object map, RFT updates associated scripts with the new
name.
However after any renaming operation, we need to change any callScript commands
in scripts which reference the old script name; otherwise, RFT shall logs an error
when while running these scripts.
Q. 35: What is the reason of Record Monitor going blank when recording
against a Java or HTML application?
The Record Monitor turns blank while recording against a Java or HTML application
when JREs or browsers are not enabled. Hence it is essential to enable the JREs for
Java testing and browsers for HTML testing.
Due to this reason, it is suggested to leave the Record Monitor in view while
recording. Thus if this problem comes we need to run the enablers.
Hover feature is useful to move the mouse to a particular place during playback in an
HTML application. It is useful for clicking on menus or links in HTML testing.
To use this feature, move the mouse pointer over the object for which we want to
record a hover. Press and then release the Shift key to record the hover. This will
cause the recorder to insert a hover() method in the script. At playback, the mouse
will then be able to activate links and menus by hovering on them, instead of
clicking.
Datapool is an external file which drives the Data-driven testing. Datapool provides
inputs to the test.
Data-driven testing uses data from an external file, known as a datapool. We can
add data to the datapool after finishing the recording of the test script.
Since our data is separated from the test script, we can easily perform the following
actions:
2) Addion of new test cases by modifying the data, without affecting the test script
1) Object Finder Tool method : Is used to select an object and all descendents of the
object. We can select one object, or select an object and the immediate children of
an object.
2) Test Object Browser method: Is used to browse for the object that we want to
select. The browser displays a hierarchical tree of objects in the application. The top
level shows any applications being run. Under each top level, RFT displays the object
hierarchy within that application.
There are two types of datapools like 1) Private datapool and 2) Shared datapool
Every test script that we create has a private test datapool associated with it. The
initial private test datapool is a placeholder and is empty until we data-drive the test
script, or add new data to it.
We can create data for a datapool right from the scratch or we can import existing
data into a new datapool from another RFT datapool or from a .csv file.
1) While importing data, we need to import the data into the same RFT project as
the test scripts that access the data.
We can easily replace literal values in an existing script with datapool references to
add realistic data to the script. We can find and replace all literal values, or just the
number, string, or Boolean literals with a datapool reference.
We can add a literal value from a script to a datapool. If we do not use an existing
datapool variable, the same literal values (the values that were captured when we
recorded the test script) are used each time we run the script.
1) The verification point accesses the data in the datapool creating the expected
result from the baseline and the active datapool record.
2) The datapool reference resolves and supplies data to the verification point.
4) Expected and actual results are recorded in the log. Any deviation from the
expected results are logged as a failure in the test log.
Q. 45: How many types of datapool record selection orders are available in
RFT?
Test datapool record selection order determines how a test script accesses the
records in the test script's associated datapool when we play back the test script.
1) Sequential record selection order: Is used to make a test script access records in
the datapool in the order that they appear in the datapool. It is the default datapool
record selection order.
2) Random record selection order: Is used to make a test script access records in the
datapool randomly. It accesses every record in the datapool once.
The state of both the environment and the application-under-test can affect script
playback. If the recorded environment and the playback environment are different,
playback problems can occur.
1) Ensure that the application-under-test is in the same state that it was in when we
recorded the script.
2) Ensure that any applications and windows that were open, displayed, or active
when we started recording the script must be open, displayed, or active when we
start playback.
3) Ensure to restore any relevant network settings, active databases, and system
memory to the same state as when the script was recorded.
When we run a script from RFT, it plays back all our recorded actions, like starting an
application, the actions we perform in the application, verification points, and
stopping the application.
The Playback Monitor starts and provides information as the script plays back. After
the script runs, a log file gets displayed.
When we run a script, TestManager creates a temporary suite, runs the suite, and
removes the suite after the run is completed.
We can run a script either from the TestManager Test Scripts window or from the
TestManager File menu.
Q. 49: Out of Test case or test script, which one should be run to generate
test case results?
To generate test case results, we should run the test case instead of the script.
When we run a script, the TestManager does not generate test case coverage results
- even if the script is associated with a test case.
We can use the same process to debug a RFT script as we would use to debug other
Visual Basic or Java applications.
In Functional Tester- Java Scripting; scripts are recorded in the Java programming
language. Debugging these scripts is the same process as debugging a conventional
Java application.
In Functional Tester - VB.NET Scripting; scripts are recorded in the Visual Basic
programming language. Debugging these scripts is the same process as debugging a
conventional Visual Basic application.
When we play back a script, RFT replays all the recorded actions, which automates
the software testing cycle.
Such automation allows us to test each new build of our application faster and more
thoroughly compared to manual testing, thereby reducing the testing time and
increasing the coverage and overall consistency.
1) Test Development Phase: Here we play back scripts to verify that they work as
intended, using the same version of the application-under-test that we used to
record. This phase validates the expected behavior for the application.
2) Regression Testing Phase: Here we play back scripts to compare the latest
build of the application to the baseline established during the test development
phase. Regression testing identifies differences that may have been introduced since
the last build. We can evaluate these differences to determine whether they are
defects or changes.
Q. 53: What are the steps involved in test development phase using RFT?
2) Play back each script against the same version of the application-under-test that
was used for recording to verify that the script performs as intended.
3) Analyze the results in the RFT log. If we associate a Functional Tester project with
the current Rational project, we can analyze the results using the Test Log window of
TestManager.
4) Use the Functional Tester Verification Point Comparator to determine the cause of
verification point failures.
Q. 54: What are the steps involved in regression testing phase using RFT?
2) Play back the test script against a new build of the application-under-test.
4) Use the Functional Tester Verification Point Comparator to determine the cause of
verification point failures. If verification points fail because of intentional changes to
the application-under-test, update the baseline data using the Comparator.
5) If necessary, revise your test scripts to use new features in the application under
test. Then play back the revised test scripts against the current build and reevaluate
the results.
When we do the playback of our script, we can view the script name, the number of
the line that is executing, status icons, and a description of the action in progress
from the Playback Monitor.
1) Script name
3) Status icons
When we associate a Functional Tester project with a Rational project, we can use
TestManager to run the Functional Tester scripts on computers that are designated
as Agent computers from a single Windows computer, called the Local computer.
Q. 57: What are the actions performed by the agent computers while using
RFT?
Q. 58: What are the actions required to run a RFT script from TestManager?
3) On a remote computer, we need to install the Rational Test Agent software on the
Agent computer and start the agent.
4) If we need an external library to run a script, for example a .jar or .dll file, we
need to install the software on the system on which we plan to run the script.
5) To install a .dll, add the library to a directory that is in system search paths.
With the help of ScriptAssure feature we can play back the scripts successfully even
when the application under test has been updated.
For RFT to recognize an object in the application under test, the object properties
must match the properties recorded in the test object map. By default, RFT can find
the object if one or two properties do not match. If two properties do not match, RFT
writes a weak recognition warning to the log. If more than three properties do not
match, RFT cannot find the object in the application.
Thus even if some objects in the application under test have changed, we can still
play back scripts in RFT by using the ScriptAssure feature to control object-matching
sensitivity.
RFT uses a criteria to assign a recognition score to objects in the application under
test. For example, if the object exactly matches the recognition properties in the test
object map, its score is 0. If the object has one property with a weight of 100 that
does not match, its score is 10,000. If the object has two properties that do not
match, its score is 20,000, and so on. The higher the recognition score, the less
exact the match.
We can enter our own values to set thresholds for recognition scores, such as the
maximum acceptable recognition score, last chance recognition score, ambiguous
recognition scores difference threshold, and warn if accepted score is greater than
some predefined value.
During the playback, the recognition scores for a test object's recognition properties
get added and the total is compared with the thresholds set in the ScriptAssure
Page.
1) Whenever we want the script to play back faster and with fewer warnings, set the
thresholds high. The recognition is less fussy but more prone to error.
2) If recognition is weak, examine the test object map. If the application has
changed permanently, update the test object map to reflect the change. In an
internationalization situation, change the label of the test object, not its accessible
name.
3) If the application has a dynamic object or if several versions of the application are
slightly different, correct versions of an object, replace the recognition property with
a regular expression. We can also use a numeric range to accept more than one
value of a property.
4) If it is late in the development cycle and we are doing maintenance, verify that
the scripts work and have the best possible recognition by setting the warning level
to High. We will receive warnings about possible problem areas, and if we do, fix the
map.
Q. 63: How does ambiguous object recognition takes place during testing by
RFT?
Ambiguous recognition occurs when RFT can not uniquely identify an object in the
system-under-test. This commonly happens when RFT cannot differentiate between
an instance of the application under test started by a script playback and an instance
of the same application inadvertently left open previous to script playback.
Ambiguous recognition will cause script playback failure unless the duplicate
application is closed.
Thus if RFT finds more than one instance of the application under test during the
playback of a script the Ambiguous Recognition window will open allowing you to
close the duplicate instance and resume playback.
Ambiguous recognition takes place when residual windows are left open from a
previous playback of a test script.
1) Close the last action recorded in the test script in the application under test.
2) If script playback fails, close all windows opened by script playback before
replaying the script.
2) Find and close the duplicate application instance using the information in the
Ambiguous Recognition window.
Q. 66: How can we view the results after the playback of script in RFT?
After playback of script finishes, we can view the results in the log.
These results include all logged events, like verification point failures, script
exceptions, object recognition warnings, and any additional playback information.
We can view The RFT logs in Functional Tester or in the Test Log window of
TestManager, by setting the logging preferences.
Q. 67: What are the types of logs available to view the script playback
results in RFT?
Following types of RFT logs are available to view the playback results of our scripts.
All these logs contain the same information but in following different formats:
1) Text Format: Displays a log in ASCII format in the Functional Tester script
window.
3) TestManager Logs: Displays RFT log information in the Test Log window of
TestManager. We need to associate a Functional Tester project with the current
Rational project to display and manage logs in TestManager.
4) TPTP: Displays a log using TPTP in the Functional Tester script window.
Logging page is used in RFT to set log and comparator options, like preventing the
script launch wizard from displaying on playback, displaying the log viewer after
playback, and displaying a message before overwriting an existing log.
Logging page is helpful to indicate the type of log generated after the script
playback.
1) Don't show script launch wizard option: Prevents the script launch wizard from
displaying each time we play back a script.
2) Display log viewer after script playback option: When selected, displays the log
after we play back a script. If the log type is TestManager, the Test Log window of
TestManager displays the log. If the log type is HTML, the log opens in the default
browser. If Text, the log opens in the Script Window of RFT.
4) Log a screen snapshot when playback fails option: When selected, takes a screen
snapshot at the time of the failure and stores it in the log. Clear checkbox to save
storage space (172 KB per snapshot). This option is not supported in TestManager
log type.
3) Opening the script, which generates a log event in the appropriate script
development tool? For example, if we create a RFT script and run it from
TestManager, when we click a log event, RFT opens the script.
5) Submitting a defect for a failed test case or for a failed log event. The log fills in
build, configuration, and script information in the Rational ClearQuest defect form.
6) Previewing or printing of data displayed in the active log in the Test Log window.
Test object map describes the test objects in the application under test. It is a static
view which describes test objects known to RFT in the application under test.
The test object map contains objects from multiple applications. It provides a quick
way to add test objects to a script. Because the test object map contains recognition
properties for each object, we can update the information in one location. Any scripts
which reference that test object map share the updated information.
When we record a script, RFT creates a test object map (or uses an existing shared
map) for the application under test. Each script is associated with a test object map
file. The map file can be private, associated with only the script (*.rftxmap), or
shared between scripts (*.rftmap). We can merge multiple private or shared test
object maps into a single shared test object map.
Q. 72: Can we merge multiple object maps into a single map in RFT?
We can use the "Merge Test Objects into" feature of RFt in its Test Object Map page
to merge multiple private or shared test object maps into a single map.
Q. 73: What functions are available while using shared object maps in RFT?
Following four functions are available while using shared object maps
1) Checking out: When we check out a script which references a shared test object
map, the map is checked out with the script.
2) Recording: When recording a script which uses a shared test object map, RFT
checks out the shared map. If we record two scripts that share a test object map,
check in one of the scripts, and record into the second script, RFT checks out the
shared map.
3) Checking in: When we check in a script which references a shared test object
map, RFT merges and checks in the shared map before merging and checking in the
remainder of the script. When we cancel a checkin that requires a shared or a private
test object map merge, RFT behaves differently at various stages of the procedure.
Q. 74: Which files don't get merged while merging branches of scripts?
3) Test datapool files. The last datapool file we check in overrides the previous
datapool file checked in by us.
Hence we should not check in any of the script files until all files are merged.
We can use the test object map to include an object in one or more scripts.
As part of the procedure, RFT displays a list of possible methods for the object and
we can choose the one we want to use for the test object.
We can feed the descriptive text about an object which RFT adds to the
Administrative property set tab for the object. RFT displays the description when we
place the cursor over the object name in a script.
RFT stores the description in the helper class. The description is not inserted until the
helper class file is regenerated, which occurs when we record, playback, or update
recognition properties.
If an object in the application under test changes, a test object map may have two
map objects describing the same object. We can combine these objects into a single
map object. When we unify the two objects, RFT updates the scripts.
We can modify recognition information for an outdated object by including the new,
similar object in the test object map. After we add the newer object to the test
object map, we can combine the outdated object or the source object with the newer
object i.e. the target object and unify their test object properties.
1) RFT script: When we rename a script, RFT renames all its related files, like the
helper script files, the private object map, and any verification point files.
2) Test object map: When we rename a test object map, RFT updates associated
scripts with the new name.
Hence care needs to be taken while changing all callScript commands in scripts
which reference the old script name; otherwise, RFT will log an error when these
scripts shall be run.
Q. 79: What can be the possible reasons of error indicating that RFT could
not find the object?
RFT can not find an object and displays an error message, due to the
following reasons:
4) The recognition properties for the test object may no longer reflect the test object
in the application.
Q. 80: What are the ways to search objects in a test object map?
We can search the test objects in a test object map, by using a property or a value.
We can search the test objects in a test object map in following two ways. RFT
searches the test object map for objects which match the search criterion and
highlights the first occurrence.
1) Quick Find method: Enables us to search for a test object based on the property
or value that we enter.
2) Find by Filters method: Enables us to create and save find criteria to search for a
test object.
The pattern allows for more flexibility in the object recognition. We can convert
properties to regular expressions and numeric ranges from within the Verification
Point Editor or the object map.
We can undo any regular expression or numeric range.
1) Pattern: This field contains the current value when we convert to a regular
expression. This field is used to edit the expression.
2) Perform Case Sensitive Match: This check box controls case sensitivity. It is
set to "on" by default, and matching is case-sensitive.
3) Match Against Value: This field contains the current value when we convert to a
regular expression. The pattern we edit must match this expression because it
reflects the property value in the application.
4) Result: When we click Evaluate, this field contains the result. If the patterns
matches, we see MATCH in green letters. If the pattern does not match, we see NOT
A MATCH in red letters. If we use an illegal character in the pattern, this field
indicates an exception.
5) Matching String: If the pattern matches, we see the matching string. If we use
an illegal character in the pattern, this field gives you the error. For example,
"Missing close paren" indicates that you have an open parentheses but not a closing
parentheses in the regular expression.
6) Evaluation Button: Edit the value in the Pattern field, and click this button to
test it. Click OK to save the expression when satisfied with it.
7) Examples Button: Used for examples of regular expression syntax and use
cases.
SCM systems are commonly used in software development groups in which several
developers are concurrently working on a common set of files.
If two developers change the same file, that file might be overwritten and critical
code changes lost. Software configuration management systems are designed to
avoid this inherent problem with sharing files in a multiuser environment.
All SCM systems create a central repository to facilitate file sharing. Each file to be
shared must be added to the central repository to create the first version of the file.
After a file is part of the central repository, users can access and update it, creating
new versions.
A checkout operation creates a local copy of the file in which you can make changes.
When user gets satisfied with the work, he checks in the file to create a new version.
The original file version always exists.
In a multiuser environment many users can check out the same file at the same
time. Thus the special "Merge" feature of the software configuration management
system becomes helpful.
The first user to check in the file creates the new version. The second user to check
in the file must merge her changes into that version. If the SCM system can combine
the changes, they are merged into a new version of the file. If the changes conflict or
cannot be resolved by the software configuration management system, the conflicts
must be resolved manually.
Test automation is a software development effort. Every time a test script is created,
whether through recording or coding, a file is generated which contains the code.
This code becomes a valuable test asset when created, developed or edited.
A team environment presents the risk of losing functioning code or breaking test
scripts by overwriting files. A software configuration management system offers a
way to overcome this risk. Every time a file changes, a new version is created and
the original file is preserved.
RFT comes seamlessly integrated with ClearCase a source control management tool,
for versioning of RFT's test assets.
ClearCase integration is specialized for RFT, hence some of its operations cannot be
performed outside RFT.
If someone tries to perform file operations on RFT files outside the RFT user
interface, scripts can become out of sync with their related files and become corrupt
or unusable.
While using ClearCase, we need to create the RFT project in a ClearCase snapshot or
dynamic view to share a project.
We can add the project to ClearCase after we create a project, as long as we create
the project in a ClearCase view. To share a project move the project to a ClearCase
view and then add the project to source control.
ClearCase allows us to share projects, scripts, script templates, test datapools, and
object maps across the testing team. We can manage following type of changes in
test assets stored in the RFT project and in software system development right from
requirements to release.
1) Check out a test script in RFT. ClearCase checks out the script and all supporting
RFT files if we check them out from RFT.
2) Edit a checked out copy of the script or any of the supporting files using RFT.
ClearCase stores the version permanently in the VOB and checks in all supporting
RFT files.
An element can be a RFT script, a RFT project, an object map, a test datapool, or a
Java file.
If we use ClearCase for source control of test assets in RFT, all elements shall get
stored with version history and comments in ClearCase. we can view the element
type, the element name, the date of the revisions, the first few characters of the
comment, the user who made the change, and the nature of the change for a test
script or other element in ClearCase.
<<<<<< =================== >>>>>>
While using the snapshot view we must ensure to get the latest files from the VOB
on a regular basis. Otherwise changes checked in by others can break the script.
Updating the files once a day may be adequate, depending on the needs of particular
team.
ClearCase integrated with RFT, copies the latest version of elements from the VOB to
the snapshot view.
Q. 91: What are the advantages of snapshot views over dynamic view?
The advantage of using a snapshot view with RFT is that, only the scripts that we
change gets compiled when we record or play back.
1) Files are not updated automatically. We need to always get the latest files from
the VOB on a regular basis. Otherwise the changes which others check in can break
the script.
2) A snapshot view uses a lot of disk space on the local hard disk drive because a
snapshot view copies every file in the Functional Test project to the local hard disk
drive.
1) Files do not take a large amount of disk space on the local machine because only
the files that we check out or create exist on the local hard disk drive.
2) Files in a dynamic view are always current with the VOB. We do not have to
remember to get the latest files from the VOB as we do in a snapshot view.
1) In a large team, when many users change scripts, it may take a long time for all
the changes to compile when we record or play back a script.
2) Functional Teste r- Java cripting, compiles the project when an element changes.
If we are using a dynamic view, automatic compilation can be time consuming,
depending on the size of the project.
MultiSite lets testers work on the same VOB concurrently at different locations. Each
location works on its own copy of the VOB, known as a replica.
Q. 95: How many type of element checkouts are there while using
ClearCase?
There are two kinds of checkouts for an element when we use ClearCase to manage
our RFT test assets:
1) Reserved checkouts: The view with a reserved checkout has the exclusive right
to check in a new version for a branch or stream. Only one reserved checkout is
allowed on each branch of the element.
When Rational ClearCase loads a file element into a snapshot view, it applies the file
system read-only attribute to the file.
If we change this attribute and modify a loaded file without checking it out,
ClearCase considers the file as hijacked.
Hijacking takes a file outside of direct ClearCase control. Although the update
operation detects whether we have hijacked a file, it is recommended that we should
not hijack files as a standard practice.
1) Script: Header of the file: Customizes the layout of new script files.
2) Script: Comment for Test Object: Customizes a test object comment line
inserted into a script by the recorder.
3) Script: Comment for top level Test Object: Customizes a top-level test object
comment line inserted into a script by the recorder.
4) Script: HTML Test Object Name: Customizes the names of HTML test objects in
a script.
5) Script: Java Test Object Name: Customizes the names of Java test objects in a
script.
9) Script Helper: Header of the file: Customizes the layout of a helper class when
auto generated.
10) Script Helper: Test Object Method: Customizes the layout of test object
methods in the helper class.
The object map property placeholders resolve object map placeholder values into
property values. They also resolve default placeholder values.
<<<<<< =================== >>>>>>
Script placeholders resolve script-level placeholder values into script values. As the
values are resolved, several lines of information can be cached, depending on the
placeholder.
VP placeholders resolve Test Object and verification point (VP) placeholder values
into property strings. Default placeholders values are also resolved.
Helper superclass or base class are optional, user defined classes which provide
overriding support for
Yes we can change the default script helper superclass for a Project as well as for an
individual script.
Yes. RFT allows us to create our own helper superclass which can be used by RFT
every time we create or record a script in our project.
Our own helper superclass can act as an extension for the RationalTestScript. We can
thus add additional methods and can even override the methods from
RationalTestScript.
Q. 104: What type of changes we can do in functional test scripts & how?
We can use application programming interface - API of RFT to make changes to the
RFT scripts.
Changes of following nature can be done in recorded scripts by using RFT's
API
RFT scripts can contain methods which can invoke another test scripts.
We can create a RFT script which serves as a command file for a suite of scripts. This
can be done by using the callScript method.
Under following situations we may need to change our script for accessing
an object property.
When we call many methods directly on the same object, and RFT loses time to find
the object each time a method was called on it. We use the TestObject.find method
to find an object without RFT calling any methods on the object.
Q. 108: What type of references for test objects can be unregistered in RFT?
RFT unregisters bound references only and that too when the entire playback ends
and not when the script ends.
As long as a bound reference to the object exists, RFT will prevent the object in the
application from being entirely free.
Q. 109: What should be the best practice to unregister the test object
references in RFT?
Q. 110: What type of verification points can we insert in our RFT script?
Two type of verification points i.e. Manual verification point & Dynamic verification
point can be added by us in our test scripts after recording.
These verification points help us to specify data for comparison against an object,
which is not found in the test object map.
Manual verification points are useful when we create the data for the verification
point ourself, and we want to compare the data. For example, the data could be the
result of a calculation or could come from an external source, like a database.
Manual verification point objects are constructed using the "vpManual" method.
When we call this method, we provide the data before "performTest" is executed.
Thus the user can avoid running of the test manually to the appropriate state before
recording the verification point.
Dynamic verification points are most useful when the TestObject is not mapped and
not something that RFT would normally test.
We can read the information out of the database of windows registry by using RFT
commands.
RFT provides following two commands to read values from the windows
registry.
1) "getRegistryValue" command : For reading the string values from the registry.
2) "getRegistryIntValue" command : For reading the integer values from the registry.
The terms "REG_SZ" describe the string and integer types. Both of the commands
take a type String argument, which contains the registry key to extract.
We can pass the data from one script to the other by using different signatures of
the "callScript" method.
2) TheCalled script :It receives the parameters and prints them to "System.out"
Few of the best practices for recording and playing back scripts to test HTML
applications are given below:
When recording a script in Netscape, pop-up message boxes like encryption notices
frequently appear. When recording a crossbrowser script, we do not want to include
these message boxes, because they usually do not appear in Internet Explorer.
2) Select any check box on the message that prevents the message from appearing
again.
4) Resume recording.
Alternatively we can modify our script as well to handle these message boxes,
When we want to test a lot of different URLs, the Applications list becomes very
lengthy. If we do not want to add a URL to the list, we can use the following
"startBrowser" command in an empty script to test it.
4) When the page is displayed, on the RFT toolbar, click Insert Recording into Active
Functional Tester Script and start recording against the page.
We can test our applications using RFT on Linux in following two ways:
1) We can record a script on Windows and export it to Linux. We can then play it
back on Linux.
2) We can write our own scripts, by using the "Test Object Insert tool". Instead of
creating an object map through recording, we can populate it outside of the recorder
by opening the map and selecting objects in the test application.
While installing the RFT package, we can install only the Functional Tester - Java
Scripting on Linux.
1) Rational "TestManager" main application does not run on Linux. But we can install
"TestManager Agent" on Linux and run RFT scripts in that agent.
For this we need to install the RFT agent software on the agent computer.
2) The integrations with Rational Robot and Rational Administrator do not work on
Linux.
Globalized applications are those in which all of the strings like messages, labels, and
text, are localized, that is, translated to the language of the location from which it
was started or launched.
"Globalized" also refers to applications that allow input and output of a non-English
character set.
1) Automated scripts recorded for a particular locale fails when played back in a
different locale. This happens because the object definition used for playing back the
automation script (for instance, the label of the button on which the automation
script has to operate) may be different from an English to a Japanese locale.
3) Data-driven test scripts do not pick and populate the data set, depending on the
location from which the application under test was launched. This happens because
there is no implicit intelligence built into the automation script to help determine the
language.
1) "Appobject" classes which logically group GUI elements together. These classes
consist of discrete, granular private object maps that contain a small number of
related GUI elements, along with routines that provide access to these elements.
2) Tasks or methods, which execute commonly - traveled paths through the GUI.
3) Test cases that invoke the tasks, verify the state of the application, and log the
results.
a) Appobjects Folder
b) Tasks Folder
c) Testcases Folder
Within verification point data, we can specify what we want to test. For example, For
an object we can have verification point on its properties or for a menu we can have
verification point for data in the menu.
RFT uses an object called the "RootTestObject" to represent a global view of the
software under test.
1) If we want to search the entire application, we use the find method on the
RootTestObject.
2) If we want to search a specific object, then use find on that TestObject. Searching
a specific "TestObject" will search only the children of that TestObject
Before understanding how to effectively use the RFT as an automation tool, we must
have fair understanding of the following:
3) Verification points
4) Low-level commands
Q. 127: What are the objects & their properties when we talk in relation to
RFT?
Components like the dialog boxes, command buttons or labels have some sort of
information attached to them, which is known as their property. Properties of the
objects have a name and some value.
While undertaking any testing project, we usually need various properties of the
objects under the test process so that we can perform some sort of verification so
that we can programmatically find out the next action expected from the test script.
We usually come across a need like the following when we need to access the
properties of a test object:
2) To add a branch in the RFT script which is based on the current value of a
property contained in an object
3) Inserting the commands to extract a property value from an object into a variable
through the VP and Actions wizard.
A "TestObject" represents a connection point between the script which is played back
and the application being tested.
For every "TestObject" in a created test script, a corresponding object resides in the
application which had been recorded by us for a particular application. This object is
now available in the Test Object Map as well.
Here our search for the TestObject is based on name and value pairs representing
the properties of the concerned TestObject or TestObjects. Our search can be either
global or limited to children of a parent TestObject.
1) For searching the entire application, we can use the find method on the
RootTestObject.
2) For searching a specific object, we can use find on that TestObject. Searching a
specific TestObject will search only the children of that TestObject.
2) Helper superclasses are quite helpful in sharing the functionality across multiple
scripts.
3) A super helper provides a single place for us to park our code which we wish that
every script should access. Any piece of code placed there will be inherited by every
helper class that extends the super helper.
Q. 133: What type of events are recorded by RFT in its log file during
playback of the script?
1) Script start
2) Script end
6) Timer end
7) Exceptions
8) Verification points
Q. 134: What methods are used for including our own custom messages in
the RFT Log File?
1) For including our own General Messages : We can use the "logInfo" method.
Q. 135: How do we capture the current value of an option specified for the
script?
Value of an option set programmatically lasts until the end of the playback only.
After the playback finishes, the option reverts back to the default value.
To capture the current value of an option, we can use the "getOption" method like
the following:
Object x = getOption(IOptionName.option);
Value of "x" can be tested to find out whether we want to change the option value
during the playback. We can use the "setOption" method using the forma liket:
setOption(IOptionName.option,value);
Q. 136: What is the method to reset the value of an option back to the
default value in a script?
"resetOption" method can be used to reset the value of an option back to its default
value.
As an example, we can write a a code in the following sequence to change the delay
between keystrokes during the playback for a short time :
setOption(IOptionName.DELAY_BEFORE_KEY_DOWN, 0.3);
InputWindow().inputKeys("abcdefg123");
resetOption(IOptionName.DELAY_BEFORE_KEY_DOWN);
InputWindow().inputKeys("999");
We can create a RFT script which can serve as a command file for a suite of scripts.
We can use the "callScript method" for invoking other test scripts.
It is asample superscript package code which can be used in our own scripts. It
provides few methods which are useful when testing plugins running inside the
Eclipse platform.
These sample codes use the internal Eclipse classes. These must be used with prior
knowledge that these may break with future versions of eclipse.
In RFT we can use our own specified search criteria for locating the various
"TestObjects".
RFT executes the search based on name / value pairs representing properties of the
"TestObjects" being searched. This search can either be a global search or it can be
limited to the children of some parent "TestObject".
a) For Global Search : We use the find method on the "RootTestObject"; since
"RootTestObject" covers a global view of the software under test.
b) For Limited Search : We use "TestObject" find method which would search the
children of a particular "TestObject".
Q. 140: How do we search SAP TestObjects without using the Object Map?
In RFT we can use our own specified search criteria for locating the various
"TestObjects".
RFT uses a "RootTestObject" to represent a global view of the software under test.
Q. 142: Why does the script playback fails sometimes while testing HTML
applications?
Sometimes script playback for testing HTML application fails if the ready state of the
browser object is not set to 4. Hence it is necessary to ensure that the ready state of
the browser is set to 4 while playing back the script.
This can be done by manully changing the test script described in the
following examples.
logInfo("Ready State #:
"+browser_htmlBrowser().getProperty(".readyState").toString());
Script Support Functions of RFt help us to insert the code in the Scripts to
perform following tasks:
4) We can set delays and sleep states for RFT Script Playback.
Q. 144: How can we insert a call to a previously recorded script in our new
RFT Script?
While recording or editing a RFT script, we can insert a call to a previously recorded
script.
We can use "CallScript" command for inserting the following code in the script at the
cursor location:
callScript ("scriptname")
Q. 145: How can we measure the time taken by various events in a script?
We can measure the time taken by various events in a script by inserting timers with
different names into the same script.
We need to start & stop the timer to measure the time taken by a group of events.
timerStart("timername")
timerStop("timername")
Here "timername" is the name of the variable defined for the timer.
Script Assure Technology of RFT renders test scripts more resilient to changes in
applications.
With script assure technology, RFT evaluates the closeness of objects which it finds
and attempts to match it with something closer to it.
If the objects are close to each other, the test continues without any need of
intervention by the tester. However a warning is logged so as to communicate to the
tester about the happening of some problem.
2) Ability of tests to run without difficulty inspite of significant changes made to the
objects in the application under test.
5) Creation of reliable & flexible scripts which remain under more control of the
tester.
Q. 148: What are the key plus features of RFT over similar tools available in
the market?
1) Great ability of integrating highly useful java classes which recording and playback
cannot perform just due to its operations under eclipse environment. For example
database accessibility, necessary looping and switching.
We can use SQuirreL SQL an open-source tool written in Java to satisfy your
database testing needs. It perfectly integrates with RFT's record and playback
automation capabilities.
1) Making the scripts as generic methods, so that they can pass in many parameters
like SQL query strings and can dynamically verify the result set.
2) Creation of custom Super Helper Classes and puting these generic methods in
them. This will permit us to simply call the necessary method from the test scripts.
For example - making a query on a table
3) Alternatively we can keep these as scripts. We can still make them generic and
these can be called from shell scripts. For example - accepting different parameters
TUTORIAL
Tutorial - 1: How to retrieve the value of an object property
programmatically?
if("SUCCESS".equals(dialog_htmlDialogStatic().
getProperty(".text")))
dialog_htmlDialogButtonOK().click();
else
dialog_htmlDialogButtonCancel().click();
}
Tutorial - 2: How do we use an anchor to locate a particular object
using RFT?
Use of an anchor is useful in pin pointing a test object, which normally RFT finds it
difficult to differentiate between two similar objects during playback.
This happens usually when two browsers or instances of the same application are
open simultaneously. We can identify the browser and the instances of the
application by using a TestObject reference.
To solve this problem, we can use "ProcessTestObject" when we call the "startApp"
command as described below.
object(pto1, DEFAULT).click();
Use the Java Runtime Environment (JRE) which gets installed while loading RFT and
gets enabled for testing Java applications.
Step - 1: Setting up the logging options. RFT provides many logging options. Here
we can use the HTML log.
b) In the left pane of the Preferences window, expand "Functional Test" > then
"Playback" > click "Logging".
c) Verify that the Use "Default" check box is selected and that html appears in the
"Log type" field.
d) Click "OK".
These setting of Step -1, shall open the HTML log automatically after playing back of
a script.
a) In the Functional Tester menu, click "File" > "New" > "Functional Test Project".
b) Provide a logical "Project name" without any spaces for example - Testtutorial.
c) Provide a logical "Project location" for example - C:\Testproject. This will create a
new folder.
d) If the source control option is available, do not select "Add the project to Source
Control".
e) If the associate project option is available, do not select "Associate the Functional
Test Project with current Rational Project".
f) Click "Finish".
The Testtutorial project is now visible in the Functional Test Projects view, which is
the left pane in the RFT perspective.
Click "Window" > "Preferences" to access the RFT options. In the tree hierarchy, click
the plus sign (+) on the side of "Functional Tester " to expand the preferences.
Define the desired recording options. Close the preferences after completion.
Step - 2: Click the "Record a Functional Test Script" button or click "File" > "New" >
"Functional Test Script Using Recorder". The "Record a Functional Test Script" dialog
box opens.
Step - 3: In the "Record a Functional Test Script" dialog box, select the project to
which the new script shall be associated. Provide a name for the new script. The
script name should not contain space or special characters like : $ \ / : & * ? " < > |
#%-
Step - 4: In case it is required to keep the script under source control, Check mark
"Add the script to Source Control". This will add the script to "ClearCase", however
the script shall remain checked out and we are able to make changes in it.
Step - 5:
a) Click "Finish" to open the Recording Monitor & start the recording.
RFT will create a local object map for our script by default.
b) Click "Next" to open the "Select Script Assets page", In case we wish to use a
different test object map, helper superclass, or test datapool.
c) From the "Select Script Assets page", we can define the datapool record selection
order and we can also change the datapool associated with the script.
Step - 6: Upon opening of the Recording Monitor and starting of the recording after
Step -5, Click the "Display Help" icon for getting information on the toolbar buttons
and regarding operation of the monitor.
Step - 7: Click the "Start Application" button on the "Recording" toolbar to start the
test application. Perform the desired actions on the running application.
Step - 8:
a) For recording a verification point, identify the object in the application.
Step - 9: Click the "Insert Script Support Commands" button for inserting any
special features into the script. Features can be a call script command, log entry,
timer, script delay command, or comment etc.
Step - 10: Close the application, if we want closing of the application to be part of
the script.
Step - 11: Click the "Stop Recording" button to finish the recording.
This process writes the script and object map into the project directory. RFT window
gets restored and the recorded script gets displayed.
The purpose of creating verification points is to verify that a particular desired action
has taken place, or to verify the state of an object.
b) In RFT VB.NET Scripting, click the "Record a Functional Tester Script" button on
the Functional Tester toolbar or the "File" > "New" > "Add Script Using Recorder"
menu command to start recording a script.
Step - 2: Start the test application by clicking the "Start Application" button in the
RFT Recording Monitor.
Step - 4: In the RFT Recording Monitor, click the "Insert Verification Point or Action
Command" button on the toolbar.
Step - 5: On the "Select an Object" page of the Verification Point and Action Wizard,
use the Object Finder to select the list in the application intended to be tested. To
test the entire list, we can select any item in the list.
Step - 6: After selecting the list, we can see that one of the values shown on the
Object recognition properties grid is "list." Verify this "List" and click Next.
Step - 7: Go to the "Select an Action" page. Select the first option on the page i.e.
"Perform Data Verification Point" option.
b) "Selected List Elements" test - to test only the items which are selected.
Step - 9: In the "Verification Point Name" field, accept the default suggestion, or
provide a new name of own choice.
Step - 10: Use the "Include Retry Parameters" to set a retry time for a verification
point during playback to check for its existence. This retry option shall be helpful to
us when playback will fail to find the verification point in the application.
Step - 11: After accepting or editing the above fields, click "Next" to continue.
Step - 12: After viewing or editing the list data, click "Finish" button. This will record
the verification point & it will be added to the script.
Step - 13: Finish the recording by clicking the "Stop Recording" button on the
"Recording Monitor" toolbar.
We can open the Verification Point Editor any time to edit the data recorded earlier.
Tutorial - 6: How can we create a new RFT script Manually i.e.
without Recording?
Step –1: Click the "Create an Empty Functional Tester Script" button on the
RFT toolbar
Alternatively
Click "File" > "New" > "Empty Functional Tester Script" on the RFT menu.
Step –2: In the "Create an empty Functional Tester script dialog box", enter
or select a folder for the script and type a name in the "Script name" field.
The script name must follow the naming conventions defined for Java class names.
Step –3: Apply the check mark against "Add the script to Source Control" in
case we want to keep the script under source control.
Step –4: Here we have two options to create a local test object map for the script:
Option –1: Click "Next" for using a different "Test Object Map", "Helper
Superclass", or "Test Datapool".
Chose the desired test assets out the following choices offered in the "Select Script
Assets page", and click "Finish":
This step creates a local test object map for our script and displays the script in the
Projects View.
2) Click "Team"
For adding the desired objects and methods to the script we can use the Test Object
Map.
We can add special features like call script command, log entry, timer, script delay,
or comment to the script. This can be done by clicking the "Insert Recording into
Active Functional Tester Script" button available on the toolbar of RFT. Then on
the Recording toolbar, click the "Insert Script Support Commands button".
We can also use the buttons on the Recording toolbar for starting an application from
the script or for creating a verification point.
It is quite simple in RFT. The only thing we need to do is to bring the cursor at the
desired location in the existing script & start the recording from there onward. The
process of such recording is no different from the fresh recording. All features like
starting the applications, inserting the verification points, and adding the script
support functions are available as usual.
Step – 1: Bring the cursor to a location in the existing script from where onwards we
intend to start the recording.
Step – 2: Next step is to open the "Recording Monitor" and starts the recording. This
can be done in either of the following two ways:
Method – 1: Click "Script" > "Insert Recording" from the In the RFT menu.
Method – 2: Click the "Insert Recording into Active Functional Test Script"
button available In the RFT toolbar.
Step – 3: Next step involves starting the test application. This can be done by
clicking the "Start Application" button on the "Recording" toolbar.
Step – 4: Now we can perform all desired actions over the application.
Step – 5: We can record a verification point as well at this stage. This can be done
by locating the object in the application desired to be tested. A verification point can
be inserted by clicking the "Insert Verification Point or Action Command"
button.
Step – 6: We can insert any desired feature at this stage. The features like a call
script command, log entry, timer, script delay command, or comment into the script
can be added by clicking the "Insert Script Support Commands" button.
Step – 8: We can finish the recording operation by clicking the "Stop Recording"
button.
This process restores the RFT window and displays the script.
We use the "Verification Point Comparator" for comparing the verification point
data after playing back a script with a verification point and to update the baseline
file.
In case the verification point happens to fail, the "Comparator" displays both types of
values i.e. the expected and actual ones, so that we can draw a comparison. This
provides us adequate information for updating the baseline file with the actual values
from the actual file.
The Title of the Verification point gets displayed in the "Comparator" banner.
Following are the steps to compare and update the verification point data using the
Comparator:
Step – 1: Record a script in RFT and ensure that it must have at least one
verification point.
Step – 2: Play back the script containing the verification point on a new build of the
application under test.
Step – 3: View the log of the concerned playback after it gets finished.
Step – 4: Open the "Comparator" from the log & view the verification point by the
following.
a) In case of use of the TestManager log: Double click the verification point in
the "Event Type" column. Expanding the Script Start command can enable us to
see the verification point.
b) In case of use of the HTML log: Click the "View Results" link. At this stage
we are likely to get a Java plug-in error. Thus to avoid this error, ensure that the
Java plug-in is properly configured.
a) In case of failure of one verification point while using log in RFT – Java
Scripting: Select the log in the RFT Projects view. Then, right-click the log, and click
"Failed Verification Points".
b) In case of failure of one verification point while using log in RFT – VB.NET
Scripting:
Select the log in the Solution Explorer, right-click the log, and click "Failed
Verification Points"..
c) In case of failure of multiple verification points while using log: The wizard
of Results for Verification Points shall open. Click the desired failed verification point
in the list and click "View Results" or "Finish".
The Verification Point Comparator opens to display the concerned verification point.
The Comparator displays the expected and actual data values. The difference
between the expected and actual data values is that we performed the test with
some expected values. However the actual values were captured in the application
during the playback.
a) For Properties, List, Table and data Text type verification points: The
expected values are displayed on the left and the actual values are displayed on the
right:
Step – 7: View the two data files to draw a comparison of differences between the
expected and actual files. By close analysis of the differences in the Comparator, we
can find out if they are intentional changes to the application or are real defects.
For navigating through the differences, we can use the navigation buttons on the
toolbar above the data display.
Step – 8: We may need to edit the baseline file to update the information for future
playbacks. For this we need to load the baseline file. Click "File" > "Baseline" or
click the button "Load Baseline to Edit" available on the toolbar.
The baseline file replaces the expected file on the left side of the display.
a) For individual items in the data: We can edit them in the baseline (left)
column of the display. Click "Save", after completion.
b) For a Text type verification point: Click "Edit Text" to launch the text editor
to make the changes.
c) For all other verification point types: We can edit directly in the baseline data
display.
In the Verification Point Comparator, Right-click the property where the values are
observed to be different, and click "Replace Baseline on Current Selection".
b) In case all the differences reflect intentional changes to the application under test,
and we want to update the baseline to reflect the changes, we need to use the
"Replace Baseline with Actual Value" toolbar button to replace the entire
baseline file.
c) In case we have made any individual changes to the baseline data file – without
the use of "Replace Baseline with Actual Value" command, click File > "Save" to
save the changes.
Step – 11: We can come out of the "Verification Point Comparator" after finishing
the comparing and updating operation on the verification point data, click "File" >
"Exit" to exit the Verification Point Comparator
With the help of Properties verification point we can identify the presence of potential
defects in our application.
a) For RFT – Java Scripting: Click the "Record a Functional Tester Script"
button on the RFT toolbar or the "File" > "New" > "Functional Tester Script
Using Recorder" menu command.
b) For RFT – VB.NET Scripting: Click the "Record a Functional Tester Script"
button on the RFT toolbar or the "File" > "New" > "Add Script Using Recorder"
menu command.
Step – 2: In the RFT Recording Monitor, click the "Start Application" button to
start the test application.
Step – 4: In the Functional Tester Recording Monitor, click the "Insert Verification
Point or Action Command" button on the toolbar.
The objects in our application can be picked up on the "Select an Object page" of
the Verification Point and Action wizard, by either of the following three selection
methods.
Method 1: Object Finder Tool method: For selecting an object and all
descendents of the object, select one object, or select an object and the immediate
children of an object.
Method 2: Test Object Browser method: For browsing for the object that we
want to select. The browser displays a hierarchical tree of objects in our application.
The top level shows any applications we are running. Under each top level, RFT
displays the object hierarchy within that application. It is a dynamic view of the
currently available objects.
Method 3: Time Delayed method: For selecting pop-up objects, like menus. This
method uses the Object Finder tool, but enables us to set a delay, which gives us
time to reach an object which requires clicking on other objects first.
Step – 6: Advancement to the next page in the Verification Point and Action wizard:
On the Select an Object page, the check box "After selecting an object advance
to next page" is selected by default. This causes automatic advancement to the
next page in the Verification Point and Action wizard.
Alternatively If the check box "After selecting an object advance to next page"
is deselected, we need to manually click "Next" to move to the next page.
3) "Immediate" – For testing the object and any immediate children present at one
level down)
4) "All" – For testing the object including all of its children down the entire
hierarchy.
Under "Verification Point Name", accept the suggested default, or type a new
name in the box. The new name if any must be in accordance with standard Java
naming conventions.
Step – 10: Setting of retry time for the verification point during the playback:
The retry option is helpful when playback does not find the verification point in the
application & retry option checks the existence of the verification point.
a) We use the "Include Retry Parameters" for setting the retry time for the
verification point during playback. We can either use the default values, or set our
own values for the "Maximum Retry Time" & "Retry Interval".
Here by default RFT will check for the existence of the verification point in the
application every 2 seconds, for up to 20 seconds.
b) The value set under "Maximum Retry Time" indicates the maximum number of
seconds RFT will retry for the verification point to appear in the application during
playback.
c) The value set under "Retry Interval" indicates the number of seconds between
times that RFT will check for the verification point during the wait period.
d) Click "Finish", to write the retry for verification point into the script, which will
take place on future playbacks.
We need not test each & every property of the test object every time. Hence it is
better to just test the specific set of properties we want while using a Properties
verification point.
a) The test object's properties and their values are available for editing in a tree
table format on the "Verification Point Data" page.
b) Only those properties can be edited which happened to be tested. We can edit the
properties in the "Property" column, and can edit the property values in the
"Value" column.
c) Making a selection of object properties by check marking them for the test:
# By default, all properties appear with no checkmark meaning thereby they will not
be tested.
# We need to apply the check mark against the selected properties desired to be
tested.
# Check marked properties will be tested each time we play back a script with this
verification point.
# We can select all properties in the list by clicking the "Check All" toolbar button
above the grid.
# We can use the "Uncheck All" button to clear the selection of all the properties.
# To edit a value, double-click the tree table cell. That particular cell becomes
editable. We can click outside the cell, which causes the edit to take effect.
# In the case of the color property, we can edit the color value from the Color
Chooser available to us.
Step – 12: Using a Datapool reference in place of a literal value for a property
verification point:
a) In the "Property" column, select a property, right-click, and then click "Convert
Value to Datapool Reference". This will open The Datapool Reference Converter
dialog box.
b) Type a new name for the Datapool variable or click the "Datapool Variable"
arrow to select the variable that we want the verification point to reference in the
Datapool
c) Optionally, place a check mark on the "Add value to new record in Datapool"
check box to add the value of the verification point to a new record row in the
Datapool.
d) Click "OK".
Step – 13: Click "Finish" to complete the process of recording & adding the
verification point to the script. Stop the recording by clicking the "Stop Recording"
button on the "Monitor" toolbar.
1) Position the pointer in the script where we want to insert the comment.
2) Click the "Insert Recording into Active Functional Test Script" button on the Functional
Tester toolbar.
3) Click the "Insert Script Support Commands" button on the Recording Monitor toolbar.
Step – 2: Click the "Clipboard" tab, In the "Script Support Functions" dialog
box.
Step – 3: Inserting the clipboard verification point test command into the
script:
c) Click the "Convert Value to Regular Expression" button to convert the system clipboard
value to a regular expression pattern. This value shall be matched at runtime against
the system clipboard contents.
d) Click the "Evaluate Regular Expression" button to evaluate the current pattern
against the system clipboard contents. In the Evaluate Regular Expression dialog
box, the "Pattern" and "Match Against Value" fields contain the current value.
e) To try an expression, change the value in the Pattern field and click the
"Evaluate" button. The "Result" indicates whether the expression matched.
f) Click "OK".
g) Click the "Insert Code" button to insert the clipboard verification point command
into the RFT script.
c) Place a check mark on the check box "Precede variable assignment with type declaration"
to precede the variable name with a String type declaration.
d) Click the "Insert Code" button to insert the command for assigning the clipboard
content into a local variable in a functional test script.
b) Enter the value for the clipboard, In the "Set clipboard text to the following value" field.
c) Click the "Insert Code" button to insert the command into the RFT script for setting
the content of the clipboard to the supplied value.
Tutorial - 11: How to Data Drive a Test Script using IBM - RFT?
Step – 1: Creation of a Project: Project is the first & foremost workbench required
to store the test assets which are needed for testing any application.
Step – 2: Beginning of the test script recording: Involves two steps like:
a) Choice of Datapool record selection order: While playing back, the test script
accesses various records in the datapool either sequentially or randomly. Thus choice
out of these two options is done from the "Datapool Record Selection Order" box
from the Select Script Assets dialog box.
# Sequential order: Records are accessed by the test script in a sequential order
as they appear in the Datapool.
# Random order: Every record gets accessed by the test script randomly once from
the Datapool.
b) Finish the selections: Click "Finish" to minimize the Functional Tester window
and launching the Recording Monitor.
a) Opening of the Insert Data Driven Actions page after halting the recording of the
test script. To do this; click "Insert Data Driven Commands" on the "Recording"
toolbar,
b) Key in the initial values which are desired to be seen in the Datapool in the fields
required to be data driven in our application under test.
While recording is halted, we avoid recording of unwanted actions in the test script
by populating such fields.
Step – 5: Selecting the test objects: Under "Populate then Select Test
Objects" select the test objects through either of the two methods:
Method –1: "Press and drag hand to select test objects" is used to select an
object and all the descendents of the selected object. This is the most common and
direct method of selecting an object.
Method –2: For opening the Select Object to Data Drive page, "Use selection
wizard to select test objects". To do this click on the "Drag Hand Selection"
method with its options, alternatively click on the "Test Object Browser" method.
Step – 6: In case we had opted for method –1 under Step – 5 above i.e. "Press
and drag hand to select test objects"
a) Use the mouse to drag the hand shaped, "Object Finder tool", to the object in
the application which is desired to be selected. RFT automatically outlines this object
with a red border.
The Data Drive Actions page shall open now. The information about the objects
selected by us appears under the DataDriven Commands table.
For viewing the line of the code inserted by RFT in our test script, we need to place
the mouse pointer over a row in this table for data-driving our application.
Step – 7: In case we had opted for method –2 under Step – 5 above i.e. "Use
selection wizard to select test objects", click on "Selection method" arrow for
making a selection out of either of the further two methods:
Method –A: "Drag Hand Selection" method is used to include only the selected
object, the selected object and the immediate children of the selected object, or to
include the selected object and all descendents of the selected object.
Method –B: "Test Object Browser" method is used to browse for the object
desired to be selected.
Step – 8: In case we had opted for method –A under Step – 7 above i.e. "Drag
Hand Selection" method
a) Select or clear the option "After selecting an object advance to the next
page".
b) Use the mouse to drag the hand shaped Object Finder tool, to the object desired
to be selected in the application. RFT automatically outlines this object with a red
border.
d) Click on "Next" if we opt for not selecting the option "After selecting an object
advance to next page".
Step – 9: In case we had opted for method –B under Step – 7 above i.e. "Test
Object Browser" method
b) Click on the part of the tree required to be selected. Then Click "Next".
d) Click "Finish".
The Insert Data Driven Actions page opens & presents all the information filled in
under "Data Driven Commands" and "Selected Command Description".
Step – 10: Click "OK" to finish the data-driving process for the script. This closes
the "Insert Data Driven Actions" page and RFT presents a Datapool containing all
the data gathered from the application.
Step – 11: Perform all other actions in the application, which we want to record. The
actions can be like: Recording a verification point or inserting desired script support
functions into the script such as such as a call script command, log entry, timer,
script delay command, or comment etc.
Step – 12: Close the application, if we want closing of the application to be part of
the script.
Step – 13: Click on "Stop Recording" on the "Recording" toolbar, to append all
the recorded
Information to the test script and update the Datapool with new variables and
associated initial values.
RFT window opens and the recorded script gets displayed in the editor window.
1) When we import data, we ensure that we import the data into the same RFT
project as the test scripts that access the data.
2c) If we want to create the RFT project in a ClearCase directory, optionally, select
"Add the datapool to ClearCase".
# To import data into the datapool, click "Next", and then proceed to Step - 4.
3b) Either type the path to the desired folder or click "Browse" to browse to the
path and folder.
3d) If we want to create the RFT project in a ClearCase VOB, we can add the
datapool to ClearCase after creating it.
4a) Type the path and filename of an existing .csv file, click the "Import From"
arrow to select from a list of ten recently imported files, or click "Browse" to select
the path and filename.
4b) Type one to three field separator characters to use in the file we want to import.
Remember that RFT must use the same field separator character as the one used in
the .csv file from which we are importing data. If we are not sure which field
separator characters to specify, use a text editor to open the .csv file and see the
field separator characters that are used.
4c) "Select First Record is Variable Information" to make the first row of the
imported data, the header of a new datapool.
If we clear "First Record is Variable Information", the first record in the .csv file
is imported as data and the headers use the default headers, such as data0, data1,
etc. "First Record is Variable Information" is unavailable if the file we select to
import is not a .csv file or not a TestManager file.
4a) Click the "Import From" arrow to display a list of ten recently imported files,
and then select a RFT datapool from the list.
4c) Click "Browse" to select the path and filename of an existing RFT Datapool.
Click "Browse TM" to select the path and filename of the TestManager datapool we
want to import. RFT automatically extracts the header information from the
associated TestManager .spc file.
While recording or editing a RFT script, we can insert a call to a previously recorded
script. This allows us to avoid repeatedly recording similar actions on the application-
under-test by taking advantage of scripts that already exist.
click the "Insert Script Support Commands" button on the Recording Monitor
toolbar.
2a) Position the pointer in the script where we want to place the callScript command.
2b) Click the "Insert Recording into Active Functional Tester Script" button on
the RFT toolbar.
2c) Click the "Insert Script Support Commands" button on the Recording Monitor
toolbar.
Step - 3: Click the "Call Script tab" in the Script Support Functions dialog box.
Step - 4: In the "Script Name" field, select from the list the name of the script we
want to call or enter the name.
# Select "Use Current Record" to use the same record across the call script.
RFT inserts the callScript ("scriptname") code at the cursor location, where
scriptname is the name we had selected in the "Script Name" field.
Step - 7: Click "Close" to remove the Script Support Functions dialog box from the
screen.
a) For RFT - Java Scripting - from the "Functional Tester Projects view".
The most common way to create a verification point is while recording. But we can
also insert a verification point any time from the Script Explorer (in RFT - Java
Scripting, the right-most pane and in RFT - VB.NET Scripting, the leftmost pane) in
the RFT window when we are not recording.
Steps to insert a verification point while we are not recording are as under:
Step - 2: Open the script we want to insert the verification point into so that it is
displayed in the script window.
Step - 3: Put the cursor at the place in the script that we want to insert the
verification point.
Step - 4: Right-click "Verification Points" in the Script Explorer, and click "Insert
Verification Point".
Step - 5: On the "Select an Object" page, use one of the selection methods to pick
the object in the application, and click "Next".
Step - 6: On the "Select an Action" page, select one of the verification point
types. Click "Next".
The verification point will be added to our script in the location of the cursor, and will
be added to the Script Explorer in the Verification Points list.
Important: If we click "Finish" and have no properties or data selected for testing
(checked), a warning will display and the script is not modified.
You can replace a recognition property with a regular expression or a numeric range
to allow for a pattern-based recognition. The pattern allows for more flexibility in the
object recognition. You can convert properties to regular expressions or numeric
ranges from within both the Verification Point Editor and the object map.
You can undo any regular expression or numeric range. After you convert a value to
a regular expression or numeric range, the shortcut menu then contains an Undo
command, which you can use to return to the original value.
Steps to use a regular expression from the test object map are as under:
Step - 1: Select the object in the test object map or in the Unification wizard.
Step - 2: In the Recognition Property grid in the map or in the top pane of the
Unification wizard, right-click the value to change and select "Convert Value to
Regular Expression".
The value is designated as a regular expression by the blue in front of the value text.
Step - 3: Click another property in the grid, and then double-click the value so that
we can edit the field.
# To test our regular expression while we edit it, we can use the "Regular
Expression Evaluator". In "Step – 3", right-click the expression, and click
"Evaluate Regular Expression".
# The "Pattern" and "Match Against Value" fields contain the current value.
# To try an expression, change the value in the "Pattern" field and click the
"Evaluate" button.
Step - 4: Edit the value. For example, if it is a text property of "customer" we can
change it as described here.
# [cC]ustomer : This syntax allows any text that contains the word "customer" with
either an uppercase "C" or lowercase "c" will match. This is important because the
comparisons are case-sensitive.
# In the Regular Expression Evaluator, we can set an option for case sensitivity. The
"Perform Case Sensitive Match" option is on by default. Matching is case-
sensitive.
# If we want matching to ignore case, we need to clear this option. We can set case
sensitivity in the interface of the object map or the Verification Point Editor and
Comparator.
We are finished if we were in the test object map. If we used the Unification Wizard
in the map, click "Next", and click "Finish".
callScript("TheCalled");