Integrated Application of TTCN

1
Integrated Application of TTCN

• Dieter Hogrefe

2


3
Peculiarities of Communication Software
(Protocols) vs. other types Software

• Establishment of states (connection, interface,
  process) -gt state oriented modelling
• Precisely defined and standardized message
  formats
• The software has to interwork with a large amount
  of (unknown) implementations
• Distribution

4
Consequences from the peculiarities

• Existence of detailed specifications (Internet
  Draft, ETSI Standard, ITU-T Standard,
  Proprietary, )Base Standards and Test
  Specifications
• Specialized (state oriented) specification
  languages and methods have been developed
• Testing against reference implementations
  (protocol testers
• Testing by Interop events, e.g.IPv6 Event,
  Mandelieu, 23-27 Sep.

5
Specialized specification languages, methods and
tools

• LanguagesSDL, MSC, TTCN, ASN.1, (UML in the
  future?)
• Methods- State based modelling- State based
  verification (e.g. state space exploration)-
  Systematic test case development based on
  specialized methodology (ISO 9646, UIO, )
• ToolsTelelogic TAU, Solinet SAFIRE, DANET,
  DaVinci, TestingTech,

6
Testing Language http//www.etsi.org/ptcc/ptc
cttcn3.htm

• Testing and Test Control Notation
• Versions 1 and 2 developed by ISO SC21 WG3 (1984
  - 1997) as part of the widely-used ISO/IEC 9646
  conformance testing standard
• ISO/IEC 9646-3 (edition 2) and ITU-T X.292
• Version 3 developed by ETSI TC MTS (1998 - 2000)
• Specialist Task Forces STF 133 STF 156

7
Testing Language

• One test notation for many testing applications
• Cheaper education and training costs
• Facilitates the application of a common
  methodology
• Easier maintenance of test suites
• Off-the-shelf tools
• Universally understood syntax and operational
  semantics
• Tests concentrate on the meaning of the test
• Constant maintenance of the language

8
Motivation for developing

• Modernization
• technology has changed since TTCN was first
  developed
• Wider scope of application
• should be applicable to many kinds of test
  applications not just conformance (development,
  system, integration, iop )
• Harmonization
• should be the first choice for test specifiers,
  implementors and users both for standardized test
  suites ...
• and as a generic solution in industrial
  product development

9
Testing Language

• Kinds of testing to which TTCN-3 could be applied
  
• - Conformance - Interoperability
• - Configuration - Compatibility
• - Performance - Stress
• - Robustness - Integration
• - Functional - Load
• - Reliability - Fault tolerance
• - Scalability - Degraded mode
• - Unit - Product
• - Development - Design
• - Interface - System

10
Main Capabilities of

• Dynamic concurrent testing configurations
• Various communication mechanisms (synch and
  asynch)
• Data and signature templates with powerful
  matching mechanisms
• Specification of encoding information
• Display and user-defined attributes
• Test suite parameterization
• Test case control and selection mechanisms
• Assignment and handling of test verdicts
• Harmonized with ASN.1
• Different presentation formats
• Well-defined syntax, static semantics and
  operational semantics

11
Core Language

• Core format is a text based language
• Core can be viewed as text or in various
  presentation formats

TTCN-3 Core Language

• Tabular format for conformance testing

• Graphical format for visual overview

• Other standardized formats in the future
• Proprietary formats

12
Use with other Languages

• TTCN can be integrated with other 'type and
  value' systems

TTCN-3 Core Language

• Fully harmonized with ASN.1 (1997)

• Harmonization possible with other type and value
  systems (possibly from proprietary languages)

13
Major Elements of

• Built-in and user-defined generic data types
  (e.g., to define messages, service primitives,
  information elements, PDUs)

TTCN-3 Core

• Actual test data transmitted/received during
  testing

• Definition of the components and communication
  ports that are used to build various testing
  configurations

• Specification of the dynamic test system behaviour

14
Example Core (Text)

• function PO49901(integer FL) runs on MyMTC
• L0.send(A_RL3(FL,CREF1,16))
• TAC.start
• alt
• L0.receive(A_RC1((FL1) mod 2))
• TAC.cancel
• verdict.set(pass)
• TAC.timeout
• verdict.set(inconc)
• any.receive
• verdict.set(fail)
• END_PTC1() // postamble as function call

15
Example Tabular
16
Example Graphical
17
Use of for OSP

• Open Settlement Protocol (OSP)
• EP TIPHON XML-based protocol
• uses TTCN-3 Core Language

18
Use of for SIP Tests

• IETF Session Initiation Protocol (SIP)
• RFC 3261
• EP TIPHON SIP Profile
• Work was done by STF196 in EP TIPHON
• Nokia, Ericsson, GMD Fokus (Testing Tech),
  ACACIA, FSCOM, GN Nettest
• work due to finish December 2003
• executable tests running
• TTCN-3 will be used by 3GPP for SIP tests in 2004

19
Use of for IP Tests

• ETSI has work items on developing test suites for
• IPv6 Core
• IPv6 Security
• IPv4-to-v6 Transition
• Currently under review by DG Enterprise at the
  Commission for funds from the eEurope initiative
• WIs for SIGTRAN M3UA, SCTP will be opened in
  October

20
Methodology
21
Methodology
22
Methodology

• UML testing profile
• TTCN-3 compatible
• JUnit compatible
• UML-TTCN-3 profile?

23
Goals of the UML Testing Profile

• Definition of a testing profile to capture all
  information that would be needed by different
  test processes
• To allow black-box testing (i.e. at UML
  interfaces) of computational models in UML
• A testing profile based upon UML 2.0
• That enables the test definition and generation
  of structural (static) and behavioral (dynamic)
  aspects of UML models, and
• That is capable of inter-operation with existing
  test technologies for black-box testing
• Define
• Test purposes for computational UML models, which
  should be related to relevant system interfaces
• Test components, test configurations and test
  system interfaces
• Test cases in an implementation independent
  manner

24
Roots of the Testing Profile

• Test control
• Wildcards
• Defaults
• Test components

• Arbiter
• Validation actions
• Data pools

UML Testing Profile
25
Concepts of the Testing Profile

• Test architecture
• Test structure, test components and test
  configuration
• Test data
• Data and templates used in test procedures
• Test behavior
• Dynamic aspects of test procedures
• Test time
• Time quantified definition of test procedures

26
Implementations under Development

• Eclipse Project Hyades on an Open Source Trace
  and Test Framework
• The test part is based on the U2TP standalone
  metamodel
• Telelogic Tau G2
• The test part is based on the U2TP profile
• Microsoft Visual Studio
• ITEA Project on Advanced Test Methods and Tools
  TTmedal

27
In Summary U2TP

• UML Testing Profile provides specification means
  for test artifacts of systems from various
  domains
• Enhances UML with concepts like test
  configuration, test components, SUT, verdict and
  default
• Seamlessly integrates into UML being based on
  UML metamodel, using UML syntax
• Adopted at OMG Technical Meeting, Paris, June
  2003
• http//www.fokus.fraunhofer.de/u2tp/

28
The End
29
Questions and Answers