Applies to: TestComplete 8.10
This article explains what distributed test are, what they are applied for, and how you can perform distributed testing using TestComplete.
The article contains the following sections:
Introduction
Distributed testing and non-distributed testing represent different approaches to classifying testing methods. Non-distributed tests are those that run on a single computer and normally do not interact with other computers.
Distributed tests are different. They consist of two or more parts performed on separate computers that interact with each other. The crucial points of distributed tests are synchronization, administration, and configuration. For better analysis of results, statistics on running all test parts should be accumulated in a single common result set, while you should still keep the ability to analyze individual results of the needed test part.
Distributed testing is applied for testing web sites and server applications when they are working with multiple clients simultaneously. The applications of this type are called distributed applications. Testing a distributed application involves testing its client and server parts. You can always test them separately, but distributed testing gives you a way to test them all together. For example, a test makes a client instance send requests to the server, at the same time, due to several clients working together, you can assess the server’s performance.
TestComplete supports distributed testing and provides features for starting tests on remote computers, exchanging data between projects during the test run, and synchronizing test projects.
Distributed Testing in TestComplete
To organize a distributed test, two types of projects are used: the master project and slave projects.
The master project manages distributed testing and holds all information about it. Distributed testing can involve only one master project.
Slave projects contain tests to be run on particular remote computers as part of distributed testing. The master project can manage any number of slave projects.

Slave projects must be stored at the locations available from the remote computers on which they are to be run. You can store slave projects in a shared network folder or on the remote computers where they will be run.
TestComplete includes a special feature that allows copying slave projects from the master computer to the remote computers where they will be run. This way, you can create slave projects on the master computer and then copy them to the required remote computers without leaving the TestComplete IDE. For more information on copying slave projects, see below.
Each project, both master and slave, involved in distributed testing must have a Network Suite project item. This item includes elements that allow you to create, manage, and run tests on remote workstations.

For example, Network Suite’s Host elements let you manage a list of computers involved in distributed testing.
Task elements specify what project or project suite should be run on which host.
Job elements are collections of tasks. When you are running a job, all its tasks are run concurrently.
To make projects participating in distributed testing interact with each other and to run them in a certain order, you can synchronize them by using Network Suite’s Synchronization Point elements or other features for test synchronization. For detailed information, see the Synchronizing Distributed Tests article.
TestComplete provides several scripting objects that allow managing distributed tests from scripts and keyword tests. Note that these scripting objects can be used only in a master project.
Each Network Suite element has an appropriate scripting object: NetworkSuite, Host, Job, or Task. These objects have properties allowing you to specify Network Suite elements’ properties from tests. The Task, Job, and NetworkSuite objects also have the Run method. This method initiates the execution of the task, job, or Network Suite.
TestComplete also includes special network suite events occurring during distributed testing, for example, Network Suite, job, or task state changing. You can create handlers for these events.
Using scripting objects and Network Suite events allows the master project to implement more complex executing logic.
Let’s see how to create a simple distributed test that includes only two slave computers that execute simple slave projects.
Creating a Distributed Test
Suppose, we have a physical testing lab or a virtual testing lab with three computers: MasterComputer, SlaveComputer1, and SlaveComputer2. MasterComputer will hold a project that manages the distributed test. SlaveComputer1 and SlaveComputer2 are remote computers on which the tests will be run.
Projects to be run on SlaveComputer1, Project1.mds and Project2.mds, are stored on the master computer. They are to be copied to SlaveComputer1 before the distributed test starts.
Projects to be run on SlaveComputer2 are stored directly on the remote computer at C:\MyDocuments\Project3\Project.mds and C:\TestComplete\Projects\Project4\Project4.mds.
In our sample, we will explain how to prepare TestComplete projects, how to copy slave projects from the master computer to the remote computers, how to create jobs and tasks and modify their properties, how to check whether the test will start successfully, and how to analyze the results.
Preparing TestComplete Projects for Distributed Testing
Now, we will prepare our TestComplete projects that will take part in distributed testing.
First, we will create a new TestComplete project on MasterComputer. This project will be the master project that manages the distributed test.
To create a new project, follow the steps below:
- If TestComplete is not running yet, launch it now. Once it is running, select New | New Project from the TestComplete File menu. This will call the Create New Project wizard.

To be able to participate in the distributed test, the project must contain the NetworkSuite item. To add this item to the project, follow these steps:
- Right-click the project node in the Project Explorer panel and select Add | New Item from the context menu. The Create Project Item dialog will appear.

- In the dialog, select Network Suite and click OK.
TestComplete will add the NetworkSuite item to the project and display it in the Project Explorer panel:

Creating the Distributed Testing Hosts List
The NetworkSuite item of the master project contains the Hosts Collection item that lists computers on which individual testing tasks will be run. Let’s add two computers to the network suite’s list of hosts. To add a new host to the project, do the following:
- Right-click the NetworkSuite | Hosts project item in the Project Explorer panel and select Add | New Item from the context menu.
- Specify the name for the new host, SlaveComputer1, in the subsequent dialog and click OK.

- Double-click the Hosts node of the NetworkSuite project item. TestComplete will show the Hosts editor in the Workspace panel.
- Switch to the Hosts editor, click the ellipsis button in the Address column for the new host, and select the needed computer from the dialog.

- Specify the User name, Domain name, and Password of the account under which distributed testing will be performed on the remote computer. This account information is required for opening user sessions on remote computers.

The same way, add the second host to the project. Call it SlaveComputer2. Specify its Address and login information.
The Hosts editor looks like this:

You can reboot hosts from the Hosts editor in the master project. To reboot a host, select it in the Hosts editor and use the Reboot command available from the context menu and from the Hosts editor toolbar.

Copying Slave Projects
Before distributed testing starts, the slave projects, SlaveProject1.mds and SlaveProject2.mds, stored on the master computer should be copied to SlaveComputer1 where they will be run.
You can use the TestComplete special feature to copy them to the remote computer. To copy the slave projects, do the following:
- Open the Hosts editor in the master project.
- From the list of hosts, select the SlaveComputer1 host.
- In the Source path column, specify the path to the folder on the master computer holding the slave projects you want to copy.
- In the Base path column specify the C:\Projects string. It is a destination folder on SlaveComputer1 to which we will copy the projects. We will also use this path as a base path for the tasks to be run.
- Use the
Copy Project to Slave command to copy the projects.

The projects are copied to the C:\Projects folder on SlaveComputer1.
Creating Distributed Testing Jobs and Tasks
Now, we can create jobs and tasks in the master project.
We will create two jobs: Job1 and Job2. During the test run, the jobs will be executed one after the other.
Each of the created jobs will include two tasks. All tasks of a job will be running simultaneously during the test. Suppose, Job1 will run Project1 on SlaveComputer1 (Task1) and Project3 on SlaveComputer2 (Task2), and Job2 will run Project2 on SlaveComputer1 (Task3) and Project4 on SlaveComputer2 (Task4).

To create a new job, right-click the NetworkSuite | Jobs project item in the Project Explorer panel, select Add | New Item from the context menu, assign an appropriate name to the job, Job1, in the resulting dialog, and click OK.

The same way, create another job and call it Job2.
The created jobs are listed in the Jobs editor. To view this editor, right-click the NetworkSuite | Jobs node in the Project Explorer panel and then select Edit from the context menu:

The jobs are executed in the order they are listed in the Jobs editor.
The execution of jobs means that the test engine runs tasks added to this job. The tasks within a job are started concurrently. To add a new task to a job, right-click the job in the Project Explorer panel, select Add | New Item from the context menu, assign an appropriate name to the task in the ensuing dialog, and click OK.

Create two tasks in Job1 and call them Task1 and Task2.
Then, create two tasks in Job2 and call them Task3 and Task4.
Now, let’s modify the tasks’ properties. To do this, follow the steps below:

- Repeat these steps to set the following properties of the other tasks:
| Tasks\Properties | Host | Project file name |
| Task2 | SlaveComputer2 | C:\My Documents\Project3\Project3.mds |
| Task3 | SlaveComputer1 | \Project2\Project2.mds |
| Task4 | SlaveComputer2 | C:\TestComplete\Projects\Project4\Project4.mds |
Besides these properties, you can also set other properties in the Tasks editor:
- Action after run - Specifies whether the remote host will be shut down, rebooted, or left as it is after the task run is completed and TestComplete is closed on the remote host.
- Remote application - Specifies which testing application, TestComplete or TestExecute, will be used on the remote workstation.
- Copy remote log - Specifies whether the task logs should be copied from the remote computer to the master computer.
- Tag - Contains an arbitrary string associated with the task.
- Use Previous instance - Specifies whether the previous running instance of TestComplete will be closed on the remote computer or used for the task execution.
Running the Distributed Test
Before we run the distributed test, we can see whether the test will start successfully. To do this, right-click the NetworkSuite node in the Project Explorer panel and select
Verify from the context menu.
For each enabled task of enabled jobs, TestComplete will check whether the host computers are available, whether TestComplete or TestExecute is installed and can be launched on these computes, whether the project specified by the task’s Project file name property exists, and other necessary actions.
When you are verifying (or running) NetworkSuite, TestComplete opens user sessions on remote computers using the account information specified in the Hosts editor.
If the verification is successful, you can run the distributed test.
You can run a whole network suite or its separate jobs and tasks. They can be run from the TestComplete UI or from keyword tests or scripts using special keyword-test operations or special scripting methods and objects. Running distributed tests from keyword tests and scripts allows you to implement more complex test logic. For example, the master project can check the state of a job or task during the run and perform specific actions according to the result of the check.
In our case, we will run the distributed test from the TestComplete UI. To do this, right-click the NetworkSuite project item in the master project and select Run from the context menu.

During the run, the Run State page of the NetworkSuite editor will display the information about the network suite, job, and task execution. This page also displays the remote desktop windows of the slave hosts allowing you to observe the test run on the remote computers directly from the master project.

TestComplete will run the network suite until all of its enabled jobs are completed. Each job, in its turn, runs until all of its enabled tasks are completed.
Each job of the network suite coincides with the previous job and will run only after the previous job has finished. Thus, TestComplete will first execute the tasks of Job1, wait for the end of their execution, and then, run the tasks of Job2. Task1 and Task2 will be executed simultaneously as well as Task3 and Task4.
Viewing Results
After the distributed test is over, we can analyze its results displayed in the master project test log:

The distributed test log includes the master project log and the logs of the slave projects executed on the remote computers.
The master project log is stored on the master computer. Depending on the Copy remote log property, the slave project logs can be copied to the master computer and stored in the master project log folder, or they can be stored on the remote computers, where the slave projects were executed, and uploaded to the master computer when you require them.
The Test Items panel displays the hierarchical structure of the distributed test log. The top-most item corresponds to the master project log. Its child items represent the structure of the executed jobs and tasks. The remote test logs to which the tasks refer are displayed as the child nodes of the task nodes:

To view the remote test log content from the master project, select the corresponding node in the Test Items panel:

Conclusion
This introduction to distributed testing explains how TestComplete supports distributed testing and how you can test client-server applications. We hope this information will help you perform your distributed testing. For more information about distributed testing, see our Distributed Testing video. If you are interested in trying TestComplete for free, download and try it today.