In this appendix the detailed description of TTCN language can be found. A short summary and the introduction can be read in the measurement instruction.
A TTCN description consists from four parts, let we see them:
The first part of the overview (test suite structure) above all accurately specifies the standard of the protocol implementation to be tested, the accidental profile standards, the relevant PICS and PIXIT documents, the chosen abstract test method, as well as other notes. Then in a table contains test groups in the sequence according to the hierarchy between them.
The second part (test case index) contains test suite(s) of the test group(s) with the description of their test aims. To a test suite can be coupled one concrete test aim which can be connected to one conformance constraint.
The third part (test step index) contains test steps, the running of which depends only from the test suite and not directly from the selection process
The fourth part contains those test steps which describes default dynamic behaviour.
The description of the data types used by the part describing the dynamic behaviour can be found in the declaration part which contains the following:
The connection of these demonstrated by the figure below:
Concrete values or patterns of data objects are referred to as constraints (also prevalent is the name "limitations") according to the terminology of TTCN. The later dynamic part use these constraints to describe the dynamic behaviour, so that its tracking will be more simple, for example with constraint declaration a concrete ATM cell (e.g. unassigned cell) can be given.
Specification of ASP and PDU constraints presented in table format. From these PDU constraint are the most important from the viewpoint of the measurings, so we refers to these by the table below:
PDU constraint declaration |
|||
NAME OF THE CONSTRAINT : Constraint identifier (parameter list) PDU TYPE : PDU identifier DERIVATION PATH : [Derivation path] NOTES : Optional text |
|||
Data field name |
Data field value |
Data field coding |
Notes |
. . PDU data field identifier . . |
. . Value of the constraint and attributes . . |
. . Call of PDU coding process . . |
. . Optional text . . |
Detailed notes: |
Dynamic part describes the dynamic behaviour of the individual test suites, and thus dynamic behaviour of IUT, using issues declared by the previous three parts. General conception of this description is built up to the so called behaviour trees, that are demonstrated in details on the following figure:
!CONNECTrequest | ?CONNECTconfirm | !DATArequest | ?DATAindication | !DATArequest |
Event series !CONNECTrequest | ?CONNECTconfirm | !DATArequest | ?DISCONNECTindication |
!CONNECTrequest | ?DISCONNECTindication |
Behaviour tree
| ||
Behaviour tree in TTCN
|
TTCN behaviour tree is the base of the part of the following table describing behaviour.
Each protocol processes are basically built up from three kind of events: PDU-sending, PDU-reception, and timeout, and TTCN uses four types of event lines for their description:
An exclamation mark marks the event line sent by a given PCO: PCO_X!DATArequest
Reception event line is marked by a question mark: PCO_X?DATAindication
The "otherwise" events are also marked with a question mark: PCO_X?OTHERWISE
Timer events are also marked with a question mark : PCO_X?TIMEOUT Clock_1
These event lines are the essential parts of tables describing dynamic behaviour of the test cases, and build-up of a table like this is demonstrated by the table below:
Dynamic behaviour of a test case |
|||||
NAME_OF_TEST_CASE : Individual test case identifier TEST_GROUP : Name of the test group TEST_GOAL : Optional text DEFAULT : List of default references NOTES : Optional text |
|||||
Nr. |
Label |
Description of behaviour |
Constraint reference |
Verdict |
Notes |
. . n . . |
. . LB_k . . |
. . Statement line (see the previous figure) . |
. . [Constraint reference] . . |
. . P/F/I . . |
. . Optional text . |
Detailed notes: |
If the individual test suites are distributed into test steps, then their dynamic behaviour will be described in similar tables. The same description scheme is used besides it for the description of the default dynamic behaviours, too.
<Content> <Appendix B>