Home • Corporate • Contacts •

TETware White Paper

Products

Solutions

Information

Datasheet

Documentation

FAQ

Knowledgebase

You are here: TETworks > White Papers > Synchronization

Introduction

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.

Automatic Synchronization

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:

• When a group of tests starts
  
• When a single test starts
  
• At the end of each test
  
• At the end of each group of tests
  

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.

Synch Points

The identification of the relevant Synch points is important. For example, consider this strategy for a file system test (see also Figure):

• The Server: export a file system using specified attributes
  
• The Client: mount the file system using NFS
  
• The Client: then creates a file on the mounted file system
  
• The Server: checks that the file was created correctly and generates a result
  
• The Client: unmounts the NFS file system
  
• The Server: unexport the file system
  

Figure: Identifying Synch Points

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.

Synch States

Synchronization has five states:

• Yes, synchronization has taken place and was successful.
  
• No, synchronization has taken place, but was not successful
  
• Not synchronized, synchronization has not yet taken place.
  
• Timed Out, a synchronization event has not taken place in the time allotted for it
  
• Dead, a system is dead and not responding.
  

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.

Conclusion

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.