Instance Synchronization

System Testing for C

The RENDEZVOUS statement, provides a way to synchronize Virtual Testers to each instance.

When a scenario is executed, the RENDEZVOUS instruction stops the execution until all Virtual Testers sharing this synchronization point (the identifier) have reached this statement.

When all Virtual Testers have met the rendezvous, the scenario resumes.

SCENARIO first_scenario

FAMILY nominal

-- Synchronization point shared by both Instances

RENDEZVOUS sync01

INSTANCE JUPITER:

RENDEZVOUS sync02

. . .

END INSTANCE

INSTANCE SATURN:

RENDEZVOUS sync02

. . .

END INSTANCE

END SCENARIO

Synchronization can be shared with other parts of the test bench such as in-house Virtual Testers, specific feature , and so on. This can be done easily by linking these pieces with the current Target Deployment Port.

Then, to define a synchronization point, you must make a call to the following function:

atl_rdv("sync01");

This synchronization point matches the following instruction used in a test script:

RENDEZVOUS sync01

Example

The following test script is based on the example developed in the Event Management section. The script provides an example of the usefulness of instances for describing several applications in a same test script.

HEADER "SystemTest Instance-including Scenario Example", "1.0", ""

DECLARE_INSTANCE JUPITER, SATURN

COMMTYPE appl_comm IS appl_id_t

MESSAGE message_t: message, data, my_ack, neg_ack

CHANNEL appl_comm: appl_ch

#appl_id_t id;

#int errcode;

PROCSEND message_t: msg ON appl_comm: id

CALL mbx_send_message( &id, &msg ) @ err_ok

END PROCSEND

CALLBACK message_t: msg ON appl_comm: id

CALL mbx_get_message ( &id, &msg, 0 ) @@ errcode

MESSAGE_DATE

IF ( errcode == err_empty ) THEN

NO_MESSAGE

END IF

IF ( errcode != err_ok ) THEN

ERROR

END IF

END CALLBACK

SCENARIO first_scenario

FAMILY nominal

COMMENT Initialize, register, send data

COMMENT wait acknowledgement, unregister and release

CALL mbx_init(&id) @ err_ok @ errcode

ADD_ID(appl_ch,id)

INSTANCE JUPITER:

VAR id.applname, INIT="JUPITER"

END INSTANCE

INSTANCE SATURN:

VAR id.applname, INIT="SATURN"

END INSTANCE

CALL mbx_register(&id) @ err_ok @ errcode

COMMENT Synchronization of both instances

RENDEZVOUS start_RDV

INSTANCE JUPITER:

VAR message, INIT={type=>DATA,num=>id.s_id,

& applname=>"SATURN",

& userdata=>"Hello Saturn!"}

SEND( message , appl_ch )

DEF_MESSAGE my_ack, EV={type=>ACK}

WAITTIL (MATCHING(my_ack), WTIME==300)

DEF_MESSAGE data, EV={type=>DATA}

WAITTIL (MATCHING(data), WTIME==1000)

END INSTANCE

INSTANCE SATURN:

DEF_MESSAGE data, EV={type=>DATA}

WAITTIL (MATCHING(data), WTIME==1000)

VAR message, INIT={type=>DATA,num=>id.s_id,

& applname=>"JUPITER",

& userdata=>"Fine, Jupiter!"}

SEND( message , appl_ch )

DEF_MESSAGE my_ack, EV={type=>ACK}

WAITTIL (MATCHING(my_ack), WTIME==300)

END INSTANCE

CALL mbx_unregister(&id) @ err_ok @ errcode

CLEAR_ID(appl_ch)

CALL mbx_end(&id) @ err_ok @ errcode

COMMENT Termination Synchronization

RENDEZVOUS term_RDV

END SCENARIO

The scenario describes the behavior of two applications (JUPITER and SATURN) exchanging messages by using a communications stack.

Some needed resources are allocated and a connection is established with the communication stack (mbx_init). This connection is made known by the Virtual Tester with the ADD_ID instruction. Note that this is a common part to both instances.

Then, the two applications register (mbx_register) onto the stack by giving their application name (JUPITER or SATURN). These operations are specific to each instance, which is why these operations are done in two separate instance blocks.

The application JUPITER sends the message "Hello Saturn!" to the SATURN application (through the communication stack) which is supposed to have set itself in a message waiting state (WAITTIL (MATCHING(data), ...) ).

Once the message has been sent, JUPITER waits for an acknowledgment from the communication stack (WAITTIL(my_ack),...). Then, it waits for the response of SATURN (WAITTIL (MATCHING(data),...) ) which answers by the message "Fine, Jupiter!" (SEND(message , appl_ch ) ). These operations are specific to each instance.

Finally, the applications unregister themselves and free the allocated resources in the last part, which is common to both instances.