![]() |
![]() |
![]() |
![]() |
![]() |
Specification of Test System Behaviour
Before we continue with the declaration of the test case let us now look at how TTCN describes the behaviour of the various test components. Many standardized service definitions and protocol specifications use state diagrams and/or state tables to describe the behaviour of the service or protocol.
Test cases are derived from these specifications. However, because conformance testing is concerned with observing and controlling sequences of interactions at service interfaces it is more appropriate that we specify test system behaviour as a tree which has branches for all the possible sequences of interactions that may occur between any two given protocol states.
Behaviour Trees
In TTCN a tree of interactions is called a behaviour tree. The tree structure is represented by using increasing levels of indentation to indicate progression into the tree with respect to time.
Behaviour Lines
A node in a behaviour tree is called a behaviour line. A behaviour line consists of the following components:
Exactly which components of the behaviour line are used at a specific time varies. For example, line numbers and comments are always optional and constraint references and verdicts shall only be used when required.
TTCN Behaviour Description
Behaviour lines are specified in dynamic behaviour tables. There are three kinds of behaviour tables, each consisting of a header and a body.
The visual difference between these three tables is in the header. The format of the body is the same for all three. However, there is a significant difference, which will be explained later, in how these different tables are used.
Statement Lines
A sequence of one or more statements, together with the indentation information, in a single behaviour line is called a statement line. Statement lines appear in the behaviour description column of dynamic behaviour tables.
Statements
The behaviour of the test system, such as sending and receiving ASPs, is expressed using TTCN statements. Statements can be split into three distinct types:
Events
Some statements will be successful, i.e. match, depending on the occurrence of certain events. There are two types of event: input events and timer events. An input event is the arrival of an ASP at a named PCO or a message at a named CP. A timer event is the expiry of a protocol timer. The TTCN statements that are events are:
Actions
Some statements will always be successful, i.e. execute. We shall call such statements actions, although this term is not used in ISO/IEC 9646-3. These are actions that are executed by the test system, and TTCN assumes that they can always be executed successfully. The TTCN statements that are actions are:
Qualifiers
Statement lines may include a qualifier statement, i.e. a boolean expression. We call such statement lines qualified statement lines. No event can match, nor can any action be executed unless the qualifier included in the statement line evaluates to TRUE. An unqualified statement line is one that does not include a qualifier.
Combinations of Events, Actions and Qualifiers
The actual combinations of events, actions and qualifiers that are allowed are defined by the TTCN-MP. The different combinations will be described at the relevant points in this guideline.
Execution and Matching
We shall now consider how a behaviour tree is traversed and executed.
Alternatives
A set of statement lines at the same level of indentation, and in the same branch of the tree are called a set of alternative statement lines, or alternatives for short. Thus, in the Figure 6 (A,B), (C, D, E), (F, G), (I, J) and (H) are all different sets of alternatives.
Because the ordering within any given set of alternatives is significant it is important that all events and qualified statements appear before any unqualified actions.
Execution of the Behaviour Tree
Execution starts at the root of the tree. That is, the first set of alternatives is repeatedly looped with each alternative being evaluated in the order of its appearance in the set. This looping continues until a statement line is successfully executed or matched. If a statement line is successful then the next set of alternatives (if any) is entered, and the process is repeated.
Execution stops when a leaf of the tree is reached. A final verdict will also halt execution, see Verdicts.
In the example shown in Figure 7 execution starts by looping through the first set of alternatives (A, B). If B is successful then execution terminates. If A is successful then the next set of alternatives (C, D, E) is entered. Let's assume that the statement line E is successful: then the next set of alternatives is (I, J). If either I or J is successful then execution terminates. Note that if no statement line in any set of alternatives is ever successful then execution gets `stuck' as we repeatedly loop through those alternatives.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |