|T-Plan Robot Enterprise 4.4.7 Doc
Local desktop automation presumes that Robot
automates the same system (desktop) the VNC server runs
on. This is typical for single OS solutions relying on MS
Windows or Mac OS X. When automation is in progress or
when a screen shot is being made the Robot GUI typically
hides to allow an undisturbed view of the automated
To set up this configuration:
An alternative to this configuration is the Local Desktop connection. It automates the the local desktop through the means of the local Java installation. No other component such as the VNC server is required. The disadvantage of this connection is that test scriptscan not be started remotely (from another PC or device) through a terminal such as telnet or rsh. Use the VNC Server instead.
|Configurations with a single machine/OS with
multiple desktop instances typical for Linux/Unix
which allow to run multiple VNC servers (desktops) on a
single system. Each server instance runs on its own port and
provides a standalone graphical desktop independent from the
default system one (the one you see on your screen). The
machine in this case serves both as the client system and
the SUT. Robot typically (but not necessarily) runs
on the default system desktop (as is displayed in the
picture) and connects to the VNC server(s).
The steps to configure:
This configuration takes advantage of virtualization technologies such as VirtualBox or VMware. In this scenario your default OS (called "hosting system" in virtualization terminology) runs a virtual machine (VM) with its own OS (called "hosted system"). There's an example of Windows Vista hosting a Windows XP system in VirtualBox on our web site. The hosting and hosted systems may be any combination of OSes supported by the particular virtualization technology.
This scenario presumes that
you have a stable
dedicated device (another PC, a mobile device, KVM
switch, POS machine etc.) runs the VNC server.
This configuration is recommended for automation
production scenarios. As the System Under Test (SUT) is
physically a separate machine it is easy to keep it in a
stable state, make necessary back ups or even set up a
routine to restore the system after each test cycle. As
the device is connected to the network it may also serve
as a test environment for multiple users (client
systems) over intranet or internet. This configuration
is also the only one possible when the SUT doesn't meet
requirements for running T-Plan Robot Enterprise
(systems not supported by Java SE) and thus a single
machine scenario can not be used. Configuration steps
are as follows:
Automation through the RFB protocol requires the System Under Test (SUT) to run a VNC server. A good overview of existing VNC products is on Wikipedia, both in the VNC and Comparison Of Remote Desktop Software topics. T-Plan Robot Enterprise should work fine with any VNC server which is RFB 3.x compatible.
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 in T-Plan Robot Enterprise. If you plan on using
clipboard changes to transfer text from server to client get a VNC
server which has it such as UltraVNC or RealVNC.
Desktop PC Platforms
Ctrl+Alt+Deleteuse the Keys tab situated in the top left corner of the T-Plan Robot Enterprise GUI.
'Properties'may be reproduced in scripts through the Press command as long as the VNC server supports them. The keys work fine on RealVNC and UltraVNC. Should you experience any issues make sure to switch on the scroll lock (this is a workaround described in UltraVNC forums). TightVNC 1.3.10 doesn't support the Windows specific keys but planned to support them in the 2.0 release.
vncserverin a terminal.
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. Other resources also mention xcutsel but we haven't tested it. Be aware the RFB client can transfer only characters from the Latin-1 (ISO8859-1) character set. This is limitation set by the RFB protocol and we can't do anything about it.
||all supported by server
||Tested by us on Linux & Windows. Be aware that Windows specific keys (Win, Properties) do not work on TightVNC server. The issue has been reported and it is likely to get fixed in TightVNC 1.3.11 or 2.0.|
||all supported by server
||Servers for portable devices (such
as mobile phones) distributed by RealVNC in form of OEM software are not
compatible and will not work with T-Plan Robot Enterprise.
RealVNC Free Edition relies on the standard RFB v3.x protocol and works out of the box.
RealVNC Personal Edition and RealVNC Enterprise Edition work on a proprietary enhancement of the RFB protocol coded as v4.x. T-Plan Robot Enterprise can work with these servers only in the 3.3 protocol compatibility mode which must be configured on the server side as follows:
1. On the Connections tab of the VNC server window change the settings:
Authentication - None
Encryption - None
Prompt VNC Server user to approve connections - Untick
2. On the Expert settings tab:
Protocol 3.3 - True
||all supported by server||Tested by us; reported to work by users.|
(Ubuntu feature compatible
by us. To enable the access:
|Apple Remote Desktop (ARD; Mac OS feature
compatible with VNC)
|10.4 PPC Mac
10.5 and higher (Intel Mac)
To make ARD work with T-Plan Robot Enterprise perform these steps on the Mac OS X desktop:
|Canon Remote Operator’s Software Kit||Reported
to work by users. Requires T-Plan Robot Enterprise version 3.1.1 or
higher to display the desktop in correct colors.
||Windows CE and Windows Mobile
us. Older versions such as PocketVNC v1.4.3 contain a bug
which breaks the desktop image transfer. There's a
As some devices disconnect regularly from the network to save battery, Robot may fail to connect with a message like "No route to server" or "Server not found". Pinging the device IP from the PC seems to wake it up in some cases. If it doesn't help, reconnect the device to the network (WiFi) and restart the VNC server to make sure that the connection is active and the device is visible in the local network.
NOTE: Pocket VNC in combination with T-Plan Robot Enterprise is one of the very few real black box GUI automation solutions for Windows mobile OS and application testing.
||Windows CE and Windows Mobile devices||Version
4.3 has been reported to work by users. As the server by
default uses an unusual 15-bit pixel format, the screen may
appear bluish. This can be fixed by making Robot to request
one of the standard pixel formats as follows:
||Symbian OS mobile devices
work by users.
As most keys on the device keyboard are mapped onto the PC numpad, commands automating typing on the device must use the "location=numpad" parameter. For example, to automate typing of a phone number of 123456789 use
||iOS (iPod, iPhone)
by us for basic functionality; reported to work by users.
Veency requires a jailbroken
device. There's no alternative because the iOS API
does not contain interfaces providing access to the
necessary features. You can install Veency from Cydia which
gets installed into the device during jailbreaking.
Should you experience freezing display image or other connection problems perform the following steps:
Veency v0.9.3381 and higher running on iOS 6 may disable
the keyboard and mouse input when the connection is not
protected by a password. When you experience this behavior
set up the password in the Veency UI and restart
For an iOS testing alternative see the iOS Mirror connection.
|VMLite VNC Server||Android||The VMLite VNC Server is a
commercial software available for a small fee from the
Google Play store. It can run both on on rooted and unrooted
For an Android testing alternative see the the Android Over ADB connection.