As the tutorial is full of examples which are best practiced on a live
system, one of the very first tasks will be to set up your own test
environment. Before we proceed to installation instructions you have to
select one of the supported configurations. This doesn't apply to
scenarios of
static image testing where
no special configuration is
required.
T-Plan Robot acts as a
client of
remote desktop software and as such it is limited by
requirements of the particular remote access technology. As it
primarily relies on the RFB protocol, it can automate
any configuration supported by VNC
. VNC software typically operates in a client-server environment where
the client and server are physically two different machines or at least
two different OS instances. That's why we distinguish two systems in
each supported configuration:
) is an OS desktop (
VNC server)
instance which runs the
Application
Under Test (AUT).There are basically three possible configurations:
 | T-Plan Robot Enterprise version 3.2 introduced support of automation of applications displayed on the local desktop. This means that Robot and one or more Applications Under Test (AUT) run on the same local desktop. The automation is of course not limited to the AUT, and it may perform any desktop action that a regular user can do. Advantages:
|
Please Note: Test script relying on the Local Desktop connection can not be started remotely through a terminal such as telnet or rsh. Use the VNC Server connection for such scenarios instead.
For more information please view our release note topic: Local Desktop Automation.
 | Configurations with a single machine/OS with multiple desktop instances are supported just by Linux/Unix which allow to run multiple VNC servers 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. T-Plan Robot typically (but not necessarily) runs on the default system desktop (as is displayed in the picture) and automates a local VNC server instance with the AUT. An example of T-Plan Robot connected to a local VNC server on Ubuntu Linux has been shown in the previous topic. This configuration is fairly easy to set up:
|
This configuration is not supported by MS Windows where the VNC server attaches to the default system desktop and as such it may run just once. If you make an attempt to connect T-Plan Robot Enterprise (or any other VNC client in general) to a local VNC server within a single Windows system, you will experience so called infinite mirroring effect (see example) which will render the client unusable.
 | 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"). You
may have noticed
an
example of Windows Vista hosting a Windows XP
system in VirtualBox in the previous topic. The
hosting and hosted systems may be any combination of OSes supported by
the particular virtualization technology.
The hosting system typically runs T-Plan Robot and plays role of the client system. Though the tool may also run on another dedicated VM instance, this configuration is not recommended with regard to a number of environment specific issues reported by T-Plan Robot users. The hosted system serves as the SUT and runs a VNC server with the AUT. Configuration instructions:
|
Be aware that the client and server roles can not be reversed and the
VM can not remote control (and automate) the hosted system. Any attempt
to do so would result in the infinite mirroring effect discussed above.
If your AUT
is too complicated to install into a VM, use a dual machine environment
instead.
The same OS factors discussed in the previous configuration apply. If you hosted system is Linux or Unix, you may start multiple VNC servers on the VM to get a number of test environments (desktops) as long as their ports are made visible to the hosted system. If the hosted system is MS Windows, the VM may serve just as one single test environment.
|
This
scenario presumes that you have a
stable
dedicated test server which serves as SUT. This configuration is
recommended for automation production
scenarios. As the 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 server 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 and thus
a single machine scenario can not be used.
Configuration steps are as follows:
|
||
|
Supports testing on:
All functionality common to the desktop tools usage is supported. E.g. Record & Playback, OCR etc. Platform independence (Java). T-Plan Robot runs on, and automates all major systems, such as Windows, Mac, Linux, Unix, Solaris, and mobile platforms such as Android, iPhone, Windows Mobile, Windows CE, Symbian. |
Analogically with the previous configurations, a Linux/Unix SUT may
provide multiple test environments while a MS Windows server just a
single one.
The SUT is not limited to computers and it may be in general any device running an RFB 3.3 compatible VNC server, for example a mobile phone.
See for example the screen shots of:
...in the previous topic.
| 12 December 2014 |
Copyright © T-Plan Ltd. |
Version 1.0 |
