Lecture Notes in Computer Science 3472

504 Zhen Ru Dai
can be mapped to JUnit concepts. But since JUnit is a framework only for unit
tests, there are a lot of concepts in U2TP which are not defined in JUnit and
also needed for unit tests.
A System Under Test does not need to be identified explicitly in JUnit. Any
class in the classpath can be considered as an utility class or a SUT class. An
arbiter can be realized as a property of the test suite of a type TestResult.
A test context is realized as a class inheriting from the JUnit TestCase class.
Test control is defined by overloading the runTest operation of he JUnit fixture.
A test case is an operation in JUnit. Coordination can be mapped using any
available synchronization mechanism available to the test components such as
semaphores. In JUnit, predefined verdicts are pass, fail and error. There is no
inconclusive verdict. Test components, stimulus, observation, test configuration,
timezone are not defined in JUnit since these concepts are only needed for system
tests. Also wildcards, coding rules and timers are not concepts of JUnit.
17.3.2 TTCN-3
Fundamentals of TTCN-3 The Testing and Test Control Notation - 3rd edition
(TTCN-3) is a test specification and implementation language to define test
procedures for black-box testing. At time, it is the only accepted standard for
test system development in the telecommunication area.
TTCN-3 is a modular language. It comprises concepts suitable for various
types of system testings. Additionally to typical programming languages, it also
contains features necessary to specify test procedures like test verdicts, matching
mechanisms, timer handling, dynamic test configuration specifications, specification
of encoding information, synchronous and asynchronous communications.
In a TTCN-3 module, stimuli are sent to the system under test (SUT). Its
reactions are observed and compared with the expected behavior defined in the
test case. Based on this comparison, the subsequent test behavior is determined
and a test verdict is assigned. If the expected and the observed responses differ,
a failure test verdict is assigned. A successful test is indicated by a test verdict
pass. Since TTCN-3 has been introduced in the last chapter in detail, the reader
is requested to read that chapter for a better understanding.
Mapping to TTCN-3 TTCN-3 served as a second basis for the development of
the U2TP. Nevertheless, there are concepts which differ from or are added to
the Testing Profile. Thus, a mapping from the Testing Profile to TTCN-3 is
complete but not the other way around.
Table 17.4 shows an excerpt of the most important mapping rules of the
standard. It compares the U2TP concepts with existing TTCN-3 testing concepts.
Almost all U2TP concepts have direct correspondence or can be mapped
to TTCN-3 testing concepts.
In order to represent the system under test, TTCN-3 provides the indirect
definition via ports from the test components to the SUT. Test components are
specified by component types. There is a default arbiter built in TTCN-3. If the
user wants to specify an explicit arbiter, it must be realized by the main test