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

Program level execution and load testing

By program level execution we understand running of automated process(es) from a custom Java program or a third party Java application. As T-Plan Robot's role is in this scenario reduced to a Java library, this mode is supported on the level of Java APIs only and there are no GUI or CLI features supporting development of the related Java code. Use a third party tool (an IDE) such as NetBeans or Eclipse for this purpose. 

T-Plan Robot Enterprise supports program level execution through the AutomatedRunnable and ApplicationSupport Java interfaces. The API allows to create and start either a single process (effectively simulating a single automatic execution in the GUI or CLI mode) or an unlimited number of processes (executed as Java threads) running in CLI mode (until the system resources are exhausted). Each such a process seamlessly accepts the same set of options as the CLI and executes one test script against one test environment (desktop) at a time.

Program level execution consists of three steps:
  1. Instantiate the ApplicationSupport class. This initializes the necessary framework and shared services.
  2. Use the instance to create an AutomatedRunnable. Test script name (file) as well as other options compatible with the CLI specification are accepted through one of the createAutomatedRunnable() method arguments.
  3. Either call the run() method of the runnable (single process scenario) or encapsulate it in a java.lang.Thread and start it as a thread (multi-threaded scenario).
The following example starts two automated threads. The first one connects to a VNC server running on port 5900 of machine called testmachine1 and executes the C:\TestScripts\test1.tpr test script. The other one connects to a VNC server running on port 5901 of machine called testmachine2 and executes the C:\TestScripts\test2.tpr test script. Note that both the threads will be executed simultaneously and the program will exit when the last thread finishes.

TwoTasks.java
import com.tplan.robot.ApplicationSupport;
import com.tplan.robot.AutomatedRunnable;

/**
* Example of two simultaneous test processes started at the Java code level.
* (C) T-Plan Limited, http://www.t-plan.com
*/
public class TwoTasks {

public static void main(String[] argv) {

// Step 1: Instantiate the ApplicationSupport class.
ApplicationSupport robot = new ApplicationSupport();

// Step 2: Create AutomatedRunnable instances and initialize them with CLI-compatible options.
String args1[] = {"-c", "rfb://testmachine1:5900", "-p", "welcome", "-n", "-r", "C:\\TestScripts\\test1.tpr"};
AutomatedRunnable runnable1 = robot.createAutomatedRunnable("cli-1", args1, System.out, false);

String args2[] = {"-c", "rfb://testmachine2:5901", "-p", "welcome", "-n", "-r", "C:\\TestScripts\\test2.tpr"};
AutomatedRunnable runnable2 = robot.createAutomatedRunnable("cli-2", args2, System.out, false);

// Step 3: Encapsulate the runnables with Thread and start them.
Thread t1 = new Thread(runnable1);
t1.start();

Thread t2 = new Thread(runnable2);
t2.start();
}
}

This multi-threaded approach can be also employed in load testing scenarios. Though T-Plan Robot at present doesn't have precise tools to measure the application response time, it may simulate a number of users accessing the tested application or service in order to generate load. When this model is combined with another more expensive tool licensed used exclusively for performance measuring, it may represent a cost effective solution.

As T-Plan Robot currently relies on the RFB (VNC) technology, each thread must automate its own VNC desktop server instance. Such an approach is very efficient with Unix or Linux where a single platform (OS) may run as many VNC servers as the system resources allow (such as RAM and CPU). This scenario may be exploited for testing of applications running on Unix/Linux and/or for web application testing where the Unix/Linux machine hosts web browser instances. As MS Windows systems may run just one VNC server per OS, load testing on these environments is not that efficient. This may change with the planned RDP support which will allow to take advantage of Windows Terminal Services.

Future versions of T-Plan Robot are planned to provide tools to measure application response time and produce performance results. As automation is performed on the desktop level, such a testing will have an extra added value because it will reflect the true time elapsed between the user request and result. This is in contrast with many other load performance testing tools which typically focus on measuring of one critical phase of the request-response cycle (for example database or web/application server response time). Such results however usually do not correspond with the end user experience where the time is further on affected by the environment.

TIP: To see an example of load testing review example #5 of the legacy How To Use VNCRobot document.