concevoir et developper un systeme automatise pour tester flamingo xl l

Université nationale du Vietnam, Hanoi
INSTITUT FRANCOPHONE INTERNATIONAL

PENTALOG

Concevoir et développer
un système automatisé pour tester
Flamingo XL
Mémoire présenté en vue de l'obtention du grade Master
informatique, Spécialité "Réseaux et Systèmes Communicants" de
l'Université Nationale du Vietnam, Hanoi.

Réalisé par
Anna SAELEE
Promotion 17, option RSC

Encadres par
NGUYEN Manh Tuong
LE THI THU Hoa


Remerciements
Je tiens `a remercier mes encadreurs, monsieur NGUYEN Manh Tuong, le directeur du Pentalog a` Hanoi, et Madame LE THI THU Hoa, le chef du projet pour
ses disponibilit´es et ses conseils. Ils m’aidaient toujours a` passer tous les moments
difficiles et m’ont guid´e a` aller dans la bonne direction du projet.
Je voudrais remercier monsieur Victor Moraru qui m‘a conseill´e de faire le
stage chez Pentalog.
Je tiens ´egalement a` remercier tous les coll`egues du Pentalog qui m’ont appris
les informations du projet et m’ont support´e `a ˆetre confortable pendant la p´eriode du
stage, et mes amis, qui m’ont aid´e avec des conseils, des remarques et des critiques.

R´
esum´
e
Actuellement, l’informatique a beaucoup d’int´erˆet dans la vie quotidienne, par
exemple : la communication, la distribution des nouvelles et l’´education, etc. Il existe
pas mal de technologies afin de bien profiter de ces int´erˆets : des sites web, des
applications mobile, etc. Pour avoir la garantie de logiciel, le processus du test est
appliqu´e dans le projet du d´eveloppement de logiciel.
Le site web est un moyen qu’on utilise pour diffuser des informations a` tout le
monde a` travers l’Internet, donc le test `a la main est suffit en raison de v´erifier des
contenus affich´es. Comme l’informatique n’est jamais rester immobile, l’application
Web a ´et´e cr´e´e pour qu’un utilisateur peut interagir avec le site web plus que la
lecture des informations. Autrement dit que le test devient un processus important
pour garantir la qualit´e de l’application Web.
Afin de tester un logiciel, nous avons diff´erents m´ethodes comme le test unitaire, le test d’int´egration, etc. Pourtant, le test du site web peut ˆetre faire `a la main.
Comme le test dans la fa¸con d’humain peut avoir des erreurs et prend beaucoup de
temps, pour cette raison le test d’automatisation du web a ´et´e d´evelopp´e.
Dans ce travail, nous avons le but de cr´eer des scripts pour le test d’automatisation du web sur le produit Flamingo XL d’Anevia. Ces scripts doivent ˆetre r´eutiliser
dans l’avenir. En plus, le nombre du scripts r´eussis dois ˆetre au minimal de 80% des
cas de test total.


Abstract
Today, Information Technology (IT) has a lot of interest in daily life, such
as : the communication, the distribution of news and the education, etc.
There are a lot of technologies in order to benefit these interests : websites,
mobile applications, etc. For the software warranty, the test process is
applied in the software development project.
The website is one way we use to distribute information to everyone

through the Internet, so the test by hand is simply due to check the
displayed content. As IT is never standing still, the web application was
created for a user can interact with the website more than reading the information. In other words that why the test becomes an important process
to ensure the quality of the Web application.
To test the software, we have different methods such as the unit test,
integration testing, etc. However, the test of the website can be done
manually. As the test in the human’s way may have the error and may
take a long time, a web automation test was developed.
In this work, we have to create scripts for the web automation test on
a product of Anevia, Flamingo XL. These scripts must be reused in the
future. In addition, the number of successful scripts have to be at minimum
80% of the total test.


Table des mati`
eres
1 Introduction
1.1 Anevia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
2

1.2

Flamingo XL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

Contexte du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.4

Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2 Bibliographie

4

2.1

IPTV

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2
2.3

Flux de transport MPEG2 . . . . . . . . . . . . . . . . . . . . . . . .
Packet sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6
9

2.4

Testerman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.5

Test d’automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3 Conception et Impl´
ementation
3.1 Conception du projet . . . . . . . . . . . . . . . . . . . . . . . . . . .

18
18

3.2

Impl´ementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4 Exp´
erimentation

33

5 Conclusion et Perspective
5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36
36

5.2

Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

A Exemple du biblioth`
eque

38

B Exemple des scripts ATS

42

C Exemple du codage de Selenium Webdriver

45

Bibliography

47

i


Table des figures
2.1
2.2

Architecture du syst`eme IPTV . . . . . . . . . . . . . . . . . . . . . . .

Architecture point-`a-point de IPTV . . . . . . . . . . . . . . . . . . .

5
6

2.3

Tableau de Programme d’Information Sp´ecifique (PSI) . . . . . . . .

7

2.4

Tableau de l’Association de Programme (PAT) . . . . . . . . . . . . .

8

2.5
2.6

Tableau de la Carte de Programme (PMT) . . . . . . . . . . . . . . .

Tableau de l’Acc`es Conditionnel (CAT) . . . . . . . . . . . . . . . . .

8
8

2.7

Infrastructure de Testerman . . . . . . . . . . . . . . . . . . . . . . . .

12

2.8

M´ethodes de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.1

Services de Flamingo XL . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.2

Fenˆetre de Qtesterman . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.3

3.4

Exemple de la biblioth`eque utilis´e dans le projet . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

29
30

4.1

Architecture du syst`eme IPTV . . . . . . . . . . . . . . . . . . . . . . .

34

Diagramme de d´eveloppement d’un script ATS

ii


Chapitre 1
Introduction
Aujourd’hui, l’Internet est connu par tout le monde. Chaque personne l’utilise
pour diff´erent but, comme les ´etudes, les travaux et les divertissements, etc. Pour
ces raisons, l’application Web a ´et´e d´evelopp´ee afin de r´epondre aux besoins des
utilisateurs.
Actuellement, il existe de nombreuses applications Web, qui sont souvent utilis´es pour acc´eder a` des services a` distant. Parmi ces applications Web, il y en a des
sites-web qui exigent d’avoir un haut niveau de s´ecurit´e, une correction des donn´ees et
une consistance des informations, etc. par exemple : le site E-commerce, le site de la
banque, etc. Par cons´equent, le test devient tr`es important pour ce genre d’application

Web.
Normalement, le test d’application Web se fait par les humains. C’est-`a-dire,
ils testent l’application a` la main. En cons´equence, il y a une forte possibilit´e qu’ils
fassent des erreurs ou ne respectent pas l’enchaˆınement des ´etapes de test. Pour ces
raisons, l’utilisation de test d’automatisation est d´evelopp´e. Ce test utilise des scripts
afin de v´erifier des fonctionnalit´es et la qualit´e de l’application Web, comme : le temps
d’attente est acceptable, la vue de page est correct dans diff´erent navigateur Web,
etc.
Un des services qu’on peut adapter avec l’application Web est la distribution
des chaˆınes TV. Celle-l`a diffuse le multim´edia (l’audio et le vid´eo) sur l’adresse IP. En
plus, on peut aussi distribuer des chaˆınes de satellite vers le r´eseau local. Donc, on n’a
pas besoins d’installer pleins d’´equipements pour pouvoir regarder des chaˆınes diffus´es
par le satellite. Cette technologie est appel´ee IPTV (Internet Protocol Television) et
OTT (Over-The-Top TV).

1


1.1

Anevia
En 2003, Anevia est l’un des leader dans la cr´eation de l’infrastructure de

logicielles pour la diffusion de la t´el´evision en direct et `a la demande. Les produits
d’Anevia ont ´et´e d´eploy´es avec succ`es sur diff´erents march´es tels que les m´edias, les
op´erateurs t´el´ecom Tier-1 et Tier-2 et dans de nombreuses entreprises priv´ees ou
publiques.
Anevia a commenc´e le d´eveloppement de Vid´eo dans le syst`eme CDN (Content
Delivery Networks) qui offrent aux t´el´espectateurs la libert´e de choisir ce qu’ils veulent
regarder `a la t´el´evision, partout et a` tout moment. Les solutions d’Anevia rendent

les CDNs plus efficaces, tout en permettant aux op´erateurs de r´eduire le stockage
et la bande passante. Ces solutions sont par nature con¸cues pour offrir la meilleure
exp´erience multi-´ecrans (NPVR, Timeshifting , OTT et/ou IPTV) `a tous les utilisateurs.
Sur le march´e d’entreprise, les produits d’Anevia ont ´et´e d´eploy´es sur tous les
continents par des centaines d’hˆotels, d’´etablissements, d’enseignement, de soci´et´es
priv´ees, etc. qui souhaitent diffuser de la vid´eo en direct et `a la demande.

1.2

Flamingo XL

Flamingo XL est l’un des produits d’Anevia qui est d´edi´e au march´e d’hospitalit´e (hˆopitaux, hˆotels). Les solutions propos´ees permettent de diffuser sur le r´eseau
local `a la fois la t´el´evision en direct et les contenus enregistr´es. Apr`es avoir re¸cu le signal TV et celui de la radio en direct par satellite, par cˆable et num´erique terrestre, le
Flamingo XL les transf`ere sur des r´eseaux IP pour les ordinateurs, les set-top boxes,
les t´el´eviseurs modernes et toute autre appareil avec un acc`es r´eseau qui est reli´e
avec le Flamingo XL. Nous pouvons se connecter a` l’interface Web et de piloter le
Flamingo XL en utilisant la connexion SSH.

1.3

Contexte du travail
Pour assurer la qualit´e du Flamingo XL, le test d’automatisation est adapt´e

dans le projet. Le script cr´e´e dans ce projet doit ˆetre r´eutiliser dans l’avenir afin
de minimiser le temps du test. Le langage sp´ecifique du projet est le Python. Les
outils sp´ecifiques du projet sont le Testerman et le Selenium-RC. Ces deux outils permettent de cr´eer des tests automatis´es avec l’application Web ; le Testerman est l’outil

2

principal qui g`ere l’ex´ecution du test d’automatisation, et le Selenium-RC fonctionne
comme un sonde permettant de lancer le test sur l’application Web.
Le d´eveloppement du projet est divis´e en
1. Compr´
ehension du produit : Pour mieux comprendre et d´evelopper les
scripts de test d’automatisation, nous devons bien comprendre les fonctionnalit´es et les services fournit par le produit sous test.
2. V´
erification des cas de test : Apr`es avoir bien compris le produit, nous
devons v´erifier les cas de test reli´es avec ce produit. Comme il existe plusieurs
version de produit, donc nous devons valider les ´etapes dans les cas de test en
raison d’assurer la coh´erence entre le produit sous test et les cas de test utilis´es.
S’il y a beaucoup de diff´erent, il faut mettre `a jour les cas de test.
3. Conception de la structure du codage : Pour que le codage du projet
sera bien saisi par tout le monde dans l’´equipe, il est n´ecessaire de concevoir
la structure des biblioth`eques et des scripts de test. Ce-l`a peut nous aider a`
augmenter la qualit´e du codage, par exemple : ´eviter la duplication de la mˆeme
fonctionnalit´e dans une biblioth`eque.
4. Installation des outils : Nous faisons la pr´eparation de l’ordinateur, comme
l’installation de plug-in Firebug et FirePath dans le navigateur Firefox, etc.
5. D´
eveloppement des biblioth`
eques et des scripts de test d’automatisation : Nous devons d´evelopper les biblioth`eques en Python avant de les d´eployer
dans les scripts de test d’automatisation.

1.4

Probl´
ematique

L’objectif g´en´eral du projet est de transformer le cas de test du Flamingo

XL environ 80% a` utiliser les scripts du test d’automatisation. Pourtant, ces scripts
doivent ˆetre r´eutiliser avec d’autres produits dans la famille de Flamingo (diff´erente
version ou plate-forme). Parfois, nous ne pouvons pas transformer le cas de test en
script parce qu’il pourra provoquer des probl`emes, par exemple : on peut simuler
la rupture de la connexion avec la commande ”sudo ifconfig eth0 down”, mais cette
commande peut inciter un probl`eme de connexion sur le serveur. C’est-`a-dire, on ne
peut pas r´etablir la connexion avec la commande a` distance. Donc, il faut ´eviter de
transf´erer le cas de test comme ¸ca en script.

3


Chapitre 2
Bibliographie
Dans cette partie, nous d´ecrivons les informations reli´ee au test d’automatisation dans le domaine du streaming. Premi`erement, nous commen¸cons par pr´esenter
le protocole IPTV qui nous permet de diffuser la vid´eo de satellite vers le r´eseau.
Deuxi`emement, nous montrons les informations du flux de transport MPEG2 (TS
MPEG2). Troisi`e-mement, nous abordons les outils de capture des trames. Quatri`emement, on pr´esente l’outil principal du projet qui nous permet de faire le test
d’automatisation, le Testerman. Enfin, nous discutons sur les logiciels permettant de
tester des applications Web.

2.1

IPTV
Dans [15], IPTV signifie ”Internet Protocol Television”, et n’importe quel utili-

sateur avec un outil IP ,comme le smartphone peut obtenir le service IPTV n’importe
o`
u et a` tout moment, tant que l’utilisateur peut acc´eder `a l’Internet.
Les architectures de syst`eme IPTV sont pr´esent´es dans la figure 2.1. Cette

derni`ere illustre les principaux composants d’un syst`eme IPTV :
1. Les serveurs d’acquisition : ils codent la vid´eo et ajoutent des m´etadonn´ees de
gestion des droits num´eriques (Digital Rights Management : DRM)
2. Les serveurs de distribution : ils fournissent la mise en cache et la QoS contrˆole.
3. Les cr´eateurs de la vid´eo a` la demande (VoD) et les serveurs : ils conservent
une biblioth`eque de contenus VoD cod´e pour fournir des services de VoD.
4. Les routeurs IP : ils acheminent les paquets IP et r´eacheminent rapidement les
paquets en cas de d´efaillance de routage.

4


Figure 2.1: Architecture du syst`eme IPTV

5. Set-Top-Box (STB) : STB est un appareil du cˆot´e client qui interagit avec le
terminal de l’utilisateur, par exemple : la t´el´evision, l’ordinateur, le t´el´ephone
portable, etc. avec le ”Digital Subscriber Line” (DSL) ou avec le cˆable.

IPTV et multidiffusion IP
La multidiffusion IP est une m´ethode d’envoi des paquets a` un groupe d’IP,
qui sont les r´ecepteurs int´eress´es. Cette m´ethode utilise l’infrastructure du r´eseau de
mani`ere efficace, tout en exigeant la source afin d’envoyer un paquet seulement une
fois, mˆeme si elle doit ˆetre d´elivr´e a` un grand nombre de r´ecepteurs.

Architecture point-`
a-point de IPTV
Pour une distribution IPTV point-`a-point (P2P), il y a une source et un groupe
de pairs regardant la vid´eo. Nous nous r´ef´erons `a la souquirce et le groupe de pairs
comme un torrent. La source encode la vid´eo et diffuse les paquets vid´eo dans le torrent
de P2P. Chaque poste re¸coit des paquets provenant de la source et/ou d’autres pairs

comme la montre la figure ci-dessous.
5


Figure 2.2: Architecture point-`a-point de IPTV

2.2

Flux de transport MPEG2
Le flux de transport (Transport Stream : TS) est un format sp´ecifi´e dans

MPEG-2 Partie 1, syst`eme (norme ISO / CEI 13818-1). TS MPEG2 a une conception
qui permet le multiplexage de la vid´eo num´erique et l’audio afin de synchroniser la
sortie. TS MPEG2 offre des fonctionnalit´es de correction d’erreur pour le transport sur
les m´edias peu fiables, et il est utilis´e dans des applications de diffusion tels que DVB
(Digital Video Broadcasting) 1 et ATSC (Advanced Television Systems Committee) 2
[3].
Un paquet est l’unit´e de base de donn´ees dans un TS MPEG2. Il se compose
d’un octet de synchronisation dont la valeur est 0x47, suivi par trois drapeaux d’un
1. un ensemble de normes de t´el´evision num´erique ´edict´ees par le consortium europ´een DVB, et
utilis´ees dans un grand nombre de pays
2. le groupe, cr´e´e en 1982, qui a d´evelopp´e les normes ATSC pour la t´el´evision num´erique aux
´
Etats-Unis,
´egalement adopt´ee par le Canada, le Mexique, la Cor´ee du Sud, et r´ecemment au Honduras et est consid´er´e par d’autres pays

6


bit et un PID `a 13 bits. Ceci est suivi par un compteur de continuit´e a` 4 bits, qui est

g´en´eralement incr´ement´e avec chaque paquet ult´erieur d’une trame, et peut ˆetre utilis´e
pour d´etecter les paquets manquants. Les champs de transport suppl´ementaires, dont
la pr´esence peut ˆetre signal´ee dans le champ d’adaptation optionnel, peuvent suivre.
Le reste du paquet est constitu´e de charge utile. La longueur des paquets est souvent
de 188 octets, mais il existe aussi des TS de 204 octets qui se terminent dans 16 octets
de donn´ees de Reed-Solomon de correction d’erreur.

Programme d’Information Sp´
ecifique (PSI)
Le Programme d’Information Sp´ecifique (Program Specific Information : PSI)
repr´esente les donn´ees MPEG 2 qui identifient les parties du flux de transport appartenant a` un programme particulier.

Figure 2.3: Tableau de Programme d’Information Sp´ecifique (PSI)
Les informations transport´ees dans un certain nombre de tables PSI sont les
suivantes :
1. Tableau d’Association de Programme (Program Association Table :
PAT) (obligatoire) : PAT est le premier arrˆet du d´ecodeur, qui essaye de localiser un programme. Le d´ecodeur trouve rapidement le PAT, car il se trouve
toujours sur le PID 0x0000. Le PAT fournit le d´ecodeur avec une carte pour
chaque programme dans le TS. Cette carte est contenue dans le PMT (Program
Map Table) pour chaque programme. Il informe le d´ecodeur de la valeur PID
pour les paquets contenant le PMT pour chaque programme. En plus, le PAT
7


peut ´egalement contenir la valeur PID des paquets contenant le NIT (Network
Information Table).

Figure 2.4: Tableau de l’Association de Programme (PAT)
2. Tableau de la Carte de Programme (Program Map Table : PMT) (obligatoire) : chaque PMT d´efinie un programme sp´ecifique en listant des PIDs pour
les paquets contenant les composants audio, vid´eo et donn´ees du programme.

Avec cette information. Grˆace au PMT, le d´ecodeur peut facilement localiser,
d´ecoder et afficher le contenu du programme.

Figure 2.5: Tableau de la Carte de Programme (PMT)
3. Tableau de l’Acc`
es Conditionnel (Conditional Access Table : CAT)
(optionnel) : la syntaxe MPEG-2 permet aux diffuseurs de transmettre des informations confidentielles d’acc`es conditionnel dans le flux de transport sous la
forme d’EMM (Entitlement Management Message) 1 . Le CAT se trouve toujours
sur PID 0x0001. Il informe le d´ecodeur o`
u il peut trouver l’EMM dans le flux
de transport en listant la valeur PID pour chaque paquet contenant l’EMM.

Figure 2.6: Tableau de l’Acc`es Conditionnel (CAT)
1. le message dans le flux de transport utilis´e pour mettre `a jour les options d’abonnement ou
”pay-per-view” droits pour un abonn´e individuel ou pour un groupe d’abonn´es

8


4. Tableau de l’Information de R´
eseau (Network Information Table :
NIT) (optionnel) : NIT fournit des informations d’un r´eseau sur lequel diff´erents
flux de transport r´esident. Il donne acc`es a` d’autres flux de transport.

2.3

Packet sniffer
Le Packet Sniffer est un programme fonctionnant dans un appareil connect´e

au r´eseau qui re¸coit passivement toutes les trames de la couche de liaison de donn´ees

en passant par la carte r´eseau. Il est ´egalement connu sous le nom de l’analyseur de
r´eseau (Ethernet Sniffer) [10].
Chaque machine sur un r´eseau local dispose de sa propre adresse mat´erielle qui
se distingue des autres machines. Quand un paquet est envoy´e, il sera transmis `a toutes
les machines disponibles sur le r´eseau local. En raison du principe de partage Ethernet,
tous les ordinateurs dans le mˆeme r´eseau local peuvent voir le trafic passant a` travers
ce r´eseau. Ces ordinateurs ignorent les paquets dont ils ne sont pas responsable.

Tcpdump
”Tcpdump” est un analyseur de paquets commun qui fonctionne sous la ligne
de commande. Il permet `a l’utilisateur d’intercepter et d’afficher TCP/IP et d’autres
paquets qui sont transmises ou re¸cues sur un r´eseau auquel l’ordinateur est connect´e.
”Tcpdump” fonctionne sur la plupart des syst`emes d’exploitation de type Unix. Dans
ces syst`emes, ”tcpdump” utilise la biblioth`eque libpcap pour capturer les paquets.

Pyshark
[5] Pyshark est python wrapper pour tshark. Il permet au Python d’analyser
les paquets en utilisant Wireshark. Il existe quelques modules d’analyse de paquets
de Python, celui-ci est diff´erent parce qu’il ne fait pas une analyse tous les paquets,
il utilise simplement la capacit´e de tshark pour exporter XMLs afin d’analyser les
paquets. Ce package permet l’analyse d’un fichier de capture ou une capture vivante,
et il est disponible sur Windows/Linux.

9


2.4

Testerman

TTCN-3
”Testing and Test Control Notation version 3” (TTCN-3) est un langage de
test d´evelopp´e par ETSI (European Telecommunications Standards Institute). La
notation ressemble `a des langages de programmation et elle est sp´ecialement d´edi´ee
au d´eveloppement de tests des protocoles de communication. TTCN-3 prend une
approche tr`es universelle en se lib´erant compl`etement du syst`eme sous test (System
Under Test, SUT). Le mˆeme cas de test peut ˆetre ex´ecut´e dans des environnements
bien diff´erents. Des adaptateurs servent d’interm´ediaire entre le script de test abstrait
et le SUT. Quelques caract´eristiques principales sont : un syst`eme de typage fort,
d´efinition des tests concurrents (des tests avec plusieurs composants), support d’une
communication synchrone ou asynchrone, support de timers et une facilit´e d’ex´ecution
automatique. L’industrie a approuv´e l’utilisabilit´e du standard. Il a ´et´e employ´e pour
le d´eveloppement de test de conformit´e dans des domaines diff´erents comme VoIP,
IPv6, Digital Mobile Radio, WiMax, LTE, etc. TTCN-3 est surtout utilis´e dans le
domaine de la communication mais peut ˆetre adopt´e pour les tests unitaires (logiciels)
ou les syst`emes distribu´es. Il existe plusieurs outils open source et commerciaux autour
de TTCN-3.

Testerman
Dans [2] explique que le Testerman est Open Source/Logiciel libre sous licence
GNU (General Public License) la version 2. Il est une tentative de produire un test
de syst`eme d’automatisation TTCN-3 inspir´e sans le strict mod`ele de la notation
de contrˆole TTCN-3. Ceci est r´ealis´e en mettant les primitives de TTCN-3 avec les
concepts du langage de programmation Python.
Testerman fournit un environnement complet pour concevoir, g´erer, ex´ecuter
et analyser les tests automatis´es. Il est peut-ˆetre utilis´e comme une plate-forme pour
d´evelopper des simulateurs de test (pilotes et stubs) et des prototypes d’applications
de r´eseau. Il se concentre sur la fourniture de toute la base n´ecessaire pour effectuer
des tests d’applications de bout en bout bas´ees sur le r´eseau de protocoles multiples.
En particulier, il a ´et´e con¸cu avec les plate-formes de t´el´ecommunications `a l’esprit,

comme ceux bas´es sur VoIP / IMS.
Testerman a ´et´e con¸cu pour ˆetre multi-utilisateur (client-serveur) avec un
d´epˆot centralis´e des cas de test. Il est adaptable a` la plupart des topologies SUT,
les contraintes de r´eseau, et extensible (adaptateurs de test/syst`eme peuvent ˆetre
10


d´evelopp´es facilement, en n’importe quelle langage).
Utilisateur (Client)
Les utilisateurs interagissent avec le syst`eme `a travers un client de Testerman.
Plusieurs clients peuvent se connecter au mˆeme serveur et ils sont capable de partager
le mˆeme r´ef´erentiel d’ATS et les mˆemes ressources techniques. Actuellement, les clients
suivants sont disponibles :
1. un client d’interface de ligne de commande : il peut ˆetre utilis´e pour appeler les
ex´ecutions de la suite de tests `a partir d’un script shell, ou un Makefile.
2. une multi-plate-forme : nomm´e QTesterman qui fournit un IDE pour concevoir,
ex´ecuter, contrˆoler et analyser les suites de test.
3. un client Web lightweigth : il est limit´e `a l’ex´ecution des tests et obtenir leurs
r´esultats et les journaux. Ce client peut ˆetre publi´e comme un front-end pour
vos clients dans une DMZ.
Composants du serveur
Le serveur est divis´e en deux composantes :
1. Le serveur Testerman : un front-end pour les clients qui est responsables de la
cr´eation, de l’ex´ecution et de contrˆole de test ex´ecutables (TE) d’une source
ATS ´ecrit par l’utilisateur. Il est ´egalement en mesure de pousser les mises `a
jour pour les clients ayant mis en œuvre la mises a` jour automatiques, tels que
QTesterman.
2. Le serveur contrˆoleur de l’agent Testerman (TACS) : est un processus responsable de la gestion des agents et sondes de sorte que les TE peut les utiliser en
cas de besoin lors de l’ex´ecution a` distance. Le TACS peut ˆetre install´e sur une
autre machine que la Testerman Server et partag´e entre plusieurs serveurs.

Sonde (Probe)
Une ”probe” est le mot pour appeler un adaptateur de test (un adaptateur
syst`eme). Elle peut effectivement se connecter a` un SUT (Syst`eme sous test) en
utilisant diff´erents protocoles comme TCP, UDP, SOAP, etc.
Testerman fournit un ensemble de sondes, qui sont capable d’interagir avec le
SUT, et ´egalement avec la simulation des actions de l’utilisateur ou d’autres actions
n´ecessaires pour automatiser un test.

11


Figure 2.7: Infrastructure de Testerman

12


Les sondes peuvent ˆetre g´er´es par le TE lui-mˆeme. Il sont en cours d’ex´ecuter
sur le serveur Testerman et d’initier ou d’attendre les connexions r´eseau sur les interfaces IP du serveur Testerman, ou peut ˆetre ex´ecut´e sur n’importe quel syst`eme
distant. Dans ce cas, ils doivent ˆetre h´eberg´es sur un agent Testerman afin de g´erer
les communications de bas niveau avec le serveur de contrˆoleur de l’agent Testerman
(TACS).
Les agents doivent ˆetre d´eploy´es manuellement par le testeur, c’est-`a-dire ils
doivent ˆetre install´es et d´emarr´es. Cependant, une fois d´eploy´e, un agent peut ˆetre
utilis´e par n’importe quel TE, afin de d´eployer dynamiquement n’importe quel nombre
de sondes en fonction de sa configuration d’adaptateur de test d´efinie.
Cette architecture permet de distribuer les sondes n’importe o`
u dans le r´eseau,
soit a` l’int´erieur du SUT ou autour du SUT lui-mˆeme. Ceci permet d’obtenir plusieurs
avantages :
1. Nous pouvons stimuler le SUT avec n’importe quelle adresse IP, il y a pas de

limite `a ceux du serveur.
2. Nous pouvons installer un agent sur les SUT eux-mˆemes. Nous pouvons aussi
ex´ecuter des commandes sur le SUT, ou observer les ´ev´enements qui se produisent a` l’int´erieur du SUT, par exemple : les mises `a jour de journaux, les
cr´eations de fichiers, les cr´eations des processus enfants, etc
3. Nous pouvons mettre en œuvre des sondes dans n’importe quelle langage, en
fournissant un agent existant. C’est-`a-dire, on n’est pas limit´e a` Python mais on
peut choisir le meilleur langage de mise en œuvre de notre sonde en fonction de
nos comp´etences ou des biblioth`eques disponibles dans le langage. Si on n’utilise pas le Python, cependant, nos sondes ne seront pas en mesure d’ex´ecuter
localement avec le TE et auront besoin d’un agent pour les accueillir.
Pour l’instant, la mise en œuvre de l’agent Testerman disponible est ´ecrit en
Python (PyAgent), et il peut accueillir toutes les sondes qui peuvent ´egalement ˆetre
ex´ecut´ees localement par le TE. Cette PyAgent peut ´egalement ˆetre mis `a jour `a
distance `a partir de TAC et de serveur de Testerman.

2.5

Test d’automatisation

Les tests de logiciels est une phase essentielle du cycle de vie des logiciels dans
le d´eveloppement afin d’´evaluer des fonctionnalit´es d’un logiciel. Dans le domaine des

13


tests de logiciels, il existe plusieurs m´ethodes qui sont divis´es en 3 cat´egories :

Figure 2.8: M´ethodes de tests
1. Les tests statiques et les tests dynamiques
Les diff´erences entre ces deux tests sont pr´esent´es dans le tableau suivant :
Tests statiques

R´ealis´e sans l’ex´ecution du programme
R´ealis´e avant la compilation
Le but est de pr´evenir des anomalies

Tests dynamiques
R´ealis´e par l’ex´ecution du programme
R´ealis´e apr`es compilation
Le but est de trouver et corriger les
d´efauts
C’est le processus de validation

C’est le processus de v´erification
2. L’approche de la boˆıte

L’approche de la boˆıte est divis´ee en 2 types diff´erents :
Boˆıte blanche
Les tests de fonctionnalit´es
Pas besoins de savoir le fonctionnement
interne d’une application

Boˆıte noire
Les tests de codages
Le testeur a besoin d’avoir une connaissance compl`ete du fonctionnement interne de l’application
Normalement r´ealis´e par les testeurs et
les d´eveloppeurs
Convient a` l’algorithme des tests
Utilises plus de temps

Le test est r´ealis´e par les utilisateurs finaux, les testeurs et les d´eveloppeurs
Ne convient pas `a l’algorithme des tests

Utilises moins de temps

14


3. Le test manuel et le test d’automatisation
Les diff´erences entre le test manuel et le test d’automatisation sont d´ecrits dans
le tableau suivant :
Test manuel
L’ex´ecution est lente
Plus nombre de testeurs
Pas de programmation peut ˆetre fait
pour ´ecrire des tests compliqu´es qui vont
chercher l’information cach´ee
Test manuel est moins fiable car les
tests ne peuvent pas ˆetre r´ealis´es avec
pr´ecision a` chaque fois `a cause des erreurs humain

Test d’automatisation
L’ex´ecution est plus rapide
Moins nombre de testeurs
Les testeurs peuvent programmer des
tests complexes pour faire ressortir des
informations cach´ees
Tests d’automatisation est plus fiable et
moins des erreurs

Aujourd’hui, il existe de nombreuses applications qui sont ´ecrites comme des
sites Web. Pour tester ces applications, nous pouvons utiliser des outils de test d’automatisation afin de minimiser le coˆ
ut et le temps. Dans [12] montre qu’il existe plusieurs

outils de test d’automatisation et dans [14] repr´esente des r´esultats de performances
de 2 outils int´eressants : Selenium et Watir.

Selenium
”Selenium” est un des outils open-source pour les tests d’automatisation qui
fournit un framework de test pour tester une vari´et´e d’applications dans presque
toutes les langages. Son principale caract´eristique est l’ex´ecution de cas de test sur
multi-navigateur. Il existe 3 types diff´erents de Selenium :
1. Selenium IDE, qui est utilis´e uniquement dans Firefox comme plug-in.
2. Selenium RC, qui prend en charge plusieurs navigateurs et les scripts dans
des langages diff´erents.
3. S´
el´
enium Web Driver, qui prend en charge tous les navigateurs pour l’ex´ecution
de test.

Watir
Watir est un ensemble de biblioth`eques Open Source Ruby publi´e sous licence
BSD afin de tester les diff´erentes applications bas´ees sur le Web. Il se compose des
composants suivants :

15


1. Watir-Classic, fonctionne sur la liaison d’objet et l’int´egration (Object Linking
& Embedding).
2. Watir-WebDriver, est la mise en œuvre de tester des fonctionnalit´es par watir.
Il fonctionne comme une API impl´ement´e en utilisant la sp´ecification HTML
qui est compatible avec une grande vari´et´e de standards du W3C.
3. Watir-Spec, est une sp´ecification ex´ecutable pour l’API de Watir.

Comparasion entre Selenium et Watir
Pour comparer la performance entre le Selenium et le Watir, le travail [14] a
soulev´e les diff´erents facteurs permettant de mesurer ces deux outils :
1. Capacit´
e d’enregistrement : d´efinit l’efficacit´e de l’outil dans le terme de la
capacit´e d’enregistrement des cas de test.
2. G´
en´
eration de scripts : d´efinit la capacit´e de l’outil `a soutenir de nombreux
langages dans lesquels le code peut ˆetre export´e.
3. Test des donn´
ees : comprend le test avec un ensemble de donn´ees vari´es qui
peut ˆetre importer `a partir du fichier. En plus, ce test peut ˆetre r´eutiliser dans
le futur.
4. Facilit´
e d’apprentissage : la facilit´e de la compr´ehension du fonctionnement
des logiciels de test est v´erifi´ee sur la base de 3 param`etres ; l’accessibilit´e, les
caract´eristiques de l’interface d’utilisateur et le manuel.
5. Rapport de test : est pr´esent´e dans un format bien structur´e o`
u nous nous
sommes en mesure de comprendre ce que l’outil de test veut illustrer.
6. Fonctionnalit´
es suppl´
ementaires : le coˆ
ut est l’un des facteurs important
quand il s’agit de la comparaison des diff´erents fournisseurs ou les mˆemes fournisseurs entre des produits diff´erents et peut ˆetre vu comme seul crit`ere dans
certains cas.
Les r´esultats de la comparaison obtenus sont diff´erents dans chaque facteur.
Premi`erement, la capacit´e d’enregistrement, le Selenium est plus efficace que le Watir

parce qu’il soutien plusieurs fonctions sans avoir recours a` d’autre plugin. Deuxi`emement,
la g´en´eration de scripts, comme le Selenium est capable d’exporter le code en langage
vari´e donc il est mieux que le Watir. Troisi`emement, le test des donn´ees, le Selenium et le Watir gagnent presque la mˆeme position, sauf le Selenium fournit l’acc`es `a
une vari´et´e de donn´ees plus que le Watir. Quatri`emement, la facilit´e d’apprentissage,
16


l’accessibilit´e du Selenium est mieux que le Watir. Pourtant, la caract´eristique de
l’interface et le manuel des 2 outils sont pareils. Cinqui`emement, le rapport de test,
le Selenium gagne le mieux r´esultat pour ce facteur parce qu’il fournit le rapport en
mode graphique mais le Watir a seulement le rapport en mode textuel. Enfin, les fonctionnalit´es suppl´ementaires, comme les 2 outils sont open-source, mais le Selenium
fournit plus de nombre de plugin que le Watir donc il est un bon choix que le Watir.
` propos du r´esultat ci-dessus, nous sommes certains que le Selenium est le
A
meilleur outil afin de tester l’application Web que le Watir. En plus, le Testerman est
disponible pour le Python donc le Selenium est l’outil de bon choix pour d´evelopper
le test d’automatisation.

17


Chapitre 3
Conception et Impl´
ementation
Ce stage a pour but de d´evelopper les scripts de cas de test pour pouvoir les
utiliser avec les outils de tests d’automatisation. En plus, ces scripts doivent ˆetre
r´eutiliser dans l’avenir. Pour mieux r´epondre aux objectifs de ce travail, nous avons
utilis´es la conception de la programmation orient´ee objet (POO).

3.1

Conception du projet
Ce projet fait partie des produits d’Anevia. Les produits d’Anevia partagent

plusieurs modules de fonctionnalit´es entre eux, sauf le module des services qui est
diff´erent dans chaque famille (Flamingo, ViaLive, ViaMotion, etc.). Dans ce module,
il y a plusieurs services disponibles, par exemple : le service ”Modules Settings”, le
service ”Web Radio”, le service ”Web TV”, etc.
Comme il existe plusieurs versions de ce produit, les cas de tests doivent ˆetre
adapt´es avec les diff´erentes versions du produit. La cr´eation de nouveau scripts afin
de tester de nouveau cas de test ne pose aucun probl`eme. Pourtant, le probl`eme
de l’utilisation seulement de script ATS est apparaˆıt, s’il y a des changements de
l’interface de l’application Web ou dans le syst`eme sous test (SUT) dans les cas de
test existant. Pour surmonter le probl`eme de changement de SUT pour les cas de
tests, nous avons une vue sur les services de Flamingo XL comme les cat´egories des
objets et des groupes de m´ethodes.
Afin de r´eussir ce projet, nous avons l’id´ee de cr´eer des biblioth`eques pour
d´ecrire les ´etapes de chaque fonctionnalit´e. Les biblioth`eques sont ´ecrites avec le
langage Python combin´e avec la d´efinition de Selenium. Ces biblioth`eques peuvent
ˆetre utiliser dans des scripts ATS de Testerman.
Avant d’´ecrire les biblioth`eques utilis´es par Flamingo XL, nous devons tout
d’abord ´etudier les cas de tests pour bien comprendre les fonctionnalit´es de produit.
18


Ensuite, nous devons pr´eparer l’environnement local comme l’installation de Wireshark, PyShark, le logiciel de m´edias (VLC, FFplay), etc. Puis, nous devons essayer de
suivre ces cas de tests en testant `a la main (l’interaction avec l’interface web). Enfin,
nous pouvons avoir la vue sur les fonctionnalit´es, afin de diviser ces fonctionnalit´es il
suffit de les ´ecrire comme des classes et des m´ethodes en Python.

Figure 3.1: Services de Flamingo XL

Dans la figure 3.1, vous pouvez voir qu’il y a 5 cat´egories de services de Flamingo XL. Chaque cat´egorie est d´evelopp´e comme un fichier Python. Ce fichier peut
contenir plusieurs classes m´elang´e avec des m´ethodes. Nous prenons les fonctionnalit´es principaux dans chaque cat´egorie pour ´ecrire une classe. Grˆace a` l’´etape d’´etude
des cas de tests, nous pouvons d´efinir les fonctions en commun entre les services de
Flamingo XL.

3.2

Impl´
ementation
Apr`es avoir d´efinir la structure des biblioth`eques, nous allons tout d’abord

pr´eparer l’environnement de travail et installer les outils n´ecessaires (les outils d’analyse des paquets, les biblioth`eques n´ecessaires dans Ubuntu). Puis nous pouvons cr´eer
des scripts ATS sur le Flamingo XL.

Pr´
eparation de l’environnement
1. Python
Concernant le langage sp´ecifique utilis´e dans ce projet est le Python, nous devons v´erifier s’il est d´ej`a install´e dans le syst`eme d’exploitation utilis´e. Normalement, le Python existe d´ej`a sous Ubuntu mais il faut faire la confiance sur la
version utilis´e parce que les diff´erentes version de Python peut provoquer un

19