TTCN-3

TTCN-3 (Testing and Test Control Notation version 3) est un langage de test fortement typé utilisé pour les tests de conformité des systèmes communicants. TTCN-3 est écrit par l'ETSI dans la série ES 201 873, et est standardisé par l'UIT dans la série Z.160 . TTCN-3 a ses propres types de données et peut être combiné avec des types ASN.1, IDL, et XML.

Organisation du standard

Le standard TTCN-3 de l'UIT fait partie de la série Z et est organisé en plusieurs parties:

• Z.161 - Core Language - Définit le cœur de la notation
• Z.162 - Tabular presentation format (TFT) - Définit une présentation des tests sous forme tabulaire
• Z.163 - Graphical presentation format (GFT) - Définit une présentation des tests sous forme graphique similaire aux MSC
• Z.164 - Operational Semantics - Définit la sémantique d'exécution du TTCN-3
• Z.165 - TRI - Définit les interfaces fournies et requises par l'appareil de test
• Z.166 - TCI - Définit les interfaces fournies et requises par le contrôleur de test
• Z.167 - ASN.1 - Définit comment utiliser les types de données ASN.1 dans une suite TTCN-3
• Z.168 - Règles de traduction d'IDL vers TTCN-3
• Z.169 - Utilisation de schéma XML dans le TTCN-3

Organisation du langage

• Module

Le container de plus haut niveau dans une suite de test TTCN-3 est le module. C'est généralement un fichier.

• Component

Un component est une entité d'exécution. Un cas de test ou une fonction s'exécute sur un component.

• Port

Les components communiquent entre eux ou avec le système sous test (SUT) via des ports qui sont connectés les uns aux autres.

• Test case

Un test case est une séquence d'envoi et de réception. Quand un message est envoyé au système sous test, plusieurs possibilités de réponses sont décrites.

• Alternative

Comme un test case est une séquence de stimuli suivis par un ensemble de réponses possibles, la notation inclut la notion d'alternative. C'est une notation compacte qui permet de lister toutes les alternatives possibles dans un scénario.

• Template

Lors de l'envoi et de la réception d'information, la valeur des paramètres est de la plus haute importance. Elle doit être définie lors de l'envoi et vérifiée lors de la réception. La notion de template a pour objectif de définir les valeurs de paramètres quand ils sont envoyés et de vérifier les valeurs des paramètres lorsqu'ils sont reçus. Comme les paramètres peuvent être complexes, définir ou vérifier des valeurs peut être relativement long à écrire. Le template permet des vérifications complexes sur un simple appel de telle manière que le test case reste lisible.

• Verdict

Le verdict est le résultat de l'exécution d'un test case. Il a 5 valeurs possibles: none, pass, inconc, fail, error.

Applications

TTCN-3 a été utilisé pour écrire les suites de test de conformité des protocoles standards SIP, WiMAX, ou DSRC.

La Open Mobile Alliance a adopté en 2008 une stratégie pour l'utilisation de TTCN-3 pour traduire certains test cases dans une représentation exécutable.

Le projet AUTOSAR a promu en 2008 l'utilisation de TTCN-3 dans l'industrie automobile.

Le projet 3GPPa promu l'utilisation du TTCN-3 dans l'industrie du téléphone mobile.

Architecture

Lors de l'exécution du TTCN-3 l'architecture est organisée de la manière suivante:

• TE: TTCN-3 Executable est la suite de test sous sa forme exécutable.
• TRI: TTCN-3 Runtime Interface est l'interface entre le TE et le SUT. Elle est divisée en deux parties:
  • SA: System Adaptor
  • PA: Platform Adaptor
• TCI: TTCN-3 Control Interfaces est l'interface de contrôle pour l'exécution des tests. Elle est divisée en :
  • TM: Test Management
  • TL: Test Logging
  • CD: Coding and Decoding
  • CH: Component Handling

Exemple de code

Ceci est un exemple de code TTCN-3.

module TestSystem {

// Define a subtype of integer
type integer myNewType (0..50)

// Declare Request struct type with 2 fields
type record Request {
  myNewType param1,
  charstring param2
  }

// Declare Answer struct type with one field
type record Answer {
  myNewType param1
  }

// Declare a message based communication port
type port cEnv_type message {
  out Request;
  in Answer;
  }

// Declare the component on which the test case will run
type component sSystem {
  port cEnv_type cEnv;
  }

// The templates define the outgoing parameter values
// and verify the incoming parameter values
template Request Good_Req := {param1 := 42, param2 := "hello !" };
template Answer All_is_OK := {param1 := 0};

// Define testcase1 that will run on sSystem component
testcase testcase1() runs on sSystem
  {
  // Send Request message with (42, "hello !") as parmeters
  cEnv.send(Good_Req);
  // An alternative for the 2 possible answers
  alt
    {
    // Do we receive Answer with 0 as parameter
    []cEnv.receive(All_is_OK)
      {
      // Pass verdict !
      setverdict(pass)
      }
    // Or do we receive something else
    []cEnv.receive
      {
      // Fail verdict
      setverdict(fail)
      }
    }
  }

// Control part chains test cases execution automatically
control {
  var verdicttype verdict1;
  verdict1 := execute(testcase1());
  }
}

Voir aussi

• Une histoire du TTCN
• TTCN
• ETSI

Liens externes

• Site web sur le TTCN-3 de l'ETSI
• Conférence co-organisée par l'ETSI des utilisateurs de TTCN-3
• Une vidéo d'introduction au TTCN-3
• Memo TTCN-3
• Liste des outils TTCN-3
• Exporter des modèles Use Case Map (ITU-T Z.151) vers TTCN-3 (ITU-T Z.161) [1]