![]() |
![]() |
![]() |
![]() |
![]() |
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:
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:
Case study 22: Is the same as:
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:
- when an attach statement is reached when looping through a set of alternatives, control is passed to the attached test step;
- if no alternative in the first set of alternatives in the test step is successful during the first loop through that set of alternatives, then control returns from the test step to the calling tree, and evaluation continues with the other alternatives, if any, in the same set of alternatives as the attach statement; this has the same effect as if the test step was actually expanded into the calling tree;
- if an alternative in the first level of the test step is successful then execution continues in the test step tree;
- if a final verdict is reached in the test step tree then the execution of the test step (i.e. the entire test case) is halted and control is not returned to the calling tree;
- if no final verdict is encountered, before a leaf of the test step tree is reached then control returns to the calling tree, and execution continues with the next set of alternatives (if any) subsequent to the attach statement, i.e. the next level of indentation.
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.
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.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |