![]() |
![]() |
![]() |
![]() |
![]() |
Background
Among other things, parts 1 and 2 of ISO/IEC 9646 define the basic concepts and abstract methods that are the cornerstone of standardized conformance testing. It is beyond the scope of this guideline to examine these concepts in detail, but a knowledge of the terms and concepts described below is helpful to understanding the TTCN.
Black Box Implementations
One of the basic premises of the conformance standard is that the implementation of the protocol, called an implementation under test (IUT) is a black box.
Any conclusions that we may draw about the conformance of that IUT will be made by observing and controlling the events that occur at the lower and upper service interfaces of the IUT. In ISO/IEC 9646 terms these interactions occur at points of control and observation (PCO) and are expressed in terms of protocol data units (PDUs) embedded in abstract service primitives (ASPs).
An IUT is tested by a test system. In TTCN the different parts of the test system are called test components. A test component created by the main test system is referred to as a Parallel Test Component (PTC).
Lower Tester and Upper Tester
In simple terms, the test components which communicate with the IUT via the PCOs at the lower interface are collectively called the lower tester (LT). The test components which communicate with the IUT via the PCOs at the upper interface are collectively called the upper tester (UT). There must be at least one test component always present in the test system. This is called the master test component (MTC) and it is responsible for coordinating and controlling the test and for setting the final verdict of the test.
Communication between test components in the LT is achieved via coordination points (CP). Similarly, UT test components may communicate with each other via CPs.
Coordination between the LT and the UT is achieved by test coordination procedures (TCP).
The lower tester is the more complex of the two components as it is also responsible for the control and observation of the protocol data units (PDUs) embedded in the ASPs that it sends and receives. In fact, at any given time the LT, when executing a test case, is implementing a portion of the relevant protocol.
Test Notation
In order to test the IUT we need to specify the sequences of interactions, or test events, that we wish the test system to control and observe. A sequence of such events that specify a complete test purpose is called a test case. A set of test cases for a particular protocol is called a test suite.
The TTCN is a notation that has been developed for the specification of test cases at a level that is abstracted from the architecture of any real test system that these test cases may eventually be run on.
The abstract test cases contain all the information that is necessary to fully specify the test purpose in terms of the protocol that the IUT is supposed to implement. It does not include test system specific information. However, this does not mean to imply that the notation itself is abstract - during the last few years the definition of TTCN has become very precise, with regard to both syntax and operational semantics, and is now close to a programming language.
Forms of TTCN
The main body of ISO/IEC 9646-3 defines the graphical form of the notation (TTCN-GR), where all information is presented using tables. There is also an underlying machine processable format (TTCN-MP) specified in an extended form of BNF (Backus-Naur Form). In this guideline we shall concentrate on the TTCN-GR.
Requirements on TTCN
From Figure 1 it can be seen that, generally speaking, the ISO conformance standard requires that tests are specified in terms of (N-1)-layer ASPs, (N)-layer ASPs and (N)-layer PDUs. In order to fulfil these requirements the minimum functionality that the TTCN should provide is:
- the ability to specify the ASPs to be sent and/or received by the test system;
- the ability to specify the PDUs embedded in the ASPs;
- specification of the order in which ASPs are to be sent and/or received at specific PCOs.
In order to do this the TTCN allows:
- declaration of ASP and PDU types;
- declaration of PCOs;
- specification of actual ASPs and PDUs;
- specification of instances of behaviour.
We shall examine in detail how these, and other, features are supported in TTCN to make it a powerful notation for specifying abstract test cases.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |