Rational® XDE Tester
Release Notes
Version 2003.06.12
Part Number: 800-026280-000
© Copyright IBM Corporation.
2002 2004. All rights reserved.
Understanding XDE Tester Product Packaging
and Integrations
Before
Recording and Playing Back Scripts
Guidelines and Restrictions on Using Rational
XDE Tester
Script
Recording and Playback Issues
Purify,
Quantify, and PureCoverage Issues
Contacting IBM Rational Software Support
These release notes provide information that is not available in the Help for Rational® XDE Tester.
XDE Tester is a functional test-automation tool that enables organizations to validate business-critical Web and Java applications on Windows and UNIX platforms. Its unique capabilities enable both application testers and developers to rapidly create repeatable tests through a robust user-action recording engine and wizards.
You can record and play back on the following platforms:
· Windows NT
· Windows 2000
· Windows XP Professional
You can play back, but not record, on the following platforms:
· Red Hat Linux
· Windows 98
· Windows ME
Product changes described in this document and contained within this service release apply to Rational XDE Tester v2003.06.00.
Go to XDETester_readme_sr.html if you are
upgrading from Rational XDE Tester v2003.06.00. The Service Release Notes includes:
· Upgrade information and instructions
· Defects fixed in the current service release (v2003.06.12)
XDE Tester is the newest version of the product introduced as Rational RobotJ in Rational Suites Enterprise Studio, Rational Suites TestStudio, and Rational TeamTest version 2002.05.02. XDE Tester includes all the RobotJ functionality, plus new features.
RobotJ was included in Rational Suites with Rational TestManager and is integrated with TestManager. XDE Tester is a stand-alone point product, but it maintains the same integrations when you have the 2003.06.00 versions of both XDE Tester and TestManager installed. If you install Enterprise Studio, TestStudio, Robot, or TeamTest version 2003.06.00, you receive TestManager and you are able to use the integrated features of XDE Tester and TestManager. You can install the two products in either order — that is, you can install XDE Tester, then install Rational Suites (or another product that includes TestManager), or install Rational Suites/TestManager, then install XDE Tester. If you use the Rational Test Agents, this is a separate installation.
If you have both XDE Tester and TestManager, the integration features are available to you. These features include the TestManager Log, running Windows and Linux remote playback agents, test management features, and editing datapools through TestManager. XDE Tester has its own logs and does not depend on the TestManager log integration. If a feature depends on TestManager, it is noted in the XDE Tester documentation about that feature.
XDE Tester can make use of Rational projects and the Rational Test datastore if you have Rational Administrator and TestManager installed. A Rational Test datastore is used to store test assets such as test plans, test cases, test logs, reports, and builds. Use of the Rational Test datastores is optional. Regardless of whether you use a Rational Test datastore, XDE Tester uses an XDE Tester datastore, which is created from within XDE Tester.
XDE Tester is integrated with ClearCase and ClearCase LT. As with the initial release of RobotJ in Rational Suites and TeamTest, you must have one of the ClearCase products for this integration to work.
This document includes information about Version
2003.06.00. Detailed information about the current service release is available
here.
This release of Rational XDE Tester includes the following
new features and enhancements:
·
WebSphere WorkBench
(WSWB) 2.1.2 as the installed IDE
· Option to install and run in the same instance of the Eclipse shell as IBM WebSphere Studio Application Developer 5.0 and Rational XDE Developer
· Support for Netscape 7.01 and 7.02
· Support for Red Hat Linux 8 (for test playback only)
· Usability enhancements:
· Object Map: Ability to merge single or multiple private Object Maps into a single shared Object Map
· Object Map: Ability to update an object’s recognition properties directly from the Object Map — for information, see “Updating Recognition Properties” in the XDE Tester User Guide.
· Object Map: Ability to add user-specified recognition property for an object from the Object Map — to do this, in the Update Test Object Recognition Properties wizard, right-click on a property in the All Active Properties grid and select Add to Unified Test Object Properties. XDE Tester copies the property to the Updated Test Object Properties grid.
·
Verification Point: Simplified default Verification Point
names, and the ability to modify these through a template
· Verification Point: New Regular Expression evaluation wizard — for information, see “Regular Expression Evaluator” in the XDE Tester User Guide.
·
Verification Point: Regular Expression capabilities in all
Verification Point types and displays — you can now create regular
expressions and numeric ranges from values in all Verification Point types. See
“Replacing an Exact Match Property with a Pattern” in the XDE Tester User Guide
for information on using regular expressions from the Verification Point
editor.
· Log: Ability to launch Verification Point Comparator from an HTML log
· Enabler: Quick Search capability for searching Java environments through the registry
· Enabler: Ability to specify root directory in Search for Java/Web environments
·
Enabler: XDE Tester auto-enables the browser
plug-in JVM
· IDE: Ability to insert Verification Points from Script Explorer pane
·
IDE: Ability to insert Test
Objects from Script Explorer pane
·
IDE: Ability to view TestObject-specific
help information directly from the Script Explorer pane — the TestObject Interface Summary is a Help topic that describes
the selected object, including the supported test data types and the default
recognition properties. To display the TestObject Interface Summary, in the Script Explorer
right-click a test object and select Interface Summary.
· IDE: HTML and text logs are now displayed in the Datastore Explorer
· Preferences: Simplified Recognition Scores dialog (now called ScriptAssure™ and includes slider bar controls) — the ScriptAssure™ feature, which is XDE Tester's object recognition technology, enables you to successfully play back scripts even when the application-under-test has been updated. In this release, the user interface for this feature has been improved. There are two ways to use ScriptAssure™: Standard — The ScriptAssure™ Preferences Page-Standard enables you to control XDE Tester's object-matching sensitivity during playback by using a slider control. Advanced — The ScriptAssure™ Preference Page-Advanced enables advanced users to enter values to set thresholds for recognition scores. For information, see "Using Script Assure™" in the XDE Tester User Guide.
· ClearCase integration:
· Compare to Previous menu item to the Datastore Explorer PopUp Menu — using ClearCase, you can compare the current version of a script to a previous version. For information, see “Comparing Versions or Elements” in the XDE Tester User Guide.
· Enhanced Compare to Previous menu that allows comparing a script to any version of a script — for information, see “Displaying the History of an Element” in the XDE Tester User Guide.
· History menu item that allows users to view history comments
· Support for Single Stream UCM — XDE Tester works in a ClearCase Unified Change Management (UCM) enabled view if the view was created as part of a single-stream UCM project. XDE Tester will not work in views that are part of multi-stream UCM projects.
· Control Support:
· Verification Point support for SWT/AWT menus
This release of XDE Tester also includes changes to the API. These are flagged in the XDE Tester API Reference with Since RFT1.1. Syntax examples have been added directly into the API Reference in some of the important classes.
The XDE Tester Quick Tour helps you get started using XDE Tester. It
uses a sample Java application that is automatically provided in your XDE
Tester installation. The Quick Tour walks you through the major use cases for
testing with XDE Tester and shows you how to do the basics. To access the Quick
Tour from XDE Tester, click Help > XDE Tester Quick Tour, or click
the link at the top of the Welcome screen. We strongly recommend that you print
the Quick Tour and go through it from your printed copy.
The XDE Tester
documentation, which contains both API and user-guide information, is all
online. For important information on how to get started with XDE Tester, see
the topic "Getting Started with XDE Tester" in the XDE Tester User
Guide.
To access the XDE Tester documentation:
In XDE Tester, click either Help > XDE Tester User Guide or Help > XDE Tester API Reference.
Following is additional information about displaying the XDE Tester Help:
· To access the Help at any time while using XDE Tester, press F1.
· Some XDE Tester dialog boxes and windows also have Help buttons that display context-sensitive Help.
· To display Help in the Object Map, Verification Point Editor, and Verification Point Comparator, use the Help menu in that component.
Before you can record scripts, you must create a datastore and configure your applications and environments
for testing. For instructions on how to complete these setup tasks, click Help
> Getting Started with XDE Tester.
Note that sometimes virus scanning software can impede XDE
Tester’s performance. After you have installed XDE Tester, you may have
difficulty launching the Application Configuration Tool or the Enabler. In this
case, you can halt any virus scanning software on your system and try to launch
the Configuration Tool or the Enabler again. After they have launched
successfully, you can restart your virus scanning software.
The foreground lock
timeout indicates the amount of time in milliseconds after user input during
which systems that are running Windows 2000/XP or later do not allow
applications to force themselves into the foreground.
To enable playback
of scripts in Windows 2000/XP or later, the foreground lock timeout is
automatically set to 0 the first time that you run XDE Tester. Setting this
timeout value to 0 causes the Windows operating system to keep the behavior of
previous versions of Windows. Note that this is a persistent setting. For
information on how to set this timeout manually, see the XDE Tester Help.
If you are using remote execution of XDE Tester scripts on any of the above-listed Windows platforms, you should make sure that the foreground lock timeout is set to 0 on the agent computer.
XDE
Tester can sometimes hang during simple use of the product, particularly during
recording. In these instances, reducing the hardware acceleration on the
laptop's video card avoids the problem entirely. This is not a problem
that arises on what was a working system, but a problem you may experience when
you first install XDE Tester.
If
you experience such a problem, try lowering the hardware acceleration on your
video card. To do this, right-click on your desktop and
select Properties from the popup menu. In the Display
Properties dialog, click the Advanced... button on the Settings
tab. On the settings dialog, click the TroubleShooting
tab. To see if this is the problem, we recommend that you initially
reduce your hardware acceleration setting to None.
If this resolves the issue, you may be able to re-enable some level of hardware
acceleration without causing the problem to re-appear.
Rational has
determined that under certain circumstances file system corruption can result
from installing Rational Version 2003 products on Windows 2000 to an NTFS
partition that has the Windows "Change
Journal" (log) enabled on it. Rational is actively working with Microsoft
to better understand and identify a fix for the problem.
Before installing any Rational version 2003 product on a computer running Windows
2000, please read Rational Solution 182435434 at http://www.ibm.com/support/search.wss?q=182435434&rs=727
for the latest information. Alternatively, you can search the Rational Software
Support Knowledge Base at http://www.ibm.com/software/rational/support/
for the text "182435434".
If you are merging XDE Tester into an Eclipse environment that was not
installed by another Rational or WebSphere Studio
product, then you must make registry changes and a directory change as follows:
Directory change:
Go to the Eclipse install root. In the eclipse directory, create a new subdirectory named links.
Registry changes:
Under HKEY_LOCAL_MACHINE\SOFTWARE create:
Eclipse\2.0\product\<something> with values:
installdir=<folder containing
the eclipse folder>
name=<a
name to identify the shell>
version=<eclipse
version>
The <something>
can be anything, for example,
com.mycompany.
If a scroll action fails to take place during playback, XDE
Tester does not throw an exception. That is, missed scroll actions are not
fatal, script-stopping events. When the script performs actions that require an
object to be scrolled into view, XDE Tester automatically performs the action
so that the object is scrolled into view.
To play back both XDE Tester and Robot scripts to the same Rational Test Agent:
1. Start TestManager.
2. In a suite, insert two computer groups. Each group must have the Rational Test Agent as its computer resource.
3. Insert the XDE Tester script into one computer group, and insert the Robot script into the other computer group.
4. Run the suite. Both the XDE Tester and Robot script will execute on the Rational Test Agent.
If you are playing back a script on Linux and you are not
starting the application using the startApp
command in the script, you must set the following environment variable:
LD_PRELOAD=/usr/rational/test/XDETester/libftevent.so
XDE Tester does not record or play back actions against system menus.
If you use a Chinese Input Method Editor (IME) while recording in XDE Tester, XDE Tester does not record any ASCII characters that you enter. To avoid this issue, switch the input mode to standard ASCII layout when recording ASCII characters. To switch to another input mode in Windows, select Settings > Control Panel > Regional Options > Input Locales. When you want to resume recording Chinese characters, switch back to the Chinese input mode.
This release does not support playing back strings with double-byte characters on Linux, for example, playing back Japanese characters.
Playback to Linux agents supports Motif widgets for SWT. The GTK+ version of SWT is not supported.
Verification Point and Action Wizard Can
Freeze If Java Is Still Initializing
If you try to select an object in the Verification Point and Action
Wizard while a Java application or applet is still initializing, it can cause
the recorder to hang. To avoid this problem, do not attempt to perform an
action on a Java application or a Java applet within HTML while it is still
initializing. Do not use the object selector (the
selector hand) until you see that the Java application or applet is fully
rendered on the screen, indicating that is it initialized.
If the Verification Point Comparator is used from the HTML log, non-US ASCII, single-byte characters should not used in script names, test folder names, or in the datastore location. There is a defect in the Java Plugin for web browsers that prevents the use of applets from a local directory containing non-US ASCII characters (note that this does not apply to DBCS characters). The Verification Point Comparator can be started from the HTML log by using an applet. Examples of characters not to use include accent characters and ligatures. If non-US ASCII characters must be used, then you should open the Verification Point Comparator that is available by right-clicking the desired log in the Datastore Explorer.
Certain versions of Internet Explorer have a pop-up history mechanism for edit controls. This history pop-up list, which XDE Tester ignores, may hide other controls and therefore may interfere with playback of actions on the covered controls. If this occurs, end the keystroke input to the edit control with a tab character, which dismisses the history pop-up list.
Do not run the Enabler when Netscape QuickLaunch is running; XDE Tester does not work with QuickLaunch. If you want to run the Enabler to enable Netscape for HTML testing, you must first disable Netscape QuickLaunch and then run the Enabler.
To disable QuickLaunch when Netscape is running in the background:
1. Right-click the QuickLaunch icon that appears on the right side of the Windows taskbar.
2. Click Disable QuickLaunch.
To disable QuickLaunch when Netscape is running in the foreground:
1. In the Netscape menu bar, select Edit > Preferences.
2. In the Preferences dialog box, click Advanced.
3. In the Advanced area of the dialog box, clear the Enable QuickLaunch check box.
In an XDE Tester
script, a browser or an application can be started, stopped, and started again.
If a script starts, stops, and immediately restarts Netscape, Netscape may stop
responding. To prevent this from occurring, after XDE Tester has finished
recording the script, manually code a sleep method. This method should be
included after the method that closes Netscape and before the method that
restarts it.
For example, in the recorded script, you may
see the following lines of code, which do not contain a sleep method:
public
class BasicFormTest extends BasicFormTestHelper
{
public
void testMain (Object[] args)
{
startApp("aries-web");
Link_HTMLFormElementsamplepage().click();
Browser_htmlBrowser(Document_HomePage(),DEFAULT).close();
startApp("testHtmlApp");
}
}
Following are the
same lines of code, with a sleep method inserted:
public
class BasicFormTest extends BasicFormTestHelper
{
public
void testMain (Object[] args)
{
startApp("aries-web");
Link_HTMLFormElementsamplepage().click();
Browser_htmlBrowser(Document_HomePage(),DEFAULT).close();
sleep(1.0);
// Gives Netscape time to close.
startApp("testHtmlApp");
}
}
Note that the
argument 1.0 represents the number of seconds that elapse when the sleep method
is executing. Enter a delay of at least 1.0 seconds into this argument. If the
problem persists, increase the delay interval.
If you want to test (that is, record and play back) HTML against Netscape and you have enabled Java in Netscape, you must make sure that the JRE loaded by Netscape is also enabled.
Because the JRE
loaded by Netscape is not automatically enabled, you must check to see whether
this JRE is enabled, as follows:
1. In XDE Tester, select Configure > Enable Environments for Testing.
2. In the Enable Environments dialog box, select the Java Environments tab to see whether the JRE used by Netscape is enabled.
3. If the JRE used by Netscape is not shown or is not enabled, click Search. In the Search for Java Environments dialog, make sure that Quick Search is selected and click Search to do a quick search for all JREs on the system. From the list, select the JRE installed with Netscape and click Enable.
Once the JRE is enabled, you must determine whether the JRE that is running in Netscape is designed for Netscape 6.x. To do this, in Netscape select Help > About Plug-ins and verify that the plug-in for mime-type application/x-java-vm is Java Virtual Machine for Netscape 6.x. If it is not, download a new java plug-in by going to http://www.javasoft.com.
If Java applet and HTML text input controls are displayed on the same page, the playback of the input keys for the HTML may be redirected to the text input controls in the Java applet. This occurs because the Java applet takes the input focus after it initializes. In this case, the browser cannot determine whether the Java applet is in a ready state. The Netscape browser only sees that the document is ready, and it begins script playback.
To solve this issue, record a WaitForExistence command on the Java applet before recording anything for the HTML controls. On playback, this forces a wait, which makes the Java applet ready before any other playback begins.
When trying to record a close-browser action in an open browser, do not double-click the browser icon on the upper left of the browser window. XDE Tester does not record such close-browser actions. Instead, use the standard Windows Close Window icon on the upper right of the browser.
Standard properties of browsers were changed in some cases after RobotJ 1.0. This could result in some Verification Points recorded on RobotJ not playing back correctly on XDE Tester. You may want to update your baseline to ensure that any problems are not resulting from a change in the tool. Below is a list of the elements with the properties changed, and how the property is different.
INPUT elements:
.indeterminate: Change the default on NS(Netscape) to be false, not null.
.src: change the default on NS to be 0 rather than null.
TextArea:
.type: property was removed. Not part of the W3C standard.
SELECT elements:
.text: trim leading white space on IE (Internet Explorer)
.value: was always null on IE, now returns selected option
Image Button:
.src: on NS return the full path, not the relative path to the image.
FORM elements:
.text: trim leading white space on IE.
IMAGE elements:
.border: change the default on both browsers to be 0
.hspace, .vspace: change default on NS to be 0
.align: lower case text on NS.
Do not attempt to enable Mozilla Version 1.2.x. This can possibly corrupt the browser.
If you are planning to uninstall XDE Tester from an instance of the WebSphere Studio Application Developer (WSAD), be sure to close the Test perspective before you exit WSAD and uninstall XDE Tester. This ensures that there are no errors when you restart WSAD.
Message and error dialogs raised from the JFC JOptionPane class use a different dialog class in JRE 1.4 than was used in JRE 1.3 and earlier versions. This class change will cause actions recorded in JRE 1.3 to not play back if the application’s JRE is changed to JRE 1.4 or later. To work around this problem the class property must be updated to reflect the class change using the "Update Recognition Properties" support in the Object Map Editor. If you want backward compatibility, replace the class property with a Regular Expression that matches against either class name.
When testing Java applets, you must use versions 1.3.1_02 or higher of the JRE and Java plug-in.
If you install a JavaSoft JRE, the associated JavaSoft Java plug-in may also be installed. If this Java plug-in is installed, it becomes the default Java plug-in that is used by your browser and XDE Tester. That is, it overrides any previously installed version of the Java plug-in. If you install a Java plug-in that is older than version 1.3.1_02, Java applet testing for Internet Explorer with XDE Tester does not work. To test Java applets with XDE Tester, you must use a Java plug-in and JRE version 1.3.1_02 or higher.
When playing back a script that has actions against a combo
box item that is not in view, XDE Tester does not succeed in scrolling the item
into view.
When accessing a .jar file using a UNC path (for example,
\\yourname\…), and the .jar file is not self contained, either you must use a
JRE version of 1.4.x, or you must put the .jar file in the classpath
and set the main class to run the class.
TestManager does not compile XDE test scripts. If a script has not been compiled by XDE Tester before running it from TestManager, TestManager gives an error. Usually, XDE Tester scripts are compiled only through XDE Tester. A test script is compiled automatically when the XDE Tester datastore that contains the test script is connected to XDE Tester, or when the datastore is refreshed in the XDE Tester Datastore Explorer.
If you plan to run an XDE Tester script unattended from the command line, you must either install a JRE, which will be added to your path, or set your working directory to the location of the default JRE, that is, <rational_install_dir>\common\bin\jre.
If you disassociate a datastore in XDE Tester, any TestManager assets that point to that datastore become invalid, even if you later reassociate the datastore with the same name. This is because associating an XDE Tester datastore with TestManager always creates a completely new registered script source.
XDE Tester keeps information in its datastore that describes itself to TestManager. If you move an XDE Tester datastore on your local machine, XDE Tester uses this information to automatically update TestManager about the new location when you next open the datastore.
If you copy a datastore to a different machine, XDE Tester uses the information in the datastore to connect to TestManager and update TestManager about the location of the XDE Tester datastore on the new machine.
If you copy (not move) a datastore on the same machine, each time you use XDE Tester on either of the two datastores, it will update TestManager with the new location information. This can lead to unexpected results as you load the two datastores. In this scenario, we strongly recommend that you edit the DatastoreDefinition.rftdsd file (found within the datastore in the resources directory) and remove the values for ProjectPath and ScriptSourceUID. The datastore definition file is XML and should be edited carefully. For example, if the UID appears in the original file as follows:
<ProjectPath>\\atburepos\E\TTProject\RobotJXDE
Tester\RobotJXDE
Tester.rsp</ProjectPath><ScriptSourceUID>ca68d865-adf-49f7-918529d65342556</ScriptSourceUID>
delete the UID in the new copy, as follows:
<ProjectPath></ProjectPath><ScriptSourceUID></ScriptSourceUID>
This section describes using XDE Tester to test Eclipse 1.0-based and Eclipse 2.0-based applications.
Note: The procedures in this section also apply to users who are running XDE Tester in a configuration where it shares its shell with other products, for example, WSAD.
To test an Eclipse 1.0-based
application with XDE Tester, you must perform two major tasks:
1. Configure XDE Tester and the application-under-test so that each runs in its own instance of the Eclipse 1.0 shell.
2. Enable the application for testing by XDE Tester.
To configure XDE Tester and the application-under-test so
that each runs in its own instance of the Eclipse 1.0 shell:
1. Create a separate metadata directory so that you can run a separate instance of the shell.
Note that this directory does not need a special name or location. However, remember the name and location of this directory because you need to refer to it when configuring the application under test, as described in Steps 2 - 6.
2. In XDE Tester, open the Application Configuration tool by selecting Configure > Configure Applications for Testing.
3. In the Application Configuration Tool dialog box, click Add.
4. In the Add Application dialog box, select Executable or Batch File and click Next.
5. In the File Edit dialog box, insert the full path name of the Eclipse 1.0 executable, which is either of the following, depending on the type of application that is installed:
<drive
letter>:\<path>\eclipse.exe
or
<drive letter>:\<path>\wsappdev.exe
6. In the Args text box of the Application Configuration Tool, specify a new metadata directory by entering the following and then clicking OK:
-data <dir/path for
metadata>
Note that if you have spaces in the names in your directory, you must put the full path in quotes.
To enable the application for testing by XDE Tester:
1. Copy the com.rational.test.ft.enabler.wsw plug-in (typically found in C:\Program Files\Rational\XDE Tester\eclipse\plugins) to the plugins directory of the Eclipse-based application you want to test; for example, C:\Program Files\IBM\Application Developer\plugins.
2. After the Enabler directory is copied, start the target Eclipse-based application that you want to test. In the application-under-test, select Perspective > Show View > Other.
3. In the Show View dialog box, select XDE Tester Enabler to expand the node and then select XDE Tester Enabler View. This action adds the invisible XDE Tester Enabler view to the Eclipse-based application.
Once you have selected the view, the other open views resize to accommodate it. This resizing action confirms that the view is loaded. The XDE Tester Enabler view appears as a blank window.
You are now ready to begin testing the Eclipse 1.0-based
application under test with XDE Tester.
To test an Eclipse 2.0-based
application in XDE Tester, you must perform two major tasks:
1. Install XDE Tester and the application-under-test in separate instances of the Eclipse 2.0 shell.
2. Enable the application for testing by XDE Tester.
To configure XDE Tester and the application-under-test so
that each runs in its own instance of the Eclipse 2.0 shell:
1. In XDE Tester, open the Application Configuration tool by selecting Configure > Configure Applications for Testing.
2. In the Application Configuration Tool dialog box, click Add.
3. In the Add Application dialog box, select Executable or Batch File and click Next.
4. In the File Edit dialog box, insert the full path name of the Eclipse 2.0 executable, which is either of the following, depending on the type of application that is installed:
<drive
letter>:\<path>\eclipse.exe
or
<drive
letter>:\<path>\wsappdev.exe
Enabling Eclipse 2.0-Based Applications for Testing
To enable the application for testing by XDE Tester, copy
the com.rational.test.ft.enabler.wsw_2.0.0
plug-in (typically found in C:\Program
Files\Rational\XDE Tester\eclipse\plugins) to
the plugins directory of the of
the Eclipse-based application you want to test; for example, C:\Program Files\IBM\WebSphere
Studio\eclipse\plugins.
You are now ready to begin testing the Eclipse 2.0-based application-under-test in XDE Tester.
The File > Import and File > Export commands do not perform these actions for XDE Tester scripts. Only the selected files are exported to a specified medium, but XDE Tester scripts require that all related files (such as verification point, object map, and helper class files) also be exported, which Eclipse cannot do. Because the Export command does not export all the script assets, the Import command cannot have the desired effect.
Using the Refactor commands to rename or move compilation unit names does not have the desired effect when applied to XDE Tester scripts and script helper classes. Script class names must be changed using the Datastore Explorer so that all script assets can be updated at the same time. The test script cannot be played back if you rename any one part of the script without updating the other assets.
Do not use the Compare With or Replace With items that appear in popup menus for files, folders, and datastores. These items are not designed to handle XDE Tester scripts.
Eclipse alters the name of a file containing Japanese characters when it is exports it to a Zip file. When exporting the same file to a file system, the name is unchanged.
If you start the Enabler and search for JREs, the search action searches all directories, which may include mounted network partitions. On a system with a large mounted network, the search could take a long time. Therefore, on UNIX you should use the Add button to add a JRE to the list, or you can use “Search In” to search from a specific root directory.
There is a defect in the implementation of JFileChooser
in IBM JRE 1.3 included with IBM's Workbench that prevents the user from
selecting root drives in Windows with a mouse click. In the Enabler, a user can
browse the directory hierarchy to determine where to begin a search for
browsers or JREs. Because of the defect, when the
Enabler is started from within the XDE Tester Eclipse shell, you must manually
type in the drive name to begin a search at a directory root (for example,
"C:\").
XDE Tester supports basic, minimal integration with PureCoverage. As part of an application’s configuration, command-line parameters can be supplied for running PureCoverage against the following:
· XDE Tester scripts
· Java applications-under-test
· Applets
You must configure and run PureCoverage for each application that is being tested by XDE Tester.
Due to significant incompatibilities between XDE Tester and Rational Purify and Quantify, applications running under Purify and Quantify are not supported for record and playback with XDE Tester.
JRE 1.4.1 is the default JRE that is included with XDE Tester. When working in this particular JRE on Linux systems with glibc 2.2 (that is, Red Hat 7.x), you must set the following environment variable when starting up the agent:
export LD_ASSUME_KERNEL=2.2.5
If you do not set this
variable on glibc 2.2 systems, the agent hangs when a
script is run from TestManager. Note, however, that this same
variable may cause some versions of Sun's JRE to have problems on Red Hat 7.1.
In certain situations, XDE Tester may stop responding due to defects in the glibc package that is included with Red Hat Linux 7.1. To resolve this issue, download and install the latest updates available from Red Hat (currently, glibc 2.2.4-24).
To play back scripts on Linux that use multiple instances of a browser, use Control-N to open the new instance. This avoids an intermediary dialog box from Netscape that prevents the script from playing back.
Trend anti-virus software does not work with Rational ClearCase. If you try to use XDE Tester with both ClearCase and Trend running, the system stops responding.
To use Trend and ClearCase together without any
problems, go to Trend and exclude the
following files from virus detection:
· Mvfs drives (Multi-version file system, that is, dynamic view drives)
· View storage files (files with the extension .vws)
· VOB storage files (files with extension .vbs)
XDE Tester Datastore Explorer’s Show Checkouts feature does not show the checked-out scripts, files, or maps in ClearCase views that are specified by a UNC path. Therefore, when working in a ClearCase snapshot view, always use a mapped path. When working in a ClearCase dynamic view, select Start View from ClearCase HomeBase and use the mapped path.
If you want to open a datapool by coding the TSSDatapool.open method into the script, you must use a fully qualified pathname if you intend to play back the script through the RobotJ UI and the datastore is not associated with a Rational project.
If an incorrect character (for example, a square box) displays in the Message Option window, you should change the current font to a font that supports the needed characters. You must change the font in two places:
· In XDE Tester, select Window > Preferences > Workbench > Fonts.
· Open the XDE Tester Enabler by clicking Configure > Enable Environments for Testing, and, in the Enabler, click Change Font.
In the
2003.06.12 release, XDE Tester users that do not have administrative privileges
are required to change the permissions for the XDE Tester configuration
file. This can be accomplished in two
ways:
1. Have an administrative user set the permissions
on the following file to be accessible to all users (add "Full
Control" for all users).
<rational install directory>\XDETester\configuration\configuration.rftcfg
2. Copy the configation
to a location writable by all users of XDE Tester on this system and change the
following registry setting to point to this location:
HKEY_LOCAL_MACHINE\SOFTWARE\Rational
Software\Rational Test\8\Rational FT Configuration Directory
Note that the setting is for the directory
that contains the configuration.rftcfg file and not
to the file itself.
Failure to
do so will result in serious errors when updating the application configuration
or when enabling environments. On first
start, XDE Tester will attempt to automatically enable default browsers and jvms, and will post an error about a seemingly unrelated InvocationTargetException if this change is required.
When you first install XDE Tester, it may not record the correct test object on the first action in Netscape. If this occurs, reboot your machine and restart XDE Tester.
In versions 6.x and 7.0x of Netscape, XDE Tester cannot always determine which version is loaded on the system. If XDE Tester cannot determine the version, XDE Tester will configure the browser, but not try to enable it. If you run the Enabler and see a Netscape browser that is configured but not enabled, select the browser and enable it directly.
When you check out an XDE Tester script or file in ClearCase, in certain situations XDE Tester interprets that the script is hijacked when it is not. To resolve this issue, check out the file as if it were not hijacked.
If you are using JDK 1.4 or later, characters entered by means of the numeric keypad to support an input locale do not play back correctly. This is a known JDK defect.
The location of the JRE extensions directory can be changed
by specifying the “-Djava.ext.dirs=” option on the
command line. Part of the XDE Tester Java enablement process includes placing
.jar and .dll files in the EXT directory so that the
Java toolkit can locate them when an application starts up. If the EXT
directory has been changed, these files cannot be located and the application
fails to initialize properly.
XDE Tester cannot work around this error. If the EXT
directory is changed, the user must take one of the following steps:
·
Add the JRE extension directory to the command
line setting that specifies the EXT directories. This is a path variable that
permits multiple entries.
·
Add the rational_ft_bootstrap.jar
file to the command line classpath. Typically, .jar
files in the extension directory are picked up automatically, but if the extension
directory changes, they need to be added explicitly to
the classpath.
·
Copy the rational_ft*
files from the JRE extension directory to the new location. This solution is
less desirable because it does not allow XDE Tester to manage the versions of
the enabler files.
If you change the location of the EXT directory, the best
solution is to add the new directory to the path and not remove the original
directory specification. Leaving the original JRE EXT directory in the path allows
XDE Tester (and other tools) to share the special default consideration used by
the Java security model.
If you install a Java JRE or JDK and then change the default Java plug-in, you must enable the new plug-in JRE. To find and enable all JREs:
1.
In
the XDE Tester main menu, select Configure > Enable Environments for
Testing.
The Enable Environments dialog box displays.
2. Select the Java Environments tab.
3. Click Search to find the Java environments.
4. Select Quick Search.
5. Select all the Java environments that are found by the search, and click Enable.
6.
Close
the Enable Environments dialog box.
If your test application is open, close and restart it.
Note: For XDE Tester to work with Internet Explorer, the installed Java plug-in must be version 1.3.1_02 or higher.
When the Agent runs a test suite or a test script that calls other scripts, it does not automatically delete the files that are in the directory /tmp/rtagent_0 or in the created directory. Therefore, if you want these files to be deleted, you must delete them manually. If you do not delete these files, they may use up too much space when you are running a suite or a large script.
In the XDE Tester com.rational.test.util.regexp package, Unicode is supposed to recognize \w as an underscore (_) when \w is used as part of a word. However, Unicode currently does not recognize \w.
The IBM software support
Internet site provides you with self-help resources and electronic problem
submission. The IBM Software Support homepage can be found at www.ibm.com/software/support.
Voice Support is available to all current contract holders via a telephone number in your country (where available). For specific country phone numbers, please refer to the IBM Software Support Handbook, Appendix B: Contact Information, found at www.ibm.com/software/support.