You are here: Chapter 6: Executing Test Scripts > Program Level Execution and Load Testing

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.Threadand 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.
import com.tplan.robot.ApplicationSupport;
                        import com.tplan.robot.AutomatedRunnable;
* (C)T-PlanLimited,
publicclass TwoTasks {     publicstaticvoid 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. T-Plan Robot can measure the application response time, and it is an excellent engine for the simulation of a number of users accessing the tested application or service in order to generate load. When this model is combined with another tool for performance measuring, it may represent a very cost effective solution.

In addition to supporting the automation of the local desktop, T-Plan Robot utilises the RFB (VNC) technology, and in this mode 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 so efficient. In these instances it would be better to employ T-Plan Robot ability to automate the local desktop.

T-Plan Robot does provide tools to measure application response time, and produce performance results. As automation is performed on the desktop level, such 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: See an example of the Load Testing review example.


12 December 2014

Copyright © T-Plan Ltd.

Version 1.0