Introduction à TTCN-3maag/P7/docs/TTCN3_fiil2017-18.pdf · vers la fin de TTCN-2 Nombre croissant de spécifications (2G/3G/4G …) Pressions pour réduire le timet-to-market •

Introduction à TTCN -3

Stephane Maag

2 Stephane Maag / TSP

Vous venez de voir …

… à partir d’une spécification SDL

… génération de MSC …

… liens avec des scripts TTCN3 …


Mais …

� TTCN3, c’est quoi ?!

� Lien avec le modèle formel, l’architecture et les séquences de test ?!

� Historique,

� SUT, TTCN3 Core,

� Un exemple simple!


Quels Intérêts ?

� Cas de test et séquences de test proches du modèle formel

� Souvent test énuméré (sauf test symbolique)

• Ambiguités + pb black box

� Indépendant de l’interface d’exécution (ou alors in terfacées manuellement)

⇒ Besoin de mener la théorie vers un langage de test standardisé

� Plus tard, nous ferons le lien avec :

• Test de Conformité� Actif� Passif

• Architectures de Test (standardisées ISO)


… les architectures de test …


� Testing architectures defined by the ISO 9646

� Conceptually:

• The tester is directly connected to the IUT and controls its behavior.

• As presented here: only used when the test are performed locally by the human tester: optimal to detect failures!

• But not directly useable for conformance testing since the communication between the upper and lower testers has to be done through the “environment” (lower layers).

Testing architectures

Tester

(TS)

Upper Tester

Lower Tester

N-ASP

PCO

PCO

N-IUT

(N-1) ASP or N-PDU

PCO

PCO

N-ASP

PCO

PCO

N-IUT

(N-1) ASP or N-PDU

PCO

PCO


� ISO 9646 describes four main architectures:• Local

� Upper and lower testers are into the SUT.� The upper tester is directly controlled by the tester and its interface with

the IUT is a PCO.

• Distributed� The upper tester is into the SUT.� It is directly controlled by the tester and its interface with the IUT is a PCO.

• Coordinated� The upper tester is into the SUT but is implemented by the human tester.� It is directly controlled by the tester and its interface with the IUT is not

directly observable.

• Remote� No Upper Tester


Upper Tester

IUT

ASPs

PCO

System Under Test (SUT) Test System (TS)

Lower Tester

ASPs

PCO

Lower level service provider

Test Co-ordinationProcedures (TCP)

PDUs

Upper Tester

IUT

System Under Test (SUT)

Test System (TS)

Lower Tester

ASPs

PCO


PDU

TM-PDU

IUT


Lower Tester

ASPs

PCO


PDU

Upper Tester?

Local Distributed

Coordinated


Upper Tester

IUT

ASPsPCO


Lower Tester

ASPs

PCO


Test Co -ordinationProcedures (TCP)

PDUs

IUT: Implementation under TestPCO: Point of Control and ObservationASP: Abstract Service PrimitivePDU: Protocol Data Units

Remote

Controllability in the local architecture

� In a real system, the upper layer, here illustrated as the Upper Tester, communicates directly with the IUT.

� To be efficient, the communication between the IUT and the UT must be synchronized, both entities should work as they would be directly connected.

• The yellow area in the figure represents this synchronization

� That’s why we commonly use this local architecture to test the devices.

• Thus SUT, TS, PCO will be physical elements (devices)

� In order to test programs or software, it is then commonly used to apply asynchronous architectures, as it follows.

Upper Tester

IUT

ASPsPCO


Lower Tester

ASPs

PCO



PDUs

Distributed architecture

� The Upper Tester is implemented by the human testers,

� The TCP can be manual (by an operator) or automated,

� The coordination between the UT and LT is a protocol developed by the human testers,

� The test suites are the same as in a local architecture

� Appropriated to test a complete protocol stack layer (being closer to the SUT components).

Upper Tester

IUT

ASPs

PCO


Lower Tester

ASPs

PCO



PDUs

Example

�To test a phone switch:

• The UT could simulate the user (directly connected)

• The LT could

� simulate the remote switch

� could give instructions to the UT (e.g., pick up the phone)

� and controls the answer on the PCO with which it is directly connected.

Coordinated architecture

� This architecture has as a main drawback that the IUT has to integrate a UT directly controlled by the tester.

� The Upper Tester is directly and normally connected to the IUT, developed by the developer of the IUT.

� No PCO on the SUT side!

� It communicates with the tester by a Test Management Protocol that exchange some TM-PDUs

• The Test Management Protocol must be normalized since the tester could be any kind of entity

� The coordination between LT and UT (TM-PDUs) has to make part of the test suites.

� The messages detailing this coordination could be:

• either included in the data parts of the N-PDU (then pass through the LLSP)

• or transmitted through a separated connection.

� Appropriated to test a intermediary layer.

Upper Tester

IUT

System Under Test (SUT)

Test System (TS)

Lower Tester

ASPs

PCO


PDU

TM-PDU

Remote architecture

� The UT is not necessary, this can be operated by following informal instructions.

� The LT can send PDUs that contain data that will be interpreted by the IUT as primitives to be applied to its upper interface (dotted line).

� The possibilities to detect failures are limited since it is not possible to control or observe directly the upper interface.

� However, this architecture is simple and easily developed.

• Appropriated to test protocols whose the role of the upper interface of the SUT is limited (e.g., FTP)

IUT


Lower Tester

ASPs

PCOLower level service provider

PDU

Upper Tester ?

Link Upper Tester / Test System

� All architectures (except the Remote architecture) plan a link between the UT and TS.

� This link is real and must be implemented separately from the LLSP.

� Possibilities:

• An independent and reliable implemented link?

• Two persons communicating through another medium?


Principes menant à TTCN

� Une technologie pour différents types de test

• Distribués, indépendant des plates-formes

• Développement de tests graphiques (documentation et analyses)

• Adaptable, environnement de test ouvert

� Une technologie pour les IT distribués et les systèmes de Telco


Historique

� TTCN (1992)

• Publié tel un standard ISO

• Tree and Tabular Combined Notation

• Utilisé au test de protocoles� GSM, ISDN

� TTCN-2/2++ (1997)

• Test concurrents

• Modulaire

• Manipulation de données externes

• Pour le test de conformité


Historique

� TTCN-3 (2000)

• Testing and Test Control Notation

• ETSI STF 133 (200 membres) – coopération avec ITU-T SG10

• Langage propre (syntaxe et sémantique)

• Amélioration des points de communication, de configuration et de contrôle

• Standardisé et prend en considération standards communément implémentés� SIP, SCTP, IPv6, etc.

• Contributions volontaires de nombreux industriels Telco

� TTCN-3 stable en 2006

• Dec. 2016: TTCN3 v4.8.1� Proposition d’extensions


TTCN-2

� Conçu uniquement pour le Test

� Langage standardisé

� Bien établi et largement utilisé (mais appliqué?!)

� Utilise les méthodologies et concepts du test de conformité (ISO9646)

� Indépendant des outils

� Supporte ASN.1


De nouveaux challenges dans le Test :vers la fin de TTCN-2

� Nombre croissant de spécifications (2G/3G/4G …)

� Pressions pour réduire le timet-to-market

• De nouveaux services et systèmes plus vite

• Réduction du processus de test

� Pressions pour améliorer la qualité

• Réduire l’arrêt de composants réseaux (en secondes/ an !)

• Augmentation de la qualité des tests

� Nouveaux types de test

• Protocoles basés sur IP

• Protocoles « textuels »

• Unifier les approches de test logiciels et protocol es

� Tests nécessaires plus uniquement pour l’industrie Telco


TTCN-3 … c’est quoi ?

� Test and Testing Control Notation

� Langage standardisé pour formellement définir des scénarios de test.

� Prendre le meilleur de TTCN-2 et les combiner avec une meilleure et plus performante notation textuelle.

� Indépendant des outils.


Protocol TestingSoftware Testing

Pourquoi TTCN -3 est si important?

� Plus productif

• Facile à comprendre

• Facile à utiliser

� Plus puissant

• Fonctionnalités étendues

• Protocoles IP supportés

• Protocoles textuels supp.

� Plus flexible

• Pas lié au modèle OSI

• Tout (presque) type de test

� Facilités d’extensions

function Module Layer Unit Integration

TTCN-2

TTCN-3


Comparaison TTCN -2 / TTCN-3

TTCN – 2

� Format de fichiers dédiés au système

� Format de présentation tabulaire

� Supporte les timers et les messages de com. de base

� Configuration de test statique

� Interface statique (PCOs)

� Format textuel (script)

� Tabulaire, graphique (MSC) ou défini par l’utilisateur

� Supporte les timers, les messages de com. et procéduraux, et fonctions externes

� Configuration des tests dynamique et multi-connexions

� Interfaces distribuées (composants)


Application: Test de Conformité (1)

Bo

ite

No

ire


Application: Test de Conformité (2)

Layer 2

Layer 1

Layer 2

Layer 1

Layer 3

Layer 4

TTCN-3

Système de Test SUT

TRI


Où se situe TTCN -3 ?

TTCN-3 User

FormatGraphique

FormatTabulaire

ASN.1 Types & Values

Other Types & Values n

Other Types & Values 2

TTCN-3CoreNotation

Presentation Format n

Other Types & Values 3

msc mi_synch1_conc1

mtc ISAP1 MSAP2

UML Testing Profile

SDL

XML

C/C++

:

testcase myTestcase () runs on MTCType system TSIType

{ mydefault := activate (OtherwiseFail); verdict. set( pass);

:

connect(PTC_ISAP1:CP_ISAP1, mtc:CP_ISAP1);

:

map(PTC_ISAP1:ISAP1, system:TSI_ISAP1);

:

PTC_ISAP1. start(func_PTC_ISAP1());

PTC_MSAP2.start(func_PTC_MSAP2());

Synchronization(); all component. done;

log(”Correct Termination”);}

:


Concepts

� Black-Box Testing avec TTCN -3

� Configuration des Tests

� Composants des Tests

� Ports de communication

� Verdicts des Tests

� Éléments de TTCN -3

� Structure des spécifications TTCN -3

� Ré-utilisation de codes existants[Ebner2005]


Black-box testing avec TTCN -3

TTCN-3 Test Case

Port.send(Stimulus) Port.receive(Response)

System Under Test

Port

• Affectation d‘un verdict


TTCN-3 Test Case

Configuration des Tests

create

create

MTC

start

start

create

TCs

TC

TC

SUT


Composants des Tests

� Il y a trois types de composants

• Interface du système de test abstrait défini tel un composant

• MTC (Main Test Component)

• PTC (Parallel Test Component)

Système de Test

Système de test réel connecté au SUT

Interface du Système de Test Abstrait

MTC PTCnPTC1 PTC2


Ports de Communication 1(2)

� Les composants de Test communiquent via des ports.

� Un port est modélisé tel une FIFO infinie .

� Les ports ont des directions (in, out, inout).

� Il y a trois types de port

• message-based, procedure-based ou mixed

TC1 TC2

P1.send (Msg) P2. receive (Msg)

P2 (in )P1 (out )


Exemple: ports procedure-based

call getcall

reply ouraise exception

Caller Callee

getreply oucatch exception

blocking blocking


PIF

Test verdicts

� Verdicts: none < pass < inconc < fail < error

� Chaque composant de test a son propre verdict local qui peut être établi ( setverdict ) et lu ( getverdict ).

� Un Cas de Test retourne un verdict global.

MTC PTC1 PTCN

Verdict returned by the test case when it terminates

I

setverdict(inconc)setverdict(fail)

F P

setverdict(pass)


Éléments de TTCN -3

� Types de données utilisateurs génériques (e.g., pour définir des messages, primitives de service, information, PDUs).

� Données de test transmises/reçues durant le processus de test.

� Définitions des composants et des ports de communication qui sont utilisés pour configurer les tests.

� Spécification du comportement du système de test.Test Behavior

Test Configuration

TTCN-3

Test Data

Data Types


Structure des specs TTCN -3Modules

� Les modules sont les blocks modélisant toutes les specs TTCN-3.

� Une suite de test est un module.

� Un module est constitué d’une partie définition et d’une partie contrôle (optionnelle).

� Les modules peuvent être paramétrés.

� Un module peut importer des définition d’autres modules.

Module

Module Control

Module Definitions


Structure des specs TTCN -3Modules - Définition

� Les définitions sont globales au module.

� Les définitions des types de données sont basées sur les types structurés et prédéfinis.

� Les templates définissent les données des tests.

� Ports et composants utilisés dans les Configurations des tests.

� Functions, Altsteps et Test Cases définissent le comportement.

Test Cases

Altsteps

Functions

Test Components

Communication Ports

Signature Templates

Data Templates

Signatures

Constants

Data Types


Module

Module Control

Module Definitions

� La partie contrôle est la partie dynamique d’une spécification TTCN-3, là où les cas de test sont exécutés.

� Des déclarations locales telles que les variables et timers.

� Des éléments basics de codes peuvent être utilisés pour sélectionner et contrôler l’exécution des cas de test.

Structure des specs TTCN -3Modules – Contrôle


module … {…

control{var integer count;

if( execute(SIP_UA_REC_V_001()) == pass) {

// Execute test case 10 timescount := 0;while( count <= 10) {

execute(SIP_UA_REC_V_002());count := count + 1;

} // end while

} // end if

} // end control} // end module

Structure des specs TTCN -3Modules – Contrôle


Réutilisation de code existant –le mécanisme import

� Le Main Module contient la partie contrôle qui spécifie l’exécution de la suite de test.

� Les modules peuvent réutiliser les définitions (library) des autres modules.

� L’ import implicite des définitions via plusieurs imports n’est pas permis. Il nécessite un import explicite.

• Raison: un module doit connaitre tous les modules auxquels il dépend.

MainModule

LibraryModule 1

import

LibraryModule 2

import

LibraryModule 3

import

implicit importof a definition required

explicitimport


� Import permet d’importer:

• définitions

• groupes de définitions

� Les définitions peuvent être importés récursivement.

� On peut également exclure certaines définitions de l’import .

}

import form ModuleOne {

modulepar ModPar2;

type RecordType_T2

}

import from ModuleTworecursive {

testcase T_case

}

import from ModuleThree

all except {

template all

}

Réutilisation de code existant –le mécanisme import


Chaine d’intégration TTCN -3

Abstract Test Suitecompile

TE

TTCN-3Executable

TTCN-3 Runtime System

+

SUT

Executable Test Suite

build


TTCN-3 … sur un exemple !


Serveur DNS – Test Purpose

� Le service Internet DNS communique à partir d’échan ges de messages UDP

� Nous souhaitons tester le mapping correct:

www.it-sudparis.eu ⇔ 157.159.11.8

Client DNSTester SUT

(www.it-sudparis.eu, A)

(www.it-sudparis.eu, 157.159.11.8, A)

pass


Main module Definitions


Main module Definitions




pass


Main module DefinitionsPartie contrôle


Exécution du cas de test

query = ( www.it-sudparis.eu , A)

answer = ( www.it-sudparis.eu ,157.159.11.8,A)

Est-ce que la définitionde ce cas de test est adéquate?


Gestion des comportements erronées

� NON car:

• P.receive (answer ) bloque jusqu’à ce qu’il reçoive un message correspondant à la réponse (answer ).

• Aucun message ne débloque le tester

• Si aucun message n’est reçu, le tester reste aussi bloqué.

answer = ( www.it-sudparis.eu ,127.0.0.1,A)

query = ( www.it-sudparis.eu , A)


Gestion des comportements erronées




pass


Requête DNS délocalisée

� Le local DNS (SUT) n’a pas la correspondance IP de l’url,

� Le LDNS renvoie la requête à un serveur root(IANA) qui fournit l’adresse d’un autre serveur DNS qui on l’espère connait l’IP de l’url souhaitée ,

� L’IP est retournée à l’utilisateur (le testeur),

� On test le SUT, tout le reste sont des TC !



Client DNS root NS NS


(it-sudparis.eu, NS)

(it-sudparis.eu, ns.it-sudparis.eu,NS))


(www.it-sudparis.eu, 157.159.11.8,A)

(www.it-sudparis.eu, 157.159.11.8,A)

Tester TesterSUT



1

2

3

4


Requête DNS délocalisée - interface


Requête DNS délocaliséeFunctions for the two new TC




Outils TTCN -3

� Fournisseurs d’outils

• Danet

• DaVinci Communication

• Open TTCN

• Telelogic (IBM)

• Testing Technologies

• Strategic Test Solutions

� Outils internes utilisés par:

• Nokia

• Ericsson

• Motorola

� Matériel existant de test supportant TTCN-3 (pour les applications de télécommunication)

• Alcatel A1100

• Navtel InterWatch

• Nethawk

• Tektronix G20


CONCLUSIONS

� De nombreux intérêts en pratique mais aussi avec de s problématiques ouvertes en recherche

• Nouveaux domaines d’applications (e.g. automobile)

• Test de performance et temps réel

• Pattern de test

� TTCN-3 se révèle sur les plates-formes industrielle s

� Le standard TTCN-3 est mature

� TTCN-4 ?? …


Références sur TTCN -3

� Standard documents can be found on the TTCN-3 homep age: http://www.ttcn3.org/

� Example test suites:• See: http://www.ttcn-3.org/index.php/downloads/publicts/ publicts-etsi

• E.g., http://www.ttcn-3.org/index.php/downloads/publicts/ publicts-etsi/27-publicts-sip


Merci …

� … au travail fourni par les Prof Jens Grabowski et Andreas Ulrich de l’Université de Gottingen …

� … à Colin Willcock du Nokia Research Center pour sa vulgarisation de TTCN -3…

� Au CEO Testing Technologies (Berlin) pour la vulgarisation des exemples TTCN -3…

Documents

Introduction à TTCN-3maag/P7/docs/TTCN3_fiil2017-18.pdf · vers la fin de TTCN-2 Nombre croissant de spécifications (2G/3G/4G …) Pressions pour réduire le timet-to-market •