IBM
Contents Index Previous Next



Modularization of Test Cases


Test cases can be long and complex. There exist two mechanisms that allow test cases to be modularized: test steps and defaults.

Test Steps

Behaviour trees can be modularized by splitting them into sub-trees called test steps. Test steps are either:

Test steps may be parameterized, i.e. the calling tree can pass PCOs, variables, literal values, constraints etc. to the attached test step.

Local test steps

Local test steps may only be used within the behaviour description in which they appear:

Figure 68 : Illustration of local test trees and test step library

The Test Step Library

Test steps that belong to the test step library are specified in Test Step behaviour tables. These steps may be called by any test case, test step or default.

The ATTACH Statement

The ATTACH statement is used to invoke a test step, and is denoted by:

In both cases the actual parameter list should only be used if the test step has a formal parameter list. Note that a parameter may also be a PCO or CP.

Case study 21: The following test step:

Figure 69 : Test Step Dynamic Behaviour (LTS)

Case study 22: Is the same as:

Figure 70 : Test Step Dynamic Behaviour (LT)

Tree Attachment as a Subroutine Call

TTCN defines tree attachment as the actual expansion of the called tree, i.e. the test step, into the calling tree, which may be a test case or another test step. While this is a sensible approach, adequately described in the TTCN standard, we feel that the view of treating test steps as subroutines is a valid one, and one that implements the TTCN semantics for tree attachment correctly. These semantics are easily understood by anyone with a programming background.

A test step can be considered as a subroutine when handled in the following manner:

Figure 71 : Execution of a test step

Default Behaviour

The conformance standard requires that a TTCN test case must be fully specified, in terms of behaviour. This means that at any point in time a tester must be prepared to accept all possible incoming ASPs or PDUs. This includes not only the ASPs or PDUs that are allowed by the protocol but also any ASP, legal or otherwise, that the IUT or service provider may issue

The easiest way to take care of this is by using the OTHERWISE statement. However, TTCN requires that the OTHERWISE statement leads to a fail verdict and this may not always be desirable. For example, it may be perfectly legal for the underlying network service to issue an N_DISCONNECTindication at any time. Certainly, an OTHERWISE would pick this up, but a verdict of FAIL in such an instance would be quite wrong. The only verdict that should be assigned in this case is INCONClusive, i.e. use with care!

Specifying all possible combinations tends to clutter up the main behaviour description, detracting from the readability of the test case. The default behaviour can be used to specify this peripheral behaviour in a precise manner. It will often comprise the set of ASPs or PDUs that are allowed by the protocol at any given time but which are not part of the test purpose, and an OTHERWISE to catch all other unspecified events. It is also common practice to include a general TIMEOUT in the default.

Case study 23: If we specify the following default behaviour.

Figure 72 : Default Dynamic Behaviour (LT_DEFAULT)

Modeling Default Behaviour

Default behaviour can be modeled as a tree attachment that is implicitly called as the last alternative in every set of alternatives.

Defaults Reference

A test case or test step references this default behaviour in the Defaults entry in its header. If this entry is empty then no default behaviour is applicable.

Figure 73 : The test step with a default

Figure 74 : Is the same as the previous test step


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