|
1. Version 2 FAQs
2.
Licensing
&
Business
FAQs
3. Project & Community FAQs
4. Plugin FAQs
5.
Technical
FAQs
1. Version 2
FAQs
Q: What is new in
release 2?
There are many functional and
architecture enhancements such as:
- Redesigned modular architecture with a
plugin framework. It allows you to implement and plug in your
own features in a standard cross-version compatible way. As most
internal features are also implemented as plugins you can easily
customize them and plug them back in. Such a system enables you to
customize the tool and upgrade safely without losing your functionality
changes. A good example is the ReportProvider interface
giving you an opportunity to code your own report format in Java and
plug it into the tool as a plugin.
- Native Java support.
There's an API allowing you to write
test scripts directly in Java. The tool recognizes .java
files and it can compile and execute Java code on the fly both from the
GUI and CLI. The Java tests may be also executed as standalone programs
through their main() method or started from any other
Java program. For those who wish to migrate from the scripting language
to Java there's a converter available.
- Plenty of improvements on
top of the former 1.3 functionality, such as RFB listening mode, image
collections, mouse wheel support, ability to handle key location and
key events consisting just of modifiers, and many other minor features.
For a complete list of changes see the What Is New In T-Plan Robot 2.0
document.
Q: What is the
motivation behind the 2.0
project?
The 2.0 project is driven primarily by the feedback, ideas and
suggestions submitted by the community. Open source together with
modular design allowing to customize the tool and reuse the code was
one of the top requirements. Many of you have expressed interest in the
image comparison algorithms, in particular because there are not many
open Java implementations available on the web.
With help of a few
members of the community I also realized two major weak points of the
1.x version, the proprietary scripting language and hard dependency on
the RFB
protocol. As the new version is planned to allow writing and execution
of tests in Java, users will be able to take advantage of all Java
language capabilities. A nice side effect is
that it will allow testers to load test data from virtually
any data source like relational DB (via JDBC), Excel sheets and CSV
files (via Java Excel API, JDBC Excel driver or jXLS) or XML (e.g.
using JAXP).
Last but not least the newly introduced client modularity
is intended to remove the hard dependency on RFB protocol and enable to
plug in other remote or local desktop clients. Simply said the tool
should be
able to perform testing over other protocols such as Remote Desktop
Protocol (RDP) in the future.
Q:
Is
VNCRobot
version
1.3
going
to
be open sourced and maintained as well?
No. As support of the legacy 1.x versions has ended in December 2009 we
do not provide the products for download any more.
Q:
Is
the
2.0
version
going
to
be compatible with the 1.3 version?
The 2.0 version will preserve compatibility
with v1.x in the following areas:
- Compatibility with
the v1.x scripting language.
It means that you will be able to migrate test scripts created with
VNCRobot 1.x onto the 2.0 version without any major modifications.
Format of the outputs like screenshots and HTML reports may however
change a bit.
The 2.0 version will introduce incompatibilities
with 1.x in the following areas:
- Open API ( http://www.t-plan.com/robot/docs/v1.3/api/index.html).
As
interfaces
were
radically
redesigned,
the methods and objects are
likely to change. This impacts just a very few users who plugged in
their own Java extensions. Some Java development efforts will be needed
to migrate such extensions onto 2.0.
- The command line interface(CLI)
is
compatible
with
the
1.x
versions in terms of supporting the same set
of CLI options. Names of the product JAR file and start scripts have
however changed as a result of rebranding. If you have integrated
VNCRobot CLI calls into your test framework, you will have to update
the starting commands or eventually rename these files to their old
names (robot.jar to vncrobot.jar, robot.sh to vncrobot.sh, robot.bat to
vncrobot.bat).
Q:
I have working
test scripts written for VNCRobot 1.3. Should I be afraid of migration
to version 2?
Not at all. The scripting language is compatible and your
scripts should work fine right away. If you wish to migrate to Java
test scripts, there's a converter to Java available. It is not perfect
but in vast majority of cases it will get you converted to Java pretty
fast with just minor Java coding efforts. There's a good documentation
on everything you might need and it will be updated on the fly with the
feedback from the community. Should you need assistance anyway, apply
for support (this time commercial, sorry).
Q:
Which
version
of
Java
will
be
required by v2?
Java 6 (formerly 1.6) or higher. If you want to take advantage of Java
test scripts, you have to use the Java Development Kit 6 (JDK 6)
instead of Java Runtime Environment 6 (JRE 6). The difference is that
JDK contains compiler needed for runtime compilation of Java code. If
you use just a JRE, the tool will run but it won't allow you to compile
and execute Java source code (.java files). This limitation doesn't
apply to already compiled Java test scripts (.class
files). Java requirements are documented in the Release Notes document.
Q:
Are
there
any
changes
in
platforms
supported by version 2?
Not really. As the tool is written entirely in Java, it considered as
platform independent and it should run anywhere where Java is
supported. If you see any failure which is obviously caused by
incompatibility with the underlying platform, report a bug. The 2.0
version will be actually better compatible with mobile platforms thanks
to implementation of the RFB listen mode and more intensive
testing. We for example resolved an issue with PocketVNC and made our
product suitable for testing of Windows mobile applications. Platform
support is documented in the Release
Notes document.
2. Licensing
& Business FAQs
Q: I'm user of VNCRobot 1.x. How does the T-Plan
acquisition impact me?
From the end user perspective there are very little changes. The
VNCRobot 1.3 binaries will remain on the web for download under the
current freeware license. As its support and maintenance will end in
December 2009, you
should consider migration to T-Plan Robot
2.0. See the FAQs above for infomation about compatibility and
migration risks. As version 2.0 will also ship as a free open sourced
product, there's no impact on low budget users. Only if you need a more
relaxed license, extra features or services (support), consider paying
for the Enterprise Edition. Comparison of the open source and
enterprise versions iis available at the Versions page.
The acquisition and open sourcing also draw a clearer line of public
free support. We are happy to deal with obvious bug reports,
feature/enhancement suggestions and technical inquiries which are not
covered by the documentation. This type of feedback brings added value
in form of quality improvements and innovation and we are determined to
keep spending resources on the open source code and documentation
development. Many hours of precious time were however burnt in the past
to support users who prefer to ask without reading the docs first. We
are still happy to do it, but only for enterprise users who actually
pay us for being online and respond such type of questions.
Last but not least the acquisition widened the project outlooks and set
its future strategy. Commercially supported open source software gets
more attention and it has a more secure future thanks to stable
financing. Integration with T-Plan's high quality test management
software delivers a solution covering the whole QA life cycle, from
design of test plans and test cases through testing, bug tracking,
automation to reporting and tracking the test coverage back to the
requirements specification.
Q:
How
is
T-Plan
Robot
v2
licensed?
There are two editions:
- T-Plan Robot
2.0 is a version with limited functionality available free of
charge under GNU General Public License (GPL) on SourceForge. This
project is not backed up by a reliable support. It is being maintained
in terms of bug fixing but no new features are being actively
developed.
- T-Plan Robot Enterprise 2.0 is provided for a fee under a
more relaxed binary license with no copyleft applied. The product
delivers extra features, integration with T-Plan Test Management
products and support. As the product core is derived from the open
source code, it is backward compatible with the free version in terms
of test script, plugin and configuration migration.
For a an overview of T-Plan Robot and T-Plan Robot Enterprise products
see the Versions page.
Q: Why is T-Plan Robot Enterprise licensing
based on number of test environment connections?
We are in fact charging for one T-Plan Robot connection to a test
environment. This model better
reflects
the product ability to scale and the value it creates.
One T-Plan Robot instance running either in the CLI or GUI mode is able
to connect to one test environment
(VNC server instance or any other
supported technlogy) at a
time. There is typically one user who writes test scripts and then
executes them (or gets the OS scheduler to run them) sequentially
against one or more test environments. In this scenario our pricing is
equal to traditionally understood "user" or "per seat" pricing and one
license is good enough because there is never more than one connection
to a test environment at a time.
It is however possible to start multiple
T-Plan
Robot
instances to
perform testing in parallel on a number of test environments. It brings
a significant added value in form of reduction of testing time. In this
scenario we charge for each instance while offering significant volume
discounts to let you realize your added value and savings.
There's also
a Java programming API allowing to create and run multiple automated
testing threads within one Java Virtual Machine (JVM). Each
single
thread behaves as a standalone T-Plan Robot instance and it can also
connect to one test server at a time. This set up is typically employed
for load testing or when the tool is integrated with a Java project. In
this case we also charge for each instance.
An important factor is that we don't
lock the license either to computer or user. Each license is
effectively a floating one and you may have the product circulating in
your company as long as you don't exceed the number of licensed
connections. We also do not lock it to a certain product version and
when there's a new release, you are free
to
upgrade as long as your license key is valid.
Should you have any further questions regarding pricing or the license
contact our Sales department through the T-Plan Contacts page.
Q:
When should I prefer T-Plan Robot v2.0 Enterprise Edition to the GPL version?
A few reasons why you should consider to pay for the enterprise license:
- GPL
restrictions. GPL requires you distribute any derivative work as
open source under GPL. This is known as "copyleft". The practical
impact is that if you write a Java test script, plugin or enhancement,
it is in terms of GPL considered to be a derivative work of T-Plan
Robot and it is covered by GPL. If you decide to distribute it to a 3rd
party, you have to do so under GPL and with the full source code. The
Enterprise license is much more relaxed and doesn't apply any copyleft.
- Integration
with T-Plan Professional allowing you to report results of
automated tests into the T-Plan test management framework.
- Additional
functionality and improved performance.
- Support and
access to hot bug fixes (custom builds),
- Higher priority
in bug fixing and requests for enhancements and new features.
For a complete summary of advantages of T-Plan
Robot Enterprise see the Versions page.
3. Project
& Community FAQs
Q:
What
do
you
mean
when
you talk about "community"?
There's no "development driving" community as you know it from Linux or
other large OSS projects. The legacy VNCRobot project was privately
developed and distributed for free with an occasional free support.
Many existing features and improvements were actually suggested by
active users who made an extra effort and provided feedback. Many
others also reported bugs and helped to test the bug fixes. T-Plan
Robot community for us means the network of users who actively use the
tool and give us something in return, whether it is a bug report,
feature suggestion or recommendation on the web or in public QA
forums (such as SQAForums.com).
As
we
addressed
the
wish
of many and decided to go open source, we hope
to see the community growing and contributing to the forums at
SourceForge.
Q: Is there any forum where I could ask questions
or provide feedback?
The T-Plan Robot forum is on SourceForge.
If you need more general help which spans accross mutiple tools,
automation and QA technologies, you may also take advantage of the Automated
Testing forum at SQAForums.com (Disclaimer: We do not operate this
forum. We just occasionally contribute to the automation discussions).
Q:
Where
do
I
find
the
source code?
The latest source code is available on SourceForge.
Source
code
of
a
particular
product
release is also shipped as part of the binary
release in form of a ZIP file.
Q:
Are there any
alternatives or other projects similar to this one?
To our knowledge there is no other open source, platform independent
and
multi purpose testing tool like this one. Eggplant from Testplant comes
close in terms of using the RFB protocol for testing but it suffers
from many limitations and disadvantages such as commercial/closed
source model, platform dependency of certain components, no support of
an industry standard programming language, limited customization
capabilities and hard dependency on the RFB protocol. This makes T-Plan
Robot unique and it often becomes a preferred
choice of black box testing tool, especially on Linux/Unix and mobile
platforms where universal black box GUI test tools are fairly scarce.
Q:
How can I
contribute to the project?
Participate in the forums on SourceForge and help other users. If you
succeed to automate an unusual platform which is not yet listed in the
Release Notes, let us know and we will document it for the others to
come (show me where).
Develop
new
features
in
form
of
plugins and put them to our download site for the benefit of
the whole community (guide).
If
you are bilingual, translate the message file
to your language and publish it (guide).
Suggest
improvements,
new
features
and
ideas.
Combine the code with other GPL projects to deliver new
functionality and eventual new plugins. If you see an interesting
functionality in another
product that you would like to see in the tool, drop us a note and we
will review it. If you are experienced in Linux distributions, help us
to create Linux packages and integrate them to existing distributions.
If you have practical experience wit the plugin interface to NetBeans
and Eclipse, help us to plug the tool into these environments to make
writing of Java test scripts easy for those 6 million Java developers
out there.
Q:
Can
I
contribute
code
to
the
project?
T-Plan
Robot is not a typical community driven project where the source code
is open to public contributions. As any such modification would be
under
copyright of the contributing person, we would be not able to dual
license the code and it would effectively break our business. That's
why we had to draw a clear line of code ownership, and we did so
through
design and implementation of the Plugin interface and public Java APIs.
That's why you may contribute new features or improved existing
features in form
of plugins. If you wish to extend or replace functionality which
doesn't have an exposed plugin interface, get in touch and we will
expose it provided that the architecture and resources allow it. Read
more about plugins in the Plugin FAQ
below.
4. Plugin FAQs
Q: Where do I find
additional feature plugins?
Check out our Plugins page. We
will
provide there plugins which were developed by us
and we will also link plugins provided by the community and submitted
to us.
Q:
I
have
downloaded
a
plugin
JAR
file. Do I have to add it to the Java class path?
No. Path to the plugin JAR file or class path gets saved to the user
plugin configuration XML file. The Plugin Manager will load it
dynamically upon the application start. If you however move the tool
into
another folder, you need to either add the plugin JAR to the Java class
path or plug it in again.
Q:
Can
I
uninstall
a
built-in
plugin?
No. So called "built-in plugins"
represent core classes from the product JAR binaries and they cannot be
uninstalled. They can be however disabled through installation of a
plugin which implements the same functionality.
Q:
How
do
I
add
a
new
feature or replace an existing one with my own Java code?
Refer to the T-Plan Robot Plugin
Framework document. It
is linked to the Java
code documentation.
Q:
I want to translate the software messages and
publish it. How do I do it?
Follow the steps in the localization
guide. If you want us to
endorse your translated message file, send us an E-mail and
we will link it after a review to our download site and SourceForge
docs.
Q:
How
do
I
install
a
translated
message file?
Just copy it to the folder where you installed the tool to. It will
pick it up after restart and make it available in the Language drop
down of the Login Dialog.
Q:
I
want
to
write
a
plugin
and publish it. How do I do it?
Follow steps described in the Plugin
Framework
manual. If you wish to make the plugin public to the
community, we
suggest you to create a SourceForge project. If you want us to endorse
your plugin, send us an E-mail
and
we will link it to our site.
Q:
Is
there
any
advantage
in
publishing
link to my plugin on your download site?
Yes, many. It will be the place where most community members will go
and you are likely to get a lot of attention and credit there. There
might be also business opportunities. If you for example happen to
develop a plugin which one of our paying customers likes, we may get in
touch with you to get a commercial license. Last but not least should
there be a need to change one of the existing interfaces, we will check
whether it would break any of the published plugins and we will make an
effort either to fix it or work with the plugin owners to resolve it.
5. Technical
FAQs
Q: How do I
verify result of a test script?
Verification methods include (1) image comparison, (2) image updates,
(3) bell character, (4) text transfer and (5) local system commands.
The most often used method is image
comparison.
The point is to save an image of the tested application, or better its
small part, such as an icon, button or any unique component. The use
one of the Compareto,
Screenshot
or Waitfor
match/mismatch
commands to verify that the remote desktop contains the image.
For a quick check you may just wait for a screen update. When an application
window displays, it causes part of the display to refresh (update). The
Waitfor
update
command may be used to hold the script execution until the desktop
refreshes. An action may be specified to be invoked when the refresh
doesn't come and the application window is likely to fail to open. Note
that screen update is supported just by clients which actively refresh
displays, such as for example RFB (VNC) or RDP.
Some clients (namely RFB/VNC) are able to detect when the desktop
machine rings a bell
(beeps). It is usually caused by the Bell character (ASCII 0x07)
printed out to the console. This feature may be effectively used on
Linux/Unix systems to detect that an OS command being executed in a
console window finished. See the Waitfor
bell command for more information and its example section for
sample
code.
Be aware that availability of bell events is also limited to certain
protocols such as RFB (VNC), and it may not be supported by other
clients.
Text transfer
from the server
to the client may be used to verify results where text plays a role.
See one of the following FAQ for more information.
Last but not least you may employ the Exec
command to execute an OS command
from a test script. It becomes handy especially on Linux/Unix systems
where there are many useful commands allowing you to perform string or
file comparison or verify status of the remote machine through
different technologies.
Q:
Does
the
tool
support
file
transfers
between
the client and server?
Current implementation of the standard RFB (VNC) client however doesn't
have
this functionality. File transfers as you see them in UltraVNC and
TightVNC are proprietary features of these particular products which
have no support in the official RFB protocol. There is no written
specification and I would have to review the C code to find out how it
works in order to implement it in Java. It may be subject to
unannounced changes which makes it a maintenance nightmare. It would
also introduce dependency on a particular VNC server which is against
the philosophy of this project.
For all these reasons we decided not to implement the VNC file transfer
at the moment. If there's enough demand and someone is willing to pay
for the development or someone from the community implements it, it may
be delivered as a plugin in the future. As a workaround you may
automate the remote desktop to save files to a shared location visible
by both the server or client (for example, NFS) or employ FTP commands
on the remote desktop.
Q:
How
do
I
get
text
displayed
on the remote desktop?
In general you may use clipboard of the remote system. Simply select
(highlight) the text and invoke the 'Copy' or 'Cut' action (Ctrl+C or
Ctrl+X on most systems). The text should get transferred to the client
and it will be available to the script in form of a variable. See the Var
command specification,
especially the _SERVER_CLIPBOARD_CONTENT implicit variable.
Availability of the text transfer and its parameters and limitations
depend on the client used. The RFB one can not transfer other than
Latin-1 characters (ISO 8859-1) and it requires additional utility to
run on the server. See the next question for more.
Q: I copied text on the
remote RFB desktop.
The content of the remote clipboard however didn't make it to the
client. How do I make it work?
The "vncconfig" utility has to run on your server to make
the clipboard transfer working. As some VNC servers do not distribute
it (for example, TightVNC), the feature may be switched off. If you
plan on using clipboard changes to transfer text from server to client,
get a VNC server which has it, such as UltraVNC.
On Linux/Unix, the autocutsel
utility can be used instead of vncconfig. It must be executing on the
server as "autocutsel -s PRIMARY". If you are running
Debian or Ubuntu, you may find the tool in the package repository. Be
however aware that client text transfer limitations apply both for
vncconfig and autocutsel. For example, the RFB client can transfer only
characters from the Latin-1 (ISO8859-1) character set. The Java client
(v2.0 enterprise feature) is limited by characters which can typed on
the local machine keyboard.
Q:
How
can
I
get
access
to
the components of the tested application like buttons, drop
downs, etc?
You can't. This is a general image tool which
sees just an image
of the desktop and it doesn't recognize applications and windows which
run there. If you need access to application windows and components,
you have to use another tool. There are specialized tools for Java,
C/C++ and web/browser applications.
Q:
Can
I
write
libraries
with
test
routines and share them among multiple scripts?
Yes. The Include
and Run
commands in conjunction with global
variables and procedures
are designed exactly for this purpose. Version 2.2 of the Enterprise
product in addition allows to write parametrized routines in Java and
call them from regular scripts. See the Interoperability of test
scripts and Java code tutorial topic.
Q:
The
application
window
I
am
testing
gets displayed in a different location each time I
start it. How do I automate it?
There are many approaches. I suggest to stay away from mouse clicking
and handle everything through keyboard. You may navigate to any window
component using the Tab and Shift+Tab keys while Enter or Space can be
then used to press buttons or follow links. There are a few other
options:
- Use your OS specific key to maximize the window
and work with it in full screen size.
- Many systems allow to move windows through the
keyboard. For example, on Linux/GNOME it is Alt+F7 followed by arrow
keys. Use it to move the window to one of the corners and automate at
this location.
- Employ a utility which can move the window to
the specified location and/or remember window size and position, such
as WinSize2 on
Windows.
- Use image search to locate the window on the
screen, and specify coordinates of all location-depending commands as
relative (
x:{_SEARCH_X}+[relativeX],y:{_SEARCH_Y}+[relativeY]).
Q:
Which
version
does
the
RFB
client
support?
The client supports RFB version 3.3. It should
work fine with most VNC products.
Q: Can I use the tool with RDP desktop (Windows Terminal Services)?
There is no direct RDP support at the moment. A few users reported that
they had succeeded to make the tool work with Citrix/ICA using the RDP2VNC proxy. We are
considering to provide an RDP client in one of the future versions. The
client API is otherwise open to plugins for those who wish to implement
their own protocol support or plug in functionality of other open
source projects.
Q:
Does
the
tool
work
with
Apple
Remote Desktop (ARD)?
Yes, because Apple uses RFB protocol for the
desktop access. Note that there were bugs up to 1.3.14 causing the tool
to display incorrect colors. Version 1.3.15 and higher should work
fine.
Q:
Does the tool
support MSRC4/NTLM RFB authentication?
No. Reasons are the same as in case of file
transfers. MSRC4/NTLM are UltraVNC proprietary features which are not
specified in RFB protocol.
Q: Can I use the tool to
automate a mobile phone?
Yes, provided that there's a VNC server or
any other supported desktop technology available for the mobile
platform. Windows mobile phones may take advantage of PocketVNC (a workaround described
in Release Notes
is needed). For
testing with VNCRobot 1.3 you will also need to set up your mobile to
have a
public IP address (instructions).
This
is
not
required
for
T-Plan Robot v2.0 which supports reverse
server-to-client
connection through the RFB listen mode.
Q: Can I load test
data from a file or database to the script?
Yes, in Java test scripts. There are many free
Java libraries allowing you to access data from various sources, such
as relational DB (via JDBC), Excel sheets and CSV files (via Java Excel
API, JDBC Excel driver or jXLS) or XML (for example using JAXP or SAX
parser). Text files or even CSVs can be also loaded easily through the
core Java I/O functionality. Examples are provided in the tutorial.
The scripting language has otherwise very limited ways to load test
data and there are just clumsy workarounds. You may for example print
out & process the data file into the console using the Exec
command and then
access the output in the script (contents of the _EXEC_OUTPUT
variable). The for statement can be then used to iterate
over a set of string constants (words).
Q:
Can
I
record
video
from
the
test sessions?
There's no direct support in the tool at the moment. You may however
set up an external tool for RFB (VNC) session recording. See an example
of how
to convert VNC sessions to
Flash using pyvnc2swf.
Q: Can I record test
scripts directly to Java?
Not directly. Use the Record feature to generate a script in the
scripting language and then export (convert) it to Java.
Q:
Is
there
any
way
to
convert
a Java test script back to the proprietary language?
Not really. As Java syntax is much more complicated, not every
statement in Java can be translated into the proprietary scripting
language. The Java Test Script API in fact calls handlers of the
individual commands, you can however execute a test script and save the
resulting commands to a script. This way is however very limited and
covers only method calls which are compatible with the proprietary
scripting language commands.
Q:
Can
I
customize
the
test
script
converter?
Yes. As the converter implements the Plugin
interface, you may customize it and plug it back to the tool. You can
also use methods
of the converter interface to modify behavior of the existing
implementation in a Java program.
Q: I have a
test script which executes well against a VNC server. Can I execute it
using another client/protocol, for example the Java native client?
In general yes.
You
should be however aware that each client applies certain protocol
specific limitations which may impact compatibility, such as:
- Client
capabilities. T-Plan Robot is an open architecture and allows to
plug in even clients which are not capable of all operations typical
for desktop technologies. For example, some servers (such as the Java
one) do not actively notify client of desktop image changes. The client
is then forced to poll the image at scheduled intervals which makes it
impossible to use the Waitfor update command. Such compatibility
failures are checked during both script compilation (doesn't apply to
Java test scripts; it also must be clear which client will be used) as
well as script execution. Any lack of client capability will be
reported as script syntax error.
- Ability to
transfer certain characters. For example, the Java client allows
to transfer any characters supported by the local client keyboard. The
VNC client on the other hand can transfer only Latin-1 characters which
is a limitation of the RFB protocol. Hence if you write a test scripts
which types Russian characters on the remote desktop, it may work with
the Java client provided that both the client and server use a Russian
keyboard, but it will for sure not work with VNC. These differences may
result in failures of Press, Type and TypeLine commands as well as
transfers of text through the system clipboard during script executions
(no syntax error is reported).
See documentation of
the clients and the Waitfor
client
overview
table for more information
on individual limitations.
Q:
Is
T-Plan
Robot
v2
IPv6
enabled?
No. Though Java claims to support IPv6
transparently without any application code change, we have never tested
it. We are however considering IPv6 support for one of the future
versions.
|
|
T-PLAN
ROBOT FAQ