T-Plan Robot Documents > T-Plan Robot Enterprise v2 Tutorial

Supported configurations

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:
  • The Client System runs Java and T-Plan Robot Enterprise.
  • The System Under Test (SUT) is an OS desktop (VNC server) instance which runs the Application Under Test (AUT). This system is also sometimes referred to as test environment, especially when the SUT is a separate machine.
There are basically three possible configurations:
  1. Single OS with multiple desktops.
  2. Single machine with multiple OS instances (VirtualBox or VMware scenarios).
  3. Dual machine environment (classic client-server configurations).

1. Single OS with multiple desktops

Single machine environments with one OS instanceConfigurations 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:
  1.   Install any supported VNC server and start it.
  2.   Install Java JDK 1.6 and T-Plan Robot Enterprise.
  3.   Start T-Plan Robot Enterprise and connect to the VNC server (typically localhost:5901).
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 draw the client unusable.


2. Single machine with multiple OS instances

Single machine with multiple OS instancesThis 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:
  1. Install VirtualBox or VMware.
  2. Create a VM and install the hosted OS in there.
  3. Install any supported VNC server on the hosted system and start it.
  4. Configure the VM to make the VNC port visible from the hosting system.
  5. Install the AUT on the hosted system.
  6. Install Java JDK 1.6 and T-Plan Robot Enterprise on the hosting system.
  7. Start T-Plan Robot Enterprise and connect to the VNC server on the hosted system.
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.

3. Dual machine environment

Classic client-server configurationThis 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 quite obvious:
  1. Install any supported VNC server on the SUT and start it.
  2. Install the AUT on the SUT.
  3. Install Java JDK 1.6 and T-Plan Robot Enterprise on the client system.
  4. Start T-Plan Robot Enterprise and connect to the VNC server on SUT.
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 cell phone with Windows Mobile OS and PocketVNC. See for example the screen shot of HTC mobile automated from Ubuntu Linux in the previous topic.