For example: test case CASE100 has the reference INTEROP/REQUEST/BASIC/CASE100. This reference show that the case belongs to group BASIC (for basic testing), which part of the group REQUEST (Groups for the requester role), which in turn is part of the group INTEROP (root of the interoperability test suite.)

The test case purpose identifies the purpose of the test case and also provides special instructions for executing the test case. In the CASE100 example, the purpose indicates that the case focuses on the simplest transaction for a non-returnable item. It also instructs the IUT operator to use only mandatory data that is to send the smallest possible APDU.

Test Case Events:

1. Invoking a request service such as the ILL-REQUEST request;
2. Transmitting an APDU, such as transmitting the ILL-REQUEST APDU, as the result of invoking a request primitive;
3. Receiving an APDU from a partner implementation such as receiving the SHIPPED APDU;
4. Getting an indication primitive, such as the SHIPPED indication, as the result of the reception of an APDU;
5. A local action such as the time-out expiry.

Abbreviations used to specify the possible test events in the DYNAMIC Behaviour Tables are as follows:

Points of Control and observation (PCO)

IUT: This PCO represents the interface between the ILL Application Service Element (ASE) and the service user. It is at this point that the request and indication test events occur.

L: This PCO represents the interface between the ILL ASE and the communications service. It is at this point that the transmission and reception of APDUs occur.

LF: This PCO also represents the interface between the ILL ADE and the communications service. But with the LF PCO, APDUs are sent to and received from a different mail address. It is used when testing forwarding, that is, when the test case involves more than one partner (a different PCO refers to a different partner.)

Specifying a TTCN Test Event:

"!" specifies that data is flowing from the implementation, that is, when the test event involves the transmission of an APDU or a request service primitive.

"?" specifies that data is flowing to the implementation, that is, when the event involves the reception of an APDU or an indication service.

The possible formats for test event specification are:

<IUT!service> for requester service

<IUT?service> for indication services

<IUT!local action> for local actions

PCO!APDU for transmitting an APDU

PCO?APDU for receiving an APDU

Following are examples for TTCN test events:

<IUT!ILLreq>: requester test event in which the ILL-REQUEST request service is invoked

<IUT?RCVind>: responder test event in which the RECEIVED indication occurs

L!CHK: responder test event in which the CHECK-IN APDU is transmitted

L?RET: requester test event in which the RETURNED APDU is received

These events are arranged in the Behaviour Description column of the TTCN Dynamic Tables. Notice that the test event specifications are indented from one another. This indentation specifies events that occur sequentially, that is, follow one another in time.

In the test CASE133, an number of events have the same level of indentation starting with the events L?SHI and L?ANS. Arranging the test events in this fashion creates alternative branches that can be selected. In this case, the responder can either send the SHI APDU or if it cannot send this optional APDU, must send the ANS APDU (see the corresponding test case CASE233). These alternatives provide two ways of requiring the RCV APDU from the requester. Once a branch has been chosen, the case terminates at the end of the branch.

Events with Optional APDUs:

The test cases have been specified as if the optional APDUs are transmitted. This will not necessarily be the case during interoperability testing. Implementations may only transmit the optional APDU under certain conditions. For example, the optional APDU may only be transmitted when required by the remote site. An implementation may not even be capable of transmitting optional APDUs.

To allow for the various possible scenarios, when executing an event where the optional APDU is not transmitted, the IUT operator should invoke the STRreq service. The remote site receives an STRind indicating that the service has been invoked and the optional APDU has not been transmitted.

For example, the test event specifications:

<IUT!SHIreq>
 L!SHI

L?SHI
<IUT?SHIind>

<IUT!SHIreq>
 <IUT!STRreq>
  L!STR

L?STR
 <IUT?STRind>

when the SHI optional APDU is not provided by the responder. The alternatives could have been included in the test specifications. This would have rendered the case specifications lengthy and complex. To keep them simple, the cases were specified as if the optional APDUs were transmitted.

It is highly recommended that the implementations require that optional APDUs be transmitted. This ensures that the execution of cases will closely resemble the test case specification. Of course, requiring an optional APDU from an implementation that does not support it is not recommended.

Running the APTAPDU Test Group:

The test cases specified in the OPTAPDU test group focus on the SHI and RCV optional APDUs. In the purpose of each case, a note indicates if the requester should require, desire, or place no requirements for the SHI APDU; and similarly if the responder should require, desire, or place no requirements for the RCV APDU. This is done by setting the value for requester-SHIPPED parameter in the ILL APDU to require, desire, or neither for the requester; and setting the value for responder-RECEIVED parameter in either the SHI or ANS APDU to require, desire or neither for the responder. Notice that constraint formal parameters are used in the dynamic tables to set values for these parameters.

Test cases are selected from this test group based on the support of the optional APDUs and the capability for making requirements for optional APDUs by all partners in a test party.

Constraint tables

For the test events involving request or indication services, a constraint reference is specified. This reference can be used as an index into the constraint tables. A constraint table is a means of constraining parameter values used when invoking services. Much flexibility is given to the operator to specify test data. An exact parameter value is specified only when it is required to achieve the test purpose. These tables consist of ASN.1 value definitions that specify the values expected for the APDU parameters. Values can consist of actual values as defined in the ILL Protocol Standard or one of the following wildcards:

? A valid value must be present

* A value need not be present, but if one is present, it must be valid

OMIT No value must be present

Formal parameters are used to define values for constraints in the dynamic tables.

For example, the constraint reference BSANSind000(unfilled) in test case CASE102 is used to specify the value "unfilled" for the transaction-results parameter of the ANS APDU.

<IUT!ILLreq>
 L!ILL
  L?SHI
   <IUT?SHIind>
    <IUT!RCVreq>
     L!RCV

BSILLreq000


BSSHIind000
BSRCVreq000

<IUT!ILLreq>
 L!ILL
  L?SHI
   <IUT?SHIind>
    <IUT!RCVreq>
     L!RCV
      <IUT!RETreq L!RET>
       L?CHK
        <IUT?CHKind>

BSILLreq001


BSSHIind001
BSRCVreq001

BSRETreq000

BSCHKind000

<IUT!ILLreq>
 L!ILL
  L?ANS
   <IUT?ANSind>

BSILLreq001


BSANSind000(unfilled)

<IUT!ILLreq>
 L!ILL
  L?SHI
   <IUT?SHIind>
    <IUT!RCVreq>
     L!RCV
  L?ANS
   <IUT?ANSind>

    <IUT!RCVreq>
     L!RCV

BSILLreq004(desires)


BSSHIind004(requires)
BSRCVreq000


BSANSind006(will-supply, 
requires)
BSRCVreq000

<IUT!ILLreq>
 L!ILL
  L?FWD
   <IUT?FWDind>
    L?SHI
     <IUT?SHIind>
      <IUT!RCVreq>
       L!RCV

BSILLreq006(RESP1)


BSFWDind000(RESP2)

BSSHIind006(RESP2)
BSRCVreq003(RESP2)

L?ILL
 <IUT?ILLind>
  <IUT!SHIreq>
   L!SHI
    L?RCV
     <IUT?RCVind>

BSILLind000
BSSHIreq007


BSRCVind000

L?ILL
 <IUT?ILLind>
  <IUT!SHIreq>
   L!SHI
    L?RCV
     <IUT?RCVind>
      L?RET
       <IUT?RETind>
        <IUT!CHKreq>
         L!CHK

BSILLind001
BSSHIreq008


BSRCVind001

BSRETind000
BSCHKreq002

L?ILL
 <IUT?ILLind>
  <IUT!ANSreq>
   L!ANS

BSILLind001
BSSHIreq007(unfilled)

L?ILL
 <IUT?ILLind>
  <IUT!SHIreq>
   L!SHI
    L?RCV
     <IUT?RCVind>
  <IUT!ANSreq>

   L!ANS
    <IUT!SHIreq>
     L?RCV
      <IUT?RCVind>

BSILLind004(desires)
BSSHIreq011(requires)


BSRCVind001
BSANSreq012(will-supply,
requires)

BSSHIreq011(?)

BSRCVind001

L?ILL
 <IUT!ILLind>
  <IUT!SHIreq>
   L?SHI
    L!RCV
     <IUT!RCVind>

BSILLind007
BSSHIreq008


BSRCVind001