|The Network Suite functionality is deprecated. We don’t recommend using it for distributed testing. Consider using a CI/CD system for managing distributed tests. See Migrating Distributed Tests to CI/CD Systems for details. In case you need to run web tests on multiple environments in parallel, you can also try using your project’s Execution Plan.|
There are two types of projects that you use when organizing a network suite: master and slave. Each of these project types must contain the NetworkSuite item, since a project can participate in a distributed test only if this item is present.
About Master Projects
A master project is used to manage the distributed tests. A network suite can include only one master project. Master projects serve the following purposes:
Holds a list of hosts, on which individual test tasks will run.
Specifies the distributed test jobs and their components - tasks - to be run on the remote hosts.
Defines network suite variables.
Runs the network suite (as a test item, from keyword test or script).
Lets you monitor the network suite execution on the Run State page on the NetworkSuite editor.
The master project does not need scripts or other kind of tests, unless you want to execute them on the master computer. For example, the master project can contain a keyword test or script that performs some preliminary or final operations, handles certain network suite events and so on.
However, it is also possible that the master project participates in the distributed test along with slave projects and executes some tests on the master computer. Note that in this case, the master project should properly control the network suite execution and synchronize with the slave workstations (see Controlling Network Suites From Tests and Synchronizing Projects in Network Suites).
It is also possible that the master project contains tests to be run on remote computers. In this case, you can easily create a collection of tasks that will execute those tests on remote computers by using the Network Suite wizard. For information on how to use the wizard, see Network Suite Wizard.
About Slave Projects
Slave projects contain tests to be run on a particular host as a part of the distributed test. A network suite can include any number of slave projects.
Slave projects must be stored at locations accessible from the remote hosts they are intended to be run on. In other words, each slave project must reside either on the corresponding remote host or in a shared network folder (the latter is not recommended). You can configure the master project to automatically upload slave projects to the remote hosts or you can copy them manually from TestComplete IDE, from tests or by using file managers.
|Tip:||You can create slave projects while working on the master computer and then configure the master project to upload them on slave hosts automatically. For more information, see Copying Slave Projects to Remote Computers.|
Like the master project, each slave project must also contain the NetworkSuite item, however, its elements, except for synchronization points, are ignored.
For detailed information on how to organize master and slave projects in a network suite, see the Organizing Projects in Network Suites section in the Distributed Testing - Basic Concepts.
|Note:||During the distributed testing, TestComplete is run in silent mode on slave computers with the debugger turned off. This means that you cannot step through tests on slave computers or run them to the cursor. All breakpoints in slave projects are also ignored.
To debug a slave project, you can try to log in to the slave computer and run the slave project locally, not as part of a distributed test.
Distributed Testing - Basic Concepts
Distributed Testing - Requirements