IBM
Contents Index Previous Next



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.

Figure 6 : A tree is represented in TTCN using indentation

Note that an absolute level of indentation does not necessarily mean that nodes are siblings. For example, although the nodes F and G are numerically at the same level of indentation (i.e. 3) as I and J, the nodes F and G are in one branch of the tree and the nodes I and J are in another

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.

Figure 7 : The body of a dynamic behavior table

The table body shows the columns for the line numbers, labels, statement lines, constraint references, verdicts and comments. The light shading indicates the extent of a single behaviour line. The dark shading indicates the extent of a single statement line.

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.

A TTCN qualifier is simply a:

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.

Figure 8 : Cycle of execution of a test case behavior tree


http://www.ibm.com/rational
Contents Index Previous Next