Tài liệu Concevoir et développer un système automatisé pour tester flamingo xl

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 à remercier mes encadreurs, monsieur NGUYEN Manh Tuong, le directeur du Pentalog à Hanoi, et Madame LE THI THU Hoa, le chef du projet pour ses disponibilités et ses conseils. Ils m’aidaient toujours à passer tous les moments difficiles et m’ont guidé à aller dans la bonne direction du projet. Je voudrais remercier monsieur Victor Moraru qui m‘a conseillé de faire le stage chez Pentalog. Je tiens également à remercier tous les collègues du Pentalog qui m’ont appris les informations du projet et m’ont supporté à être confortable pendant la période du stage, et mes amis, qui m’ont aidé avec des conseils, des remarques et des critiques. Résumé Actuellement, l’informatique a beaucoup d’intérêt dans la vie quotidienne, par exemple : la communication, la distribution des nouvelles et l’éducation, etc. Il existe pas mal de technologies afin de bien profiter de ces intérêts : des sites web, des applications mobile, etc. Pour avoir la garantie de logiciel, le processus du test est appliqué dans le projet du développement de logiciel. Le site web est un moyen qu’on utilise pour diffuser des informations à tout le monde à travers l’Internet, donc le test à la main est suffit en raison de vérifier des contenus affichés. Comme l’informatique n’est jamais rester immobile, l’application Web a été créé 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é de l’application Web. Afin de tester un logiciel, nous avons différents méthodes comme le test unitaire, le test d’intégration, etc. Pourtant, le test du site web peut être faire à la main. Comme le test dans la façon d’humain peut avoir des erreurs et prend beaucoup de temps, pour cette raison le test d’automatisation du web a été développé. Dans ce travail, nous avons le but de créer des scripts pour le test d’automatisation du web sur le produit Flamingo XL d’Anevia. Ces scripts doivent être réutiliser dans l’avenir. En plus, le nombre du scripts réussis dois être 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ères 1 Introduction 1.1 Anevia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 1.2 Flamingo XL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Contexte du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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émentation 3.1 Conception du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 18 3.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4 Expérimentation 33 5 Conclusion et Perspective 5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36 5.2 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 A Exemple du bibliothèque 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ème IPTV . . . . . . . . . . . . . . . . . . . . . . . Architecture point-à-point de IPTV . . . . . . . . . . . . . . . . . . . 5 6 2.3 Tableau de Programme d’Information Spécifique (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ès Conditionnel (CAT) . . . . . . . . . . . . . . . . . 8 8 2.7 Infrastructure de Testerman . . . . . . . . . . . . . . . . . . . . . . . . 12 2.8 Méthodes de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Services de Flamingo XL . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Fenêtre de Qtesterman . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3 3.4 Exemple de la bibliothèque utilisé dans le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 30 4.1 Architecture du système IPTV . . . . . . . . . . . . . . . . . . . . . . . 34 Diagramme de développement d’un script ATS ii Chapitre 1 Introduction Aujourd’hui, l’Internet est connu par tout le monde. Chaque personne l’utilise pour différent but, comme les études, les travaux et les divertissements, etc. Pour ces raisons, l’application Web a été développée afin de répondre aux besoins des utilisateurs. Actuellement, il existe de nombreuses applications Web, qui sont souvent utilisés pour accéder à des services à distant. Parmi ces applications Web, il y en a des sites-web qui exigent d’avoir un haut niveau de sécurité, une correction des données et une consistance des informations, etc. par exemple : le site E-commerce, le site de la banque, etc. Par conséquent, le test devient très important pour ce genre d’application Web. Normalement, le test d’application Web se fait par les humains. C’est-à-dire, ils testent l’application à la main. En conséquence, il y a une forte possibilité qu’ils fassent des erreurs ou ne respectent pas l’enchaı̂nement des étapes de test. Pour ces raisons, l’utilisation de test d’automatisation est développé. Ce test utilise des scripts afin de vérifier des fonctionnalités et la qualité de l’application Web, comme : le temps d’attente est acceptable, la vue de page est correct dans différent navigateur Web, etc. Un des services qu’on peut adapter avec l’application Web est la distribution des chaı̂nes TV. Celle-là diffuse le multimédia (l’audio et le vidéo) sur l’adresse IP. En plus, on peut aussi distribuer des chaı̂nes de satellite vers le réseau local. Donc, on n’a pas besoins d’installer pleins d’équipements pour pouvoir regarder des chaı̂nes diffusés par le satellite. Cette technologie est appelée 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éation de l’infrastructure de logicielles pour la diffusion de la télévision en direct et à la demande. Les produits d’Anevia ont été déployés avec succès sur différents marchés tels que les médias, les opérateurs télécom Tier-1 et Tier-2 et dans de nombreuses entreprises privées ou publiques. Anevia a commencé le développement de Vidéo dans le système CDN (Content Delivery Networks) qui offrent aux téléspectateurs la liberté de choisir ce qu’ils veulent regarder à la télévision, partout et à tout moment. Les solutions d’Anevia rendent les CDNs plus efficaces, tout en permettant aux opérateurs de réduire le stockage et la bande passante. Ces solutions sont par nature conçues pour offrir la meilleure expérience multi-écrans (NPVR, Timeshifting , OTT et/ou IPTV) à tous les utilisateurs. Sur le marché d’entreprise, les produits d’Anevia ont été déployés sur tous les continents par des centaines d’hôtels, d’établissements, d’enseignement, de sociétés privées, etc. qui souhaitent diffuser de la vidéo en direct et à la demande. 1.2 Flamingo XL Flamingo XL est l’un des produits d’Anevia qui est dédié au marché d’hospitalité (hôpitaux, hôtels). Les solutions proposées permettent de diffuser sur le réseau local à la fois la télévision en direct et les contenus enregistrés. Après avoir reçu le signal TV et celui de la radio en direct par satellite, par câble et numérique terrestre, le Flamingo XL les transfère sur des réseaux IP pour les ordinateurs, les set-top boxes, les téléviseurs modernes et toute autre appareil avec un accès réseau qui est relié avec le Flamingo XL. Nous pouvons se connecter à l’interface Web et de piloter le Flamingo XL en utilisant la connexion SSH. 1.3 Contexte du travail Pour assurer la qualité du Flamingo XL, le test d’automatisation est adapté dans le projet. Le script créé dans ce projet doit être réutiliser dans l’avenir afin de minimiser le temps du test. Le langage spécifique du projet est le Python. Les outils spécifiques du projet sont le Testerman et le Selenium-RC. Ces deux outils permettent de créer des tests automatisés avec l’application Web ; le Testerman est l’outil 2 principal qui gère l’exécution du test d’automatisation, et le Selenium-RC fonctionne comme un sonde permettant de lancer le test sur l’application Web. Le développement du projet est divisé en 1. Compréhension du produit : Pour mieux comprendre et développer les scripts de test d’automatisation, nous devons bien comprendre les fonctionnalités et les services fournit par le produit sous test. 2. Vérification des cas de test : Après avoir bien compris le produit, nous devons vérifier les cas de test reliés avec ce produit. Comme il existe plusieurs version de produit, donc nous devons valider les étapes dans les cas de test en raison d’assurer la cohérence entre le produit sous test et les cas de test utilisés. S’il y a beaucoup de différent, il faut mettre à 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’équipe, il est nécessaire de concevoir la structure des bibliothèques et des scripts de test. Ce-là peut nous aider à augmenter la qualité du codage, par exemple : éviter la duplication de la même fonctionnalité dans une bibliothèque. 4. Installation des outils : Nous faisons la préparation de l’ordinateur, comme l’installation de plug-in Firebug et FirePath dans le navigateur Firefox, etc. 5. Développement des bibliothèques et des scripts de test d’automatisation : Nous devons développer les bibliothèques en Python avant de les déployer dans les scripts de test d’automatisation. 1.4 Problématique L’objectif général du projet est de transformer le cas de test du Flamingo XL environ 80% à utiliser les scripts du test d’automatisation. Pourtant, ces scripts doivent être réutiliser avec d’autres produits dans la famille de Flamingo (différente version ou plate-forme). Parfois, nous ne pouvons pas transformer le cas de test en script parce qu’il pourra provoquer des problèmes, par exemple : on peut simuler la rupture de la connexion avec la commande ”sudo ifconfig eth0 down”, mais cette commande peut inciter un problème de connexion sur le serveur. C’est-à-dire, on ne peut pas rétablir la connexion avec la commande à distance. Donc, il faut éviter de transférer le cas de test comme ça en script. 3 Chapitre 2 Bibliographie Dans cette partie, nous décrivons les informations reliée au test d’automatisation dans le domaine du streaming. Premièrement, nous commençons par présenter le protocole IPTV qui nous permet de diffuser la vidéo de satellite vers le réseau. Deuxièmement, nous montrons les informations du flux de transport MPEG2 (TS MPEG2). Troisiè-mement, nous abordons les outils de capture des trames. Quatrièmement, on présente 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ù et à tout moment, tant que l’utilisateur peut accéder à l’Internet. Les architectures de système IPTV sont présentés dans la figure 2.1. Cette dernière illustre les principaux composants d’un système IPTV : 1. Les serveurs d’acquisition : ils codent la vidéo et ajoutent des métadonnées de gestion des droits numériques (Digital Rights Management : DRM) 2. Les serveurs de distribution : ils fournissent la mise en cache et la QoS contrôle. 3. Les créateurs de la vidéo à la demande (VoD) et les serveurs : ils conservent une bibliothèque de contenus VoD codé pour fournir des services de VoD. 4. Les routeurs IP : ils acheminent les paquets IP et réacheminent rapidement les paquets en cas de défaillance de routage. 4 Figure 2.1: Architecture du système IPTV 5. Set-Top-Box (STB) : STB est un appareil du côté client qui interagit avec le terminal de l’utilisateur, par exemple : la télévision, l’ordinateur, le téléphone portable, etc. avec le ”Digital Subscriber Line” (DSL) ou avec le câble. IPTV et multidiffusion IP La multidiffusion IP est une méthode d’envoi des paquets à un groupe d’IP, qui sont les récepteurs intéressés. Cette méthode utilise l’infrastructure du réseau de manière efficace, tout en exigeant la source afin d’envoyer un paquet seulement une fois, même si elle doit être délivré à un grand nombre de récepteurs. Architecture point-à-point de IPTV Pour une distribution IPTV point-à-point (P2P), il y a une source et un groupe de pairs regardant la vidéo. Nous nous référons à la souquirce et le groupe de pairs comme un torrent. La source encode la vidéo et diffuse les paquets vidéo dans le torrent de P2P. Chaque poste reçoit des paquets provenant de la source et/ou d’autres pairs comme la montre la figure ci-dessous. 5 Figure 2.2: Architecture point-à-point de IPTV 2.2 Flux de transport MPEG2 Le flux de transport (Transport Stream : TS) est un format spécifié dans MPEG-2 Partie 1, système (norme ISO / CEI 13818-1). TS MPEG2 a une conception qui permet le multiplexage de la vidéo numérique et l’audio afin de synchroniser la sortie. TS MPEG2 offre des fonctionnalités de correction d’erreur pour le transport sur les médias peu fiables, et il est utilisé 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é de base de données 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élévision numérique édictées par le consortium européen DVB, et utilisées dans un grand nombre de pays 2. le groupe, créé en 1982, qui a développé les normes ATSC pour la télévision numérique aux États-Unis, également adoptée par le Canada, le Mexique, la Corée du Sud, et récemment au Honduras et est considéré par d’autres pays 6 bit et un PID à 13 bits. Ceci est suivi par un compteur de continuité à 4 bits, qui est généralement incrémenté avec chaque paquet ultérieur d’une trame, et peut être utilisé pour détecter les paquets manquants. Les champs de transport supplémentaires, dont la présence peut être signalée dans le champ d’adaptation optionnel, peuvent suivre. Le reste du paquet est constitué 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ées de Reed-Solomon de correction d’erreur. Programme d’Information Spécifique (PSI) Le Programme d’Information Spécifique (Program Specific Information : PSI) représente les données MPEG 2 qui identifient les parties du flux de transport appartenant à un programme particulier. Figure 2.3: Tableau de Programme d’Information Spécifique (PSI) Les informations transportées 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êt du décodeur, qui essaye de localiser un programme. Le décodeur trouve rapidement le PAT, car il se trouve toujours sur le PID 0x0000. Le PAT fournit le décodeur 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écodeur de la valeur PID pour les paquets contenant le PMT pour chaque programme. En plus, le PAT 7 peut également 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éfinie un programme spécifique en listant des PIDs pour les paquets contenant les composants audio, vidéo et données du programme. Avec cette information. Grâce au PMT, le décodeur peut facilement localiser, décoder et afficher le contenu du programme. Figure 2.5: Tableau de la Carte de Programme (PMT) 3. Tableau de l’Accès Conditionnel (Conditional Access Table : CAT) (optionnel) : la syntaxe MPEG-2 permet aux diffuseurs de transmettre des informations confidentielles d’accès 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écodeur où 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ès Conditionnel (CAT) 1. le message dans le flux de transport utilisé pour mettre à jour les options d’abonnement ou ”pay-per-view” droits pour un abonné individuel ou pour un groupe d’abonnés 8 4. Tableau de l’Information de Réseau (Network Information Table : NIT) (optionnel) : NIT fournit des informations d’un réseau sur lequel différents flux de transport résident. Il donne accès à d’autres flux de transport. 2.3 Packet sniffer Le Packet Sniffer est un programme fonctionnant dans un appareil connecté au réseau qui reçoit passivement toutes les trames de la couche de liaison de données en passant par la carte réseau. Il est également connu sous le nom de l’analyseur de réseau (Ethernet Sniffer) [10]. Chaque machine sur un réseau local dispose de sa propre adresse matérielle qui se distingue des autres machines. Quand un paquet est envoyé, il sera transmis à toutes les machines disponibles sur le réseau local. En raison du principe de partage Ethernet, tous les ordinateurs dans le même réseau local peuvent voir le trafic passant à travers ce réseau. 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 à l’utilisateur d’intercepter et d’afficher TCP/IP et d’autres paquets qui sont transmises ou reçues sur un réseau auquel l’ordinateur est connecté. ”Tcpdump” fonctionne sur la plupart des systèmes d’exploitation de type Unix. Dans ces systèmes, ”tcpdump” utilise la bibliothèque 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érent parce qu’il ne fait pas une analyse tous les paquets, il utilise simplement la capacité 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éveloppé par ETSI (European Telecommunications Standards Institute). La notation ressemble à des langages de programmation et elle est spécialement dédiée au développement de tests des protocoles de communication. TTCN-3 prend une approche très universelle en se libérant complètement du système sous test (System Under Test, SUT). Le même cas de test peut être exécuté dans des environnements bien différents. Des adaptateurs servent d’intermédiaire entre le script de test abstrait et le SUT. Quelques caractéristiques principales sont : un système de typage fort, définition des tests concurrents (des tests avec plusieurs composants), support d’une communication synchrone ou asynchrone, support de timers et une facilité d’exécution automatique. L’industrie a approuvé l’utilisabilité du standard. Il a été employé pour le développement de test de conformité dans des domaines différents comme VoIP, IPv6, Digital Mobile Radio, WiMax, LTE, etc. TTCN-3 est surtout utilisé dans le domaine de la communication mais peut être adopté pour les tests unitaires (logiciels) ou les systèmes distribués. 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ème d’automatisation TTCN-3 inspiré sans le strict modèle de la notation de contrôle TTCN-3. Ceci est réalisé en mettant les primitives de TTCN-3 avec les concepts du langage de programmation Python. Testerman fournit un environnement complet pour concevoir, gérer, exécuter et analyser les tests automatisés. Il est peut-être utilisé comme une plate-forme pour développer des simulateurs de test (pilotes et stubs) et des prototypes d’applications de réseau. Il se concentre sur la fourniture de toute la base nécessaire pour effectuer des tests d’applications de bout en bout basées sur le réseau de protocoles multiples. En particulier, il a été conçu avec les plate-formes de télécommunications à l’esprit, comme ceux basés sur VoIP / IMS. Testerman a été conçu pour être multi-utilisateur (client-serveur) avec un dépôt centralisé des cas de test. Il est adaptable à la plupart des topologies SUT, les contraintes de réseau, et extensible (adaptateurs de test/système peuvent être 10 développés facilement, en n’importe quelle langage). Utilisateur (Client) Les utilisateurs interagissent avec le système à travers un client de Testerman. Plusieurs clients peuvent se connecter au même serveur et ils sont capable de partager le même référentiel d’ATS et les mêmes ressources techniques. Actuellement, les clients suivants sont disponibles : 1. un client d’interface de ligne de commande : il peut être utilisé pour appeler les exécutions de la suite de tests à partir d’un script shell, ou un Makefile. 2. une multi-plate-forme : nommé QTesterman qui fournit un IDE pour concevoir, exécuter, contrôler et analyser les suites de test. 3. un client Web lightweigth : il est limité à l’exécution des tests et obtenir leurs résultats et les journaux. Ce client peut être publié comme un front-end pour vos clients dans une DMZ. Composants du serveur Le serveur est divisé en deux composantes : 1. Le serveur Testerman : un front-end pour les clients qui est responsables de la création, de l’exécution et de contrôle de test exécutables (TE) d’une source ATS écrit par l’utilisateur. Il est également en mesure de pousser les mises à jour pour les clients ayant mis en œuvre la mises à jour automatiques, tels que QTesterman. 2. Le serveur contrôleur 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écution à distance. Le TACS peut être installé sur une autre machine que la Testerman Server et partagé entre plusieurs serveurs. Sonde (Probe) Une ”probe” est le mot pour appeler un adaptateur de test (un adaptateur système). Elle peut effectivement se connecter à un SUT (Système sous test) en utilisant différents protocoles comme TCP, UDP, SOAP, etc. Testerman fournit un ensemble de sondes, qui sont capable d’interagir avec le SUT, et également avec la simulation des actions de l’utilisateur ou d’autres actions nécessaires pour automatiser un test. 11 Figure 2.7: Infrastructure de Testerman 12 Les sondes peuvent être gérés par le TE lui-même. Il sont en cours d’exécuter sur le serveur Testerman et d’initier ou d’attendre les connexions réseau sur les interfaces IP du serveur Testerman, ou peut être exécuté sur n’importe quel système distant. Dans ce cas, ils doivent être hébergés sur un agent Testerman afin de gérer les communications de bas niveau avec le serveur de contrôleur de l’agent Testerman (TACS). Les agents doivent être déployés manuellement par le testeur, c’est-à-dire ils doivent être installés et démarrés. Cependant, une fois déployé, un agent peut être utilisé par n’importe quel TE, afin de déployer dynamiquement n’importe quel nombre de sondes en fonction de sa configuration d’adaptateur de test définie. Cette architecture permet de distribuer les sondes n’importe où dans le réseau, soit à l’intérieur du SUT ou autour du SUT lui-même. Ceci permet d’obtenir plusieurs avantages : 1. Nous pouvons stimuler le SUT avec n’importe quelle adresse IP, il y a pas de limite à ceux du serveur. 2. Nous pouvons installer un agent sur les SUT eux-mêmes. Nous pouvons aussi exécuter des commandes sur le SUT, ou observer les événements qui se produisent à l’intérieur du SUT, par exemple : les mises à jour de journaux, les créations de fichiers, les créations des processus enfants, etc 3. Nous pouvons mettre en œuvre des sondes dans n’importe quelle langage, en fournissant un agent existant. C’est-à-dire, on n’est pas limité à Python mais on peut choisir le meilleur langage de mise en œuvre de notre sonde en fonction de nos compétences ou des bibliothèques disponibles dans le langage. Si on n’utilise pas le Python, cependant, nos sondes ne seront pas en mesure d’exécuter 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 écrit en Python (PyAgent), et il peut accueillir toutes les sondes qui peuvent également être exécutées localement par le TE. Cette PyAgent peut également être mis à jour à distance à 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éveloppement afin d’évaluer des fonctionnalités d’un logiciel. Dans le domaine des 13 tests de logiciels, il existe plusieurs méthodes qui sont divisés en 3 catégories : Figure 2.8: Méthodes de tests 1. Les tests statiques et les tests dynamiques Les différences entre ces deux tests sont présentés dans le tableau suivant : Tests statiques Réalisé sans l’exécution du programme Réalisé avant la compilation Le but est de prévenir des anomalies Tests dynamiques Réalisé par l’exécution du programme Réalisé après compilation Le but est de trouver et corriger les défauts C’est le processus de validation C’est le processus de vérification 2. L’approche de la boı̂te L’approche de la boı̂te est divisée en 2 types différents : Boı̂te blanche Les tests de fonctionnalités 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ète du fonctionnement interne de l’application Normalement réalisé par les testeurs et les développeurs Convient à l’algorithme des tests Utilises plus de temps Le test est réalisé par les utilisateurs finaux, les testeurs et les développeurs Ne convient pas à l’algorithme des tests Utilises moins de temps 14