TETware White Paper
You are here: TETworks > White Papers > Synchronization
Synchronization - the key to distributed testing
A distributed test case consists of two or more parts, each processed on a different system, that interact with each other. It is this interaction between the different test case components that makes distributed testing different. All of the test cases processed on all of the different systems contribute towards a single, common, result. (more on distributed testing)
Ensuring that all of the tests happen on all of the systems in the correct order is the greatest challenge in distributed testing. To do this we synchronize the test cases. Synchronization is the key to distributed testing.
Synchronization of the test cases can either take place automatically, at system determined points, or the user can determine the points at which synchronization takes place for themselves.
If synchronization is to take place automatically the system will determine when it shall take place. This will be at points in the testing process such as:
User Defined Synchronization
If a user chooses to define synchronization themselves they must define the individual synch events. Each event is defined by a list of the systems that will participate in the event and a synch point number to be used.
Synchronization is co-operative so all the participating systems in a synch event must be prepared to synch with each other if the event it to succeed. For example, if system 1 expects to synchronize with system 2; then system 2 must also expect to synchronize with System 1.
The identification of the relevant Synch points is important. For example, consider this strategy for a file system test (see also Figure):
At each synchronization point each system votes as to whether or not the event should succeed. The event is only successful if it is unanimous, if everyone votes yes. If at least one system votes no, or abstains, the event fails.
Synchronization has five states:
When Synchronization takes place it is possible for message data to be exchanged between systems. One system sends the data, and all of the other systems taking part in the synchronization event receive the data, if the synchronization even is successful.
Once synchronization has been mastered everything else falls into place! But as with all aspects of development good design and a systematic approach is essential. It can take a long time to de-bug a badly designed distributed test case.