 |
|
Le fichier de configuration est au format XML simplifié. La structure est décrite dans le fichier tulip.dtd. Il consiste en un seul élément racine <CONFIG>, dans lequel s’ajoutent d’autres balises. Le nom par défaut pour le fichier de configuration est 'tulip.xml".
<TRAFFIC> : section contenant les paramètres d’exécution du test. Elle peut contenir les balises suivantes:
<MODE> 0 ou 1. Contient le mode utilise pour le test, en général le protocole. Si cette balise est absente, aucune librairie de protocole n’est chargée.
Exemple: <MODE>MEGACO</MODE>
<FORMAT> 0 ou 1. Spécifie le format utilisé pour l’envoi/réception de messages avec le pipeline de test. Si égal à TEXT, les messages sont au format texte (ASCII). Si égal à HEXA, les messages sont décris au format hexadécimal.
Exemple: <FORMAT>TEXT</FORMAT>
<SCENARIO> 0 ou 1. Contient le nom du sequentiel de test racine du test. C’est le premier séquentiel qui sera exécuté par tulip. Le fichier doit se trouver dans le répertoire source (directive –s) ou dans le répertoire d’exécution de tulip. Exemple: <SCENARIO>GO_TEST.xml</SCENARIO>
<NAME> 0 ou 1. Contient le nom du test, paramètre libre non utilisé actuellement (réservé pour les couches applicatives supérieures)
Exemple: <NAME>Common1</NAME>
<DESCRIPTION> 0 ou 1. Contient la description du test, paramètre libre non utilise actuellement (réservé pour les couches applicatives supérieures). Exemple: <DESCRIPTION>Test standard</DESCRIPTION>
<DEBUG> 0 ou 1. Utilisé pour activer le mode DEBUG, l’attribut LEVEL spécifie le niveau de trace (de 0 à 4), 0 signifie aucune trace.
Exemple: <DEBUG LEVEL="1"/>
<ENVIRONMENT> : section contenant les paramètres d’environnement du test. Elle peut contenir les balises suivantes:
<LOCAL> 0 ou 1: contient la description de la socket locale. Deux attributs peuvent être définis, “IP” est l’adresse IP local utilisée, “PORT” est le port dans le protocole de transport utilisé (UDP, TCP, SCTP).
<TEST> 0 ou 1: active le rebouclage test au niveau de la couche transport (voir section associée). L’attribut « OUTPUT » permet de rediriger la sortie standard de l’application vers un fichier, ou l’écran (« SCREEN », valeur par défaut.
<REMOTE> 0 ou plus: déclaration de l’entité distante testée. Par défaut, la première entrée est celle utilisée par l’application pour l’envoi/réception de messages. Le premier attribut est le FQDN (fully qualified domain name) ou l’IP distante, contenue dans l’attribut « HOST». L’attribut « PORT » contient le port distant.
<TRANSPORT> 0 ou 1: spécifie les options relatives à la couche transport. - Attribut MODE : si égal à MONO, le même port est utilisé pour le test, et est partagée par tous les agents. Si égal à MULTI, chaque agent utilise un port spécifique. - Attribut ROLE : tulip supporte deux fonctionnements au niveau de la couche transport. Si le rôle est égal à CLIENT, l’application tulip se connecte à un serveur distant (ex, serveur TCP). Si le rôle est SERVER, tulip accepte des connexions d’un client distant : aucun paquet ne sera envoyé avant qu’une demande de connexion ne soit reçue. - Attribut PROTOCOL : spécifie le protocole de transport utilisé par l’application. Il peut être égal à UDP (full UDP), TCP (full TCP) UDP_TCP/TCP_UDP (UDP+switch vers TCP selon le mode), SCTP (full SCTP). - Attribut RECONNECT : si égal à YES, l’application essaie de se reconnecter au distant si la connection est perdue.
Exemple: <TRANSPORT MODE="MULTI" ROLE="SERVER" PROTOCOL="TCP" RECONNECT="YES"/>
<INCLUDE_DIRECTORY> 0 ou plus: contient un répertoire ou se trouvent des fichiers source, paramètre libre non utilise actuellement (réservé pour les couches applicatives supérieures).
Exemple: <INCLUDE_DIRECTORY>C:\tulip/source</INCLUDE_DIRECTORY>
<INTERNAL_ROUTER> : section contenant les critères de routage applicatif. Elle contient une ou plusieurs balises <CRITERIA>. Une balise <CRITERIA> contient le nom du critère, spécifique au mode choisi (ex, CONTEXT).
<AGENTS> : cette section contient les déclarations de traffic agents utilisés dans le test. Chaque déclaration contient l’attribut TYPE, qui permet de spécifier le type de configuration du test (voir section dédiée). Chaque déclaration dépend du mode choisi, et est de la forme : <AGENT_nom_mode att1="valAtt1" att2="valAtt2" att3="valAtt3" …/>
Exemple : <AGENT_MEGACO TYPE="CALLER" TERM="P/1" ND="02420001"/>
Les agents de test sont déclarés de manière générique : <!ELEMENT AGENT_TEST> <!ATTLIST AGENT_TEST TYPE (CALLER | CALLED | MGC | OTHER | POOL) ID ID >
Selon la configuration de test choisi (ex, CALLER+CALLED), les agents sont couplés dans l’ordre de déclaration. Ainsi, le nème agent de type CALLER est associé au nème agent de type CALLED.
<DECLARE> : section optionnelle de déclaration de constantes/variables.
- <VARIABLE> : déclaration d’une variable, l’attribut "NAME" contient le nom de la variable (unique), l’attribut "TYPE" contient le type de la variable, et enfin l’attribut "VALUE" correspond à la valeur de la variable (au format texte ou hexa). Voir la section dédiée pour plus de détails. - <CONSTANT> : déclaration d’une constante, l’attribut "NAME" contient le nom de la constante, le champ "VALUE" contient sa valeur. Lors de la compilation, les constantes sont remplacées par leur valeur.
Exemple : <DECLARE> <CONSTANT NAME="IP_TULIP" VALUE="10.40.20.40"/> <CONSTANT NAME="IP_MGC" VALUE="10.40.20.41"/> <VARIABLE NAME="nb_calls" TYPE="INTEGER" VALUE="0"/> </DECLARE>
<COLLECTOR> : élément déclarant la collecte de statistiques et positionnant certains attributs. Il contient plusieurs attributs : - ALL_AGENTS: si positionné à YES, la somme des compteurs est affichée. - AGENT_SUMMARY: si positionné à YES, tulip réalise la somme de tous les compteurs de faute pour chaque agent. - AGENT_DETAIL: si positionné à YES, tulip affiche tous les compteurs de faute par agent (tous les types). - LOG_ANALYSIS: si positionné à YES, tulip active la réalisation d’analyse statistique de traffic. - RESPONDER_LOG: si positionné à YES, les statistiques sont également collectées pour le responder (+ test responder). - PERIOD : périodicité de l’émission de statistiques.
Exemple : <COLLECTOR ALL_AGENTS="YES" AGENT_SUMMARY="NO" AGENT_DETAIL="NO" LOG_ANALYSIS="NO" RESPONDER_LOG="NO" PERIOD="20"/>
<SCHEDULER> : élément déclarant les paramètres de trafic.
- INTERSIMU : nombre d’unité de temps entre chaque appel. - UNIT : unité de temps, S ou MS (secondes ou millisecondes). - SIMULTANEOUS : nombre d’agents lancés simultanément à chaque intervalle de temps. - PERIODS : nombre d’appel avant la fin du trafic. Quand ce nombre est atteint, l’application s’arrête. Par défaut, égal à 0 (illimité).
Exemple : <SCHEDULER INTERSIMU="30" UNIT="MS" SIMULTANEOUS="4"/>
<COMMANDER>: élément instanciant un commander. Celui-ci peut être de trois types, comme positionné par l’attribut "MODE".
LOCAL : commander prenant comme entrée le clavier. Ce mode permet le contrôle interactif d’une instance tulip. Dans ce cas, seul l’attribut "NAME" est utilisé pour identifier l’instance en cours. REMOTE : commander réseau maître, situé sur une autre machine. Dans ce cas, l’instance tulip est contrôlée par une autre instance du réseau. Le FQDN distant (fully qualified domain name) ou l’IP distante, est contenu dans l’attribut « HOST». L’attribut « PORT » contient le port TCP local. L’attribut "NAME" n’est pas utilisé. Les attributs LOG + STATS permettent de rediriger les flux de log ou statistiques vers le commander réseau, ou de garder la sortie locale. SERVER : commander réseau esclave, situé sur une autre machine. Les champs HOST/PORT identifient l’adresse réseau/port du commander. L’attribut "NAME" identifie le commander réseau. Les attributs LOG/STATS ne sont pas utilisés.
Exemple : <COMMANDER MODE="SERVER" HOST="172.16.14.13" PORT="1982" NAME="COMMANDER1"/> <COMMANDER MODE="LOCAL"/>
|
| Configuration |
|
 |
