Concurrency

For Silk Test Classic, concurrent processing means that agents on a specified set of machines drive the associated applications simultaneously. To accomplish this, the host machine interleaves execution of the sets of code assigned to each machine. This means that when you are executing identical tests on several machines, each machine can be in the process of executing the same operation. For example, select the Edit.FindChange menu item.

At the end of a set of concurrent operations, you will frequently want to synchronize the machines so that you know that all are ready and waiting before you submit the next operation. You can do this easily with 4Test.

There are several reasons for executing test cases concurrently:

You want to save testing time by running your functional tests for all the different platforms at the same time and by logging the results centrally, on the host machine.
You are testing cross-network operations.
You need to place a multi-user load on the server.
You are testing the application’s handling of concurrent access to the same database record on the server.

To accomplish testing concurrent database accesses, you simply set all the machines to be ready to make the access and then you synchronize. When all the machines are ready, you execute the operation that commits the access operation—for example, clicking OK. Consider the following example:

// [A] Execute 6 operations on all machines concurrently
for each sMachine in lsMachine
  spawn
    SixOpsFunction (sMachine)
rendezvous                        // Synchronize

// [B] Do one operation on each machine
for each sMachine in lsMachine
  spawn
    [sMachine]MessageBox.OK.Click () // One operation
rendezvous                             // Synchronize

In code fragment [A], the six operations defined by the function SixOpsFunction are executed simultaneously on all machines in a previously defined list of agent names. After the parallel operation, the script waits for all the machines to complete; on completion, they will present a message box, unless the application fails. In code fragment [B], the message box is dismissed. By putting the message dismissal operation into its own parallel statement block instead of adding it to the SixOpsFunction, you are able to synchronize and all machines click at almost the same instant.

In order to specify that a set of machines should execute concurrently, you use a 4Test command that starts concurrent threads. In the fragments above, the spawn statement starts a thread for each machine.