Approche de modélisation des tests de logiciels complexes par un système multi-agents

Ministère de l Enseignement Supérieur et de la Recherche Scientifique Institut National de Formation en Informatique (INI) Oued Smar MEMOIRE Pour l'obtention du diplôme de MAGISTER EN INFORMATIQUE (Option Systèmes d'informations) Approche de modélisation des tests de logiciels complexes par un système multi-agents Réalisé par : M me HADJ-BOUAZZA née M RAOUI Kamila Devant le jury composé de : Président : Mme H. DRIAS Professeur à l'usthb Rapporteur : Mr M. AHMED NACER Professeur à l'usthb Examinateur : Mme Z. ALIMAZIGHI Maître de conférence à l'usthb Examinateur : Mr D.E. ZEGOUR Professeur à l'ini INI, 2006

Remerciements Je tiens à exprimer toute ma gratitude à mon directeur de thèse le professeur M. Ahmed Nacer qui m a fait confiance en acceptant de m encadrer, m a transmis la motivation nécessaire pour mener à bien ce travail ; merci pour votre disponibilité, vos précieux enseignements et vos conseils avisés. Pour m avoir fait l honneur de présider mon jury, je tiens à remercier Mme H. Drias. Je remercie également Mme Z. Alimazighi et Mr D.E. Zegour de me faire l'honneur de faire partie du jury pour juger mon travail.,je remercie : - Les membres de l équipe de la Division Systèmes d'informations (DSI) du Cerist, en particulier Mme F. Admane, Melles Hamida, Lydia, Safia,... - Le personnel de la DPGR et de la bibliothèque de l INI. - Le personnel de la bibliothèque du Cerist en particulier Mr Meftouh. Je tiens à exprimer ma reconnaissance à Mme H. Mellah et Melle L. Mohand-Oussaid pour toute l aide et le soutien qu elles m ont apportés. Je tiens à dire un grand MERCI à toute ma famille, du plus petit au plus grand, pour leurs encouragements, leur soutien, leur patience et leur aide considérable. A Aziz pour sa patience et sa disponibilité, A ma petite Mellina, à ma grande Hafso, A ma mère, pour avoir suscité ma vocation, A mon père, pour ses conseils avisés qui m ont permis d acquérir un esprit de synthèse.

Résumé Le test logiciel représente un des moyens les plus efficaces permettant de s assurer du bon fonctionnement des logiciels particulièrement complexes. Mais, le processus de test logiciel en lui-même est assez complexe dans la mesure où un certain nombre de problèmes complexes se posent. Ces problèmes requièrent des solutions adaptées où le temps et l efficacité jouent un rôle important. L automatisation partielle ou globale du processus de test est donc primordiale voir déterminante. Dans cette optique, nous proposons une approche de modélisation du processus de test logiciel par un système multi-agents qui vise à automatiser ce processus. Le système proposé est constitué d agents capables de mener aussi bien les tests dynamiques que les tests statiques d un logiciel. Ces agents sont conçus pour conduire les tests de différents niveaux (unitaires, intégration et système), ainsi que les tests de régression. Les agents de notre système fonctionnent de façon autonome afin d atteindre le taux de détection d erreurs et les délais fixés par le testeur (humain) au départ. Mots-clés : Tests logiciels, agent, système multi-agents, modélisation.

SOMMAIRE INTRODUCTION GÉNÉRALE... 1 CHAPITRE I : LES TESTS LOGICIELS... 3 I.1 INTRODUCTION... 3 I.2 DEFINITIONS... 4 I.3 LES NIVEAUX DE TESTS... 5 I.3.1 Les tests unitaires... 6 I.3.2 Les tests d intégration... 7 I.3.3 Les tests système... 9 I.3.4 Les tests d acceptation... 10 I.4 LES TYPES DE TESTS... 11 I.4.1 Classification des techniques de test... 11 I.4.2 Comparaison des techniques de test... 20 I.5 LE PROCESSUS DE TEST... 21 I.5.1 Phase 1 : modélisation de l environnement du logiciel... 22 I.5.2 Phase 2 : sélection des scénarios de tests... 24 I.5.3 Phase 3 : exécution et évaluation des scénarios de tests... 24 I.5.4 Phase 4 : mesure de la progression des tests... 25 I.6 CONCLUSION... 26 CHAPITRE II : LES SYSTEMES MULTI-AGENTS... 27 II.1 INTRODUCTION... 27 PARTIE 1 : ETAT DE L ART... 29 II.2 LES AGENTS... 29 II.2.1 Définition d un agent... 29 II.2.2 Modèle d agent [BON94]... 31 II.2.3 Les types d agents... 32 II.3 SYSTÈME MULTI-AGENT (SMA)... 38 II.3.1 Définition d un SMA... 38 II.3.2 Environnement d un système multi-agent... 40 II.3.3 L organisation dans un système multiagent... 41 II.3.4 Coopération entre agents... 42 i

II.3.5 Résolution de conflits... 43 II.3.5.1 Coordination... 43 II.3.5.2 Négociation... 44 II.3.6 Communication entre agents... 44 II.3.7 Contrôle et prise de décision... 48 II.3.8 Conception d un système multi-agent... 48 II.3.8.1 Spécification d un agent... 49 II.3.8.2 Spécification des interactions... 50 PARTIE 2 : LES SMA ET LES TESTS LOGICIELS... 52 II.4 Travaux sur la modélisation des tests logiciels par les SMA... 52 II.5 Discussions... 56 II.6 CONCLUSION... 57 CHAPITRE III : CONCEPTION... 58 III.1 INTRODUCTION... 58 III.2 Découpage du problème global en sous-problèmes... 58 III.3 Architecture du SMA pour la modélisation du processus global de test... 61 III.3.1 Spécification des agents... 62 III.3.2 Modélisation globale du processus de test... 64 III.3.2.1 Modélisation du processus de tests unitaires... 64 III.3.2.2 Modélisation du processus de tests d intégration... 68 III.3.2.3 Modélisation du processus de tests système... 72 III.3.2.4 Modélisation du processus de tests statiques... 75 III.3.2.5 Modélisation du processus de tests de régression... 78 III.3.2.6 Modélisation du processus de mesure de la progression des tests... 82 III.4 CONCLUSION... 84 CONCLUSION GÉNÉRALE... 85 BIBLIOGRAPHIE... 87 ii

Liste des figures : Figure 1 : Niveaux de tests... 5 Figure 2 : Processus de test unitaire...7 Figure 3 : Graphe d appels entre unités (exemple)... 8 Figure 4 : Classification des tests... 12 Figure 5 : Les étapes du processus d inspection... 13 Figure 6 : Tests «boite noire»... 17 Figure 7 : Tests «boite blanche»... 17 Figure 8 : Processus de test dynamique... 22 Figure 9 : Aperçu externe et général d un agent [MAN02]... 29 Figure 10 : Représentation d un agent... 31 Figure 11 : Modèle d agent [BON94]... 31 Figure 12 : Structure interne d un agent... 33 Figure 13 : Architecture fonctionnelle d un agent cognitif... 34 Figure 14 : Fonctionnement d un agent réactif... 37 Figure 15 : Vue canonique d un système multiagent [JEN00]... 39 Figure 16 : Système multi-agent... 40 Figure 17 : Architecture du modèle de tableau noir... 45 Figure 18 : communication par envoi de messages... 47 Figure 19 : Les agents du TAS... 52 Figure 20 : représentation du système multi-agent de Dhavachelvan et al. [DHA06]... 55 Figure 21 : Découpage du problème global en sous-problèmes... 59 Figure 22 : Processus global de test... 60 Figure 23 : Architecture globale du système multi-agents pour le processus de test logiciel.. 61 Figure 24 : Représentation graphique de l architecture de communication du processus tests unitaires... 65 Figure 25 : Diagramme d activité du processus de tests unitaires... 66 Figure 26 : Diagramme de séquence du scénario «parallélisation des tests unitaires»... 67 Figure 27 : Représentation graphique de l architecture de communication du processus de tests d intégration... 69 Figure 28 : Diagramme d activité du processus de tests d intégration... 70 Figure 29 : Diagramme de séquence du scénario «attente d une unité non disponible»... 71 iii

Figure 30 : Représentation graphique de l architecture de communication du processus tests système... 73 Figure 31 : Diagramme d activité du processus de tests système... 74 Figure 32 : Représentation graphique de l architecture de communication du processus de tests statiques... 75 Figure 33 : Diagramme d activité du processus de tests statiques... 76 Figure 34 : Diagramme de séquence du scénario «analyse statique formelle»... 77 Figure 35 : Représentation graphique de l architecture de communication du processus tests de régression... 79 Figure 36 : Diagramme d activité du processus de tests de régression... 80 Figure 37 : Diagramme de séquence du scénario «non adéquation des cas de tests»... 81 Figure 38 : Représentation graphique de l architecture de communication du processus de mesure de la progression des tests... 82 Figure 39: Diagramme d activité du processus de mesure de la progression des tests... 83 Figure 40 : Diagramme de séquence du processus «mesure de la progression des tests»... 83 iv

Liste des tableaux : Tableau 1 : Comparaison entre les tests «boite noire» et les tests «boite blanche»... 20 Tableau 2 : Comparatif entre Agents cognitifs et Agents réactifs [REI90]... 38 Tableau 3 : Interdépendances entre sous-problèmes... 59 v

Introduction générale INTRODUCTION GÉNÉRALE La complexité des logiciels devient de plus en plus importante de nos jours. Les tests logiciels sont le moyen de s assurer du bon fonctionnement des logiciels particulièrement complexes. Par exemple dans le cas de logiciels critiques, les conséquences d une erreur peuvent être très graves (pertes humaines). C est pourquoi des chercheurs, comme des industriels, travaillent au développement de méthodes et d outils efficaces pour automatiser les tests logiciels [GOU04]. D un autre coté, le coût élevé des tests logiciels a lui aussi montré que la nécessité d automatiser les tests devient donc impérative. En effet, l étude menée pour le NIST en 2002 [NIS02] sur l impact de l insuffisance d infrastructure de test dans les développements de logiciels a montré le coût excessif de cette insuffisance qui a été estimé à 60 milliards de dollars pour l économie américaine. Ces aspects importants liés aux tests logiciels nous ont particulièrement motivés dans notre travail. L étude du processus de test logiciel nous a mené au constat qu un certain nombre de problèmes assez complexes existent et sont à résoudre comme par exemple l automatisation des tests statiques, la mesure de la progression des tests, ou la conduite des tests de régression. L approche de résolution par un système multiagents paraît donc appropriée. Les systèmes multi-agents (SMA) permettent de faire coopérer un ensemble d agents dotés d un comportement intelligent et de coordonner leurs buts et leurs plans d actions pour résoudre un problème. 1

Introduction générale Le but de notre travail est de proposer une approche de modélisation du processus de test par un système multi-agents. Notre document est organisé en trois chapitres : Le chapitre 1 est une introduction aux tests logiciels. Nous y détaillons les différentes notions relatives au domaine des tests logiciels telles que les techniques utilisées, le processus de test, les niveaux de tests, Le chapitre 2 est structuré en deux parties. Dans la première partie, nous présentons un état de l art sur les systèmes multi-agents. Nous y présentons les différentes définitions relatives au concept «agent». Dans la deuxième partie, nous présentons un résumé de travaux réalisés dans la modélisation des tests logiciels avec le concept d agent. Le chapitre 3 est consacré à la présentation de notre proposition d approche de modélisation du processus de test par un système multi-agents. Cette approche est basée sur un groupe d agents qui interagissent entre eux pour conduire au mieux les tests statiques et les tests dynamiques à différents niveaux de tests (unitaires, intégration, système). 2

Chapitre I : LES TESTS LOGICIELS Chapitre I : Les tests logiciels I.1 INTRODUCTION Afin de savoir si un logiciel ne comporte pas d anomalies et répond aux attentes des utilisateurs, les développeurs doivent le soumettre à des tests. Procéder aux tests de logiciels n est pas un processus visant seulement à détecter les éventuelles anomalies, mais aussi à acquérir la confiance nécessaire avant l utilisation opérationnelle du produit logiciel en vue d atteindre la qualité voulue. Vu les coûts liés aux tests en temps et en budget, les développeurs ne procèdent pas systématiquement aux tests de leurs logiciels. En fait, les tests sont indispensables pour des logiciels soumis à d importantes contraintes de sécurité et de fiabilité. En réalité, le problème réside dans la capacité à mettre au point des tests, qui exigent le moins de temps possible dans leur conception et leur mise en œuvre, pour obtenir les résultats (détection d erreurs) les plus performants possibles. Dans ce chapitre nous allons explorer le domaine des tests de logiciels afin de mieux cerner le processus global de test de logiciel. 3

Chapitre I : LES TESTS LOGICIELS I.2 DEFINITIONS Avant toute chose, nous allons tenter de définir ce qu est le test de logiciels ainsi que certaines notions utilisées dans ce domaine. Cette définition est issue de la norme IEEE 729: «Le test est un processus manuel ou automatique, qui vise à établir qu un système vérifie les propriétés exigées par sa spécification, ou à détecter des différences entre les résultats engendrés par le système et ceux qui sont attendus par la spécification». Une autre définition [SWE04]: «le test de logiciel consiste en la vérification dynamique du fonctionnement d'un programme sur un ensemble fini de cas de test, convenablement sélectionné parmi le domaine infini d'exécutions, en fonction des spécifications prévues.». Selon Myers [MYE04] : «Le test de logiciel est un processus, ou une série de processus, conçus pour s assurer que le code du logiciel accomplit ce pour quoi il a été conçu, et qu il n accomplit pas d autres choses inattendues». La vérification est «le processus d évaluation d un produit issu d une des activités du développement logiciel, pour déterminer la correction et la cohérence avec les produits ou les normes fournis comme entrée de cette activité» [DOD88]. La vérification sert à répondre à la question : est-ce un système bien fait, conformément aux règles de l art? La validation est «le processus d évaluation d un logiciel pour déterminer sa conformité avec les besoins spécifiés» [DOD88]. Par la validation nous tentons de répondre à la question : est-ce le bon système, répondant aux besoins réels des utilisateurs? Une erreur (error) est une différence entre une valeur ou une condition calculée, observée ou mesurée et la valeur ou condition spécifiée, qui est vraie ou théoriquement correcte [IEE90]. Une faute ou un défaut (fault) est une collection d états du code source d un programme qui cause une panne. [IEE90] 4

Chapitre I : LES TESTS LOGICIELS Une panne ou défaillance (failure) est : «l incapacité d un système ou d un de ses composants d effectuer les fonctions demandées dans les conditions de performance spécifiées» [IEE90]. Un oracle de test est une spécification des résultats attendus par le test, qui permet de décider de l échec ou le succès du test. Remarque : les définitions données ci-dessus sont standards dans le domaine du «test logiciel», elles sont différentes de celles utilisées dans le domaine de la «tolérance aux fautes». On déduit, à partir des définitions précédentes, que pour bien conduire les tests, il faudra d abord formuler les fonctionnalités attendues, les contraintes d environnement, ou encore les situations particulières à considérer. Le principal objectif du test de logiciel est de détecter les erreurs pour garantir : La correspondance entre le produit livré et ses spécifications fonctionnelles, et L absence d anomalies l empêchant de fonctionner. I.3 LES NIVEAUX DE TESTS On distingue 4 niveaux de test : 1. Les tests unitaires, 2. Les tests d intégration, 3. Les tests système et 4. Les tests d acceptation. A chaque niveau de test les buts sont spécifiques. Tests unitaires Tests d intégration Tests système Tests d acceptation Figure 1 : Niveaux de tests 5

Chapitre I : LES TESTS LOGICIELS Pour tous les types de systèmes, on commence toujours par tester la plus petite unité ou module afin d identifier les fautes fonctionnelles et structurelles, c est ce qu on appelle les tests unitaires. Une fois les tests unitaires effectués et les corrections nécessaires faites, on doit intégrer les différentes unités pour construire le système et tester l intégration. Au niveau des tests d intégration on s intéresse particulièrement aux interfaces. Le test du système commence lorsque tous les composants ont été intégrés avec succès. A ce niveau l accent est mis sur l évaluation de la performance, l utilisabilité, la fiabilité et d autres spécifications relatives à la qualité. L étape suivante est le test d acceptation, qui doit montrer que le produit logiciel satisfait les besoins des utilisateurs. A l issue de cette étape, on devra obtenir un produit validé. I.3.1 Les tests unitaires Une unité est vue comme une fonction ou une procédure implémentée dans un langage procédural. Dans un système orienté-objet, les méthodes et les classes/objets ont été suggérées par les chercheurs comme un choix d unité [BUR02]. Une unité peut représenter également un composant COTS (Component Off The Shelf) de petite taille acheté de chez un vendeur externe et qui subit l évaluation par l acheteur, ou un simple composant récupéré d une librairie de composants réutilisables interne. Les tests unitaires représentent un niveau de test vital. Plus les unités sont petites et simples, plus il sera facile de les tester. Lorsqu une défaillance est révélée par les tests, il est plus facile de la localiser et de la réparer (débogage) du moment que l on ne considère que l unité sous test. Les tests unitaires introduisent le parallélisme dans le processus de test du fait de la possibilité de tester plusieurs unités simultanément. Le but principal des tests unitaires est de comparer les fonctions d une unité par rapport à certaines spécifications. En fait, on ne cherche pas à montrer qu une unité satisfait ses spécifications mais à montrer le contraire, c est-à-dire qu elle contredise ses spécifications. Les tests unitaires sont menés en se basant sur le plan de tests unitaires conçu à l étape de «conception détaillée» du cycle de vie du logiciel. Ce plan met en évidence les spécifications à tester pour chaque unité. Donc, pour préparer les tests unitaires les développeurs ou les testeurs doivent accomplir un certain nombre de tâches : - planifier l approche générale pour effectuer le test des unités ; - concevoir les cas de test, et les procédures de test ; - définir les relations entre les tests ; 6

Chapitre I : LES TESTS LOGICIELS - préparer le code auxiliaire nécessaire pour le test unitaire. La conception des cas de test unitaires : La conception des tests unitaires nécessite deux éléments : une spécification de l unité et son code source. Typiquement, la spécification définit les entrées et les sorties de l unité. Les tests unitaires sont en grande partie orientés «boite blanche». Mais lorsqu on teste de grandes unités comme le programme entier, les tests «boite blanche» deviennent moins efficaces [BUR02]. Les tests unitaires sont également appelés tests de composants. Toutefois, les tests de composants sont parfois classés à un niveau de tests plus élevé que les tests unitaires. Cela peut être le cas des systèmes contenant des composants pouvant être testés individuellement, et qui contiennent eux-mêmes plusieurs unités. Dans d'autres cas, certains font la différence entre tests unitaires et tests de composants en fonction du degré d'isolement des modules. Dans les tests unitaires, les unités appelées sont remplacées par des bouchons (stubs), et les unités appelantes sont remplacées par des pilotes (drivers), de façon à isoler les unités en cours de test. U i (unité à tester) P i (plan de tests de U i ) Cas de Tests pour U i Test unitaire Rapport de test de U i Procédure de test de U i Figure 2 : Processus de test unitaire I.3.2 Les tests d intégration Dans les tests unitaires, le testeur tente de détecter les fautes relatives aux fonctionnalités et la structure de l unité. Quelques tests d interface simples sont réalisés lorsque les unités interagissent avec des pilotes (drivers) et des bouchons (stubs). Par ailleurs, les interfaces sont plus adéquatement testées lors des tests d intégration lorsque chaque unité est connectée aux unités avec lesquelles elle interagit. L assemblage ou le 7

Chapitre I : LES TESTS LOGICIELS processus d intégration permet de constituer un système complet prêt à être testé lors de la phase suivante «tests système». Les tests d intégration devraient être exécutés sur des unités qui ont été corrigées et qui ont passé les tests unitaires avec succès. Pour effectuer les tests d intégration, il faudra adopter une stratégie d intégration. Il existe plusieurs stratégies parmi les plus connues : la stratégie top-down, la stratégie bottom-up, et la stratégie big-bang. Les tests d intégration se basent sur le graphe d appel entre les unités. En se basant sur le graphe d appel, il sera plus simple d appliquer la stratégie choisie. U1 U2 U3 U4 U5 Figure 3 : Graphe d appels entre unités (exemple) La stratégie TOP-DOWN (descendante): Le test d intégration «Top-Down» consiste à intégrer les unités en commençant par la racine du graphe (sommet). La première unité est ainsi intégrée aux unités qu elle appelle au fur et à mesure, puis la même procédure est appliquée pour chaque unité intégrée [MYE04]. Dans l exemple de la Figure 3, l intégration Top-Down se fera comme suit : on teste l intégration de U1 avec U2, puis on teste l intégration de (U1+U2) avec U3, puis on teste l intégration de (U1+U2+U3) avec U4, puis on teste l intégration de (U1+U2+U3+U4) avec U5. La stratégie BOTTOM-UP(ascendante) : L intégration «Bottom-Up» consiste à intégrer les unités en commençant par les unités qui sont à la base du graphe (feuilles). Ces unités sont d abord testées (tests unitaires), puis pour 8

Chapitre I : LES TESTS LOGICIELS chaque unité on intègre, au fur et à mesure, les unités qui l invoquent. La même procédure est appliquée pour chaque unité intégrée [MYE04]. Dans l exemple de la Figure 3, l intégration Bottom-Up se fera comme suit : on teste l intégration de U5 avec U3, puis on teste l intégration de (U5+U3) avec U4, puis on teste l intégration de (U5+U3+U4) avec U2, puis on teste l intégration de (U5+U3+U4+U2) avec U1. La stratégie BIG-BANG : Le test d intégration «Big-Bang» consiste à assembler toutes les unités en même temps et à exécuter l ensemble. Cette technique n est pas adaptée aux systèmes complexes, car les erreurs sont difficilement localisables. Une intégration big-bang progressive, c est-à-dire l intégration d une ou de quelques unités à la fois, est plus efficace pour la localisation des erreurs [HAN02]. Dans l exemple de la Figure 3, l intégration Big-Bang se fera comme suit : On teste l intégration de (U1+U2+U3+U4+U5). I.3.3 Les tests système Les objectifs des tests système sont de détecter les fautes relatives au comportement du système global, plutôt que le comportement de chacun des éléments, et de tester le logiciel dans son fonctionnement global. Ce niveau d'évaluation implique le système dans sa globalité, et pas seulement les interactions entre unités. Le but des tests système est de s assurer que le système est en accord avec les besoins. A cette étape, les testeurs doivent disposer d un plan de tests système élaboré à l issue de l étape d analyse des besoins. Ce plan doit contenir un plan de tests maître et les tests boite noire à effectuer. Il doit contenir, aussi, les approches de tests à utiliser, les coûts et les délais à respecter, les cas de tests et les procédures de tests. Les tests système permettent d évaluer les caractéristiques de la qualité requises telles que la fiabilité, l utilisabilité, la performance et la sécurité. A ce stade, il sera spécialement utile de pouvoir détecter des défaillances dans les interfaces logicielles et matérielles externes, par exemple, celles qui causent des conditions extrêmes, des verrous, des problèmes d interruption et de traitement des exceptions, et l utilisation inefficace de la mémoire. Afin de tester les différentes caractéristiques de la qualité, il existe plusieurs types de tests système parmi eux [MYE04][JAC03]: 9

Chapitre I : LES TESTS LOGICIELS 1. les tests de fonctionnalité : consistent à tester si le système accomplit les fonctions pour lesquelles il a été conçu. 2. les tests de volume : consistent à tester si le système est capable de manipuler un gros volume de données spécifié dans les besoins. 3. les tests de stress : consistent à tester la réaction du système face à une charge de traitements importante dans un temps limité. On teste, ici, s il n y pas de problèmes de manque de ressources ou de concurrence pour l utilisation des ressources. 4. les tests d utilisabilité : ce type de tests s intéresse au facteur humain. Il s agira de sélectionner un sous ensemble représentatif d utilisateurs potentiels afin de tester le système. 5. les tests de sécurité : consistent à tester les propriétés de sécurité que le système doit assurer telles que la disponibilité, l intégrité, la confidentialité des données et des services. Le but de ces tests est de révéler les failles de sécurité. 6. les tests de performance : consistent à tester la performance du système en révélant ses défaillances en terme de temps de réponse ou encore de capacité de traitement sous certaines conditions. 7. les tests de configuration : consistent à tester le système de façon à vérifier s il fonctionne dans les différentes configurations (réseaux, systèmes d exploitation, ) pour lesquelles il a été conçu. 8. les tests de fiabilité : consistent à tester les propriétés de fiabilité du système spécifiées dans les besoins. I.3.4 Les tests d acceptation Une fois les tests système achevés, on passe à l étape des tests d acceptation. Les tests d acceptation consistent à mettre le logiciel à la disposition du client afin que les utilisateurs potentiels puissent l évaluer dans les conditions réelles. Un plan de test est conçu en collaboration avec les clients afin de déterminer les cas de test à considérer lors des tests d acceptation. Pour les logiciels destinés à un client précis, on parle de tests d acceptation. Alors que pour les logiciels complexes destinés à un large marché, on parle de tests Alpha et de tests Béta. Les tests Alpha sont faits sur le site du développeur par les utilisateurs potentiels. Les développeurs relèvent les problèmes rencontrés afin de les corriger. 10

Chapitre I : LES TESTS LOGICIELS Les tests Béta sont faits en dehors du site du développeur, les utilisateurs potentiels testeront ainsi le logiciel dans des conditions réelles, et rapportent les problèmes rencontrés aux développeurs. I.4 LES TYPES DE TESTS Les différentes approches de tests (dynamique et statique) sont importantes, car le but est de détecter la présence de fautes ou de prouver leur absence. La première définition du test de logiciels, présentée précédemment, fait ressortir deux types de test : les tests statiques et les tests dynamiques, et donc assimile la vérification au test de logiciel. Alors que la deuxième définition ne considère que la partie dynamique de la vérification comme faisant partie de l activité de test. I.4.1 Classification des techniques de test Les différentes techniques de tests peuvent être classées en fonction de la stratégie de test choisie. Ainsi, Huey-Der Chu [CHU97] propose une classification selon le but des tests : 1. doit-on exécuter le logiciel pour le tester? si oui, le test sera dynamique, sinon le test sera statique. 2. doit-on examiner le code source dans le test dynamique? si oui, on utilisera le test boite blanche, sinon ce sera le test boite noire. 3. doit-on examiner la syntaxe du code source dans le test statique? si oui, on fera un test syntaxique, sinon un test sémantique. 4. comment se fait la sélection des données de test? les données de tests sont sélectionnées selon que la technique utilisée soit un test fonctionnel, un test structurel ou encore un test aléatoire. 5. quel type de données de test doit être généré? dans le test déterministe, les données de test sont prédéterminées par un choix sélectif en fonction du critère adopté. Dans le test aléatoire, les données de test sont générées en fonction d une distribution de probabilité sur l ensemble des données de tests possibles (input domain). 11

Chapitre I : LES TESTS LOGICIELS Tests logiciels Statique Dynamique Syntaxique Sémantique Boite noire Boite grise Boite blanche Figure 4 : Classification des tests Dans ce qui suit, nous allons détailler les différentes techniques de tests. Les techniques de test existantes sont divisées en deux catégories : les tests statiques et les tests dynamiques. Les techniques de tests statiques sont utilisées pour examiner le logiciel sans l exécuter ; les techniques de tests dynamiques requièrent la génération de cas de tests pour l exécution du logiciel. I.4.1.1 Les tests statiques Les techniques de tests statiques permettent d examiner, de façon manuelle ou automatique, les représentations du système (documents de spécifications, diagrammes de conception, code source du logiciel, ) sans avoir à exécuter le code du logiciel. Le but étant de s assurer qu aucune erreur n a été introduite durant le processus de développement du logiciel, donc la vérification des spécifications est ici très importante. Les tests statiques peuvent porter sur l examen de la syntaxe ou de la sémantique du code source. On peut diviser les techniques de tests statiques en deux groupes, les techniques informelles et les techniques formelles. Dans la pratique, les techniques informelles sont axées sur l examen de la syntaxe, alors que les techniques formelles sont plus axées sur l examen de la sémantique. Parmi les techniques de tests statiques les plus utilisées, il y a les inspections de programmes, l analyse des anomalies, l évaluation symbolique, et la vérification formelle basée sur les mathématiques. 12

Chapitre I : LES TESTS LOGICIELS a) Les techniques informelles Parmi les techniques de tests informelles, il y a les inspections, l analyse des anomalies, et l évaluation symbolique. a.1. L inspection de programme : L inspection de programme est une sorte de revue. Les revues sont de trois types [SOM92] : - les revues relatives aux décisions de gestion de projet, - les revues relatives à la stratégie de conception, et - les revues qui visent à vérifier le logiciel, qui sont parfois appelées «inspections de programme». Le but d une inspection est d analyser le code et d indiquer les défauts possibles qui s y trouvent. Les inspections de programme peuvent aussi être utilisées pour l examen statique de tout produit logiciel qui résulte de n importe quel stade du processus de développement logiciel (spécification des besoins, conception, documentation, ). Une inspection suit un processus structuré. En général, une inspection est entreprise par une petite équipe composée d un minimum de quatre personnes. Les rôles des membres de l équipe sont répartis comme suit : L auteur : qui est le programmeur ou le concepteur du ou des composants à inspecter. Le lecteur, dont le rôle est de présenter le code à l équipe lors de l inspection. Le testeur qui inspecte le code du point de vue des tests (dynamiques). Le modérateur qui dirige l inspection et motive les autres membres de l équipe. Planification Panorama Préparation individuelle Inspection de programme Re-travail Ré-inspection Figure 5 : Les étapes du processus d inspection 13

Chapitre I : LES TESTS LOGICIELS D après Fagan [FAG76], le processus d inspection est composé de six étapes essentielles : 1. La phase de planification, à l issue de laquelle l équipe sera constituée, la réunion sera organisée, et tout ce qui doit être tester ainsi que les spécifications correspondantes seront préparés. 2. La phase panorama, dans laquelle sera effectuée une présentation générale à l équipe de ce qui va être inspecter. 3. La phase de préparation individuelle, dans laquelle chaque membre de l équipe étudie individuellement le code et sa spécification. 4. La phase d inspection, qui doit être courte dans le temps, dans laquelle les membres de l équipe se réunissent pour procéder à l identification des défauts, des anomalies et des points de non-conformité aux standards. 5. La phase «Re-travail» vient à la suite de la phase d inspection pour corriger les défauts ou problèmes détectés, elle est réalisée par le ou les auteurs (programmeurs et/ou développeurs). 6. En fin, la phase de ré-inspection sert à vérifier qu aucun autre défaut n a été introduit à l issue de la phase précédente. Lors du processus d inspection, on peut se baser sur une liste des erreurs les plus communes (check-list) pour détecter les erreurs. Cette liste peut varier en fonction des vérifications que le compilateur prend en charge. L équipe d inspection peut aussi mettre à jour la liste des erreurs communes afin de faciliter les prochaines inspections. a.2. L analyse des anomalies L analyse des anomalies suit une démarche bien précise, sauf pour les anomalies très simples qui peuvent être détectées à la compilation (typage impropre, mauvaise utilisation de pointeurs, ), qui peut être résumée comme suit : a. Etablir un critère d acceptabilité des programmes sous test sans les exécuter. b. Construire un graphe pour représenter les informations contenues dans les textes, afin de les simplifier. c. Etudier les chemins du graphe généré jusqu à satisfaction du critère choisi. Ici, plusieurs types de graphe peuvent être utilisés : soit un graphe de contrôle ou flot de données pour les programmes séquentiels, soit un graphe de dépendance, un réseau de Pétri ou un système de transitions pour les programmes parallèles ou concurrents. 14

Chapitre I : LES TESTS LOGICIELS a.3. L évaluation symbolique L évaluation symbolique permet de simuler l exécution sur des données symboliques. Des expressions sont construites, reliant les données d entrées d un programme aux données de sorties, ainsi que des conditions pour pouvoir suivre les différents chemins. Exemple [GAU96]: Le fragment de code suivant: read(x); y := x+1; if y <= 0 then z := y * x else z := y; donne comme expressions symboliques, associées à la variable z, pour les deux chemins possibles: (x 0 +1) x 0 si (x 0 +1) 0 (x 0 +1) si (x 0 +1) > 0 b) Les techniques formelles La vérification formelle est utilisée pour prouver que la sémantique d un code est correcte. Elle consiste à examiner que certaines propriétés souhaitées sont respectées sur un système donné. Cette vérification se fait par la confrontation d'une représentation concise et non ambiguë des propriétés et d'un modèle mathématique, basé sur un langage formel, représentant le système. Le mécanisme de vérification ayant pour but d'examiner que les propriétés souhaitées sont incluses dans les comportements du système. Il existe deux principales approches de vérification formelle : la preuve formelle et le Model Checking. b.1. La preuve formelle Introduite par Hoare [HOA69], cette approche est basée sur une preuve mathématique. Elle consiste à décrire le système et ses propriétés dans un modèle de sémantique axiomatisable et à démontrer que les propriétés peuvent être obtenues à partir du système en utilisant les règles d'inférence. Cette approche est utilisée dans des outils tels que l'atelier B [ATE], Coq [HUE99] et PVS [CRO95], etc. Cette approche a l'avantage de pouvoir traiter des systèmes à nombre d'états infini. Elle ne repose pas sur une construction explicite d'un modèle de comportement de type états/transitions, très coûteux en mémoire, puisqu'elle est capable d'inférer des conclusions 15

Chapitre I : LES TESTS LOGICIELS directement à partir d'une description d'événements ou d'opérations permettant de faire évoluer le système. L'utilisation des techniques de preuve est cependant rendue difficile par le fait que l'utilisateur doit être capable de modéliser le système par un modèle mathématique sur lequel s'effectue la preuve et raffiner ce modèle mathématique jusqu'à obtenir le système à implanter [CHO03]. Lorsqu'il s'agit d'un système conçu et implémenté, le seul moyen pour générer le modèle abstrait correspondant est l'utilisation des assertions logiques (pré-condition, post-condition). Néanmoins, la principale contrainte à laquelle fait face la preuve formelle est la complexité qui restreint son utilisation à des systèmes de taille limitée. b.2. Le model checking Le Model Checking est une approche algorithmique qui repose sur une idée simple : si l'on énumère toutes les situations possibles dans lesquelles peut se trouver le système, on saura s'assurer qu'aucune de ces situations n'est en contradiction avec les comportements que l'on désirait [CHO03]. Du fait que le Model Checking procède par énumération exhaustive des états du système à vérifier, la représentation de tous les comportements possibles d'un système avec un nombre d'états infini, conduit rapidement à un dépassement des capacités de stockage en mémoire de l'ordinateur. Ce phénomène est connu sous le nom d'explosion combinatoire, ce problème a fait l'objet de plusieurs recherches et a donné lieu à des techniques d'abstraction permettant d'aborder la vérification des systèmes infinis. Les méthodes formelles sont très efficaces, l approche est cohérente et de bonne réputation. Le seul inconvénient est que plus un programme est grand, plus la preuve devient compliquée à écrire et donc elle-même pourrait contenir des erreurs. De ce fait, il convient d utiliser cette approche pour des portions de code assez critiques. I.4.1.2 Les tests dynamiques Les techniques de tests dynamiques sont généralement divisées en deux catégories : les tests boite noire et les tests boite blanche, qui correspondent à deux points de départ différents dans le test de logiciel : la structure interne du logiciel (le code source) et la spécification des besoins. Elles requièrent l exécution de parties du logiciel avec des données de tests et une comparaison du résultat avec les sorties attendues devant satisfaire les besoins des utilisateurs. 16

Chapitre I : LES TESTS LOGICIELS a) Les tests «boite noire» Les tests «boite noire» utilisent une «mentalité de grille-pain» : on met dedans, c est supposé fonctionner. Les données en entrée créées sont conçues pour générer des variations des sorties sans se préoccuper du fonctionnement interne. Les résultats sont prédits et comparés aux résultats actuels pour déterminer le succès du test. Entrées pour faire varier les sorties Boite noire (code à tester) Sorties (résultats obtenus) Comparaison entre résultats obtenus / résultats prédits Succès / Echec Figure 6 : Tests «boite noire» b) Les tests «boite blanche» En opposition, les tests «boite blanche» ouvrent la «boite» et examinent la logique spécifique de logiciel pour vérifier comment il fonctionne. Les tests utilisent des spécifications logiques pour générer des variations dans les traitements et pour prédire les sorties résultantes. Des résultats intermédiaires et finaux peuvent être prédits et validés en utilisant les tests boites blanches. Entrées pour faire varier les traitements If x=1 then x:=x+1 Else x :=0 Boite blanche (code à tester) Sorties (résultats obtenus) Comparaison entre résultats obtenus / résultats prédits Succès / Echec Figure 7 : Tests «boite blanche» 17

Chapitre I : LES TESTS LOGICIELS Avec le temps, d autres termes ont été introduits, maintenant les tests boites noires sont parfois appelés «tests fonctionnels» ou «tests basés-spécification», et les tests boites blanches peuvent faire référence aux «tests structurels» ou «tests basés-code» ou encore «tests boites en verre (glass-box)». c) Les tests «boite grise» Les tests «boite grise» combinent les tests «boite noire» et les tests «boite blanche». Les tests «boite grise» ne sont pas des tests «boite noire» car ils s intéressent à une partie du fonctionnement interne du logiciel à tester. C est comme si on avait une boite noire et qu on ouvrait une partie de la boite pour voir ce qui s y passe. Donc une partie du code est testée en «boite noire» et une autre partie en «boite blanche». d) Techniques pour la génération de données de test Pour la génération des données de test, il existe trois stratégies de base [BER91] : 1. le test fonctionnel : les données de test sont essentiellement sélectionnées en accord avec la référence qui est la spécification fonctionnelle. 2. le test aléatoire : les données de test sont essentiellement sélectionnées en accord avec la façon dont le logiciel s exécute. (en fait, le domaine des entrées est généralement divisé en partitions en fonction de l utilisation prévue du logiciel). 3. le test structurel : les données de test sont essentiellement sélectionnées en accord avec la référence qui est la spécification structurelle. Les deux premières stratégies font allusion aux tests boite noire et la troisième aux tests boite blanche. Une variété de techniques de test fait partie des stratégies de base citées précédemment. De façon générale, la génération d un sous-domaine des entrées de tests adéquat procède selon un des deux principes suivants : soit déterministe ou aléatoire (probabiliste). * Les tests déterministes : Les stratégies de test fonctionnelles et structurelles utilisent toutes les deux des moyens méthodiques pour déterminer des sous-domaines des entrées de test. Elles utilisent souvent des entrées particulières pour tester des cas particuliers. Les techniques de test déterministes consistent à sélectionner des sous-domaines des entrées de tests en fonction du critère choisi. Cette approche de sélection de données de test fait communément allusion au «partition testing». En fait, la plupart des stratégies de 18

Chapitre I : LES TESTS LOGICIELS test subdivisent le domaine des entrées en sous-domaines qui se chevauchent et par conséquent ne forment pas une vraie partition du domaine des entrées, le terme subdomain-based testing ou plus simplement subdomain testing a été suggéré par un certain nombre d auteurs [CHE96][FRA93]. Par ailleurs, le but de ces tests est de provoquer un comportement anormal, et le succès de cette démarche réside dans l identification des sous-domaines avec une forte probabilité de fautes ou de défaillances. * Les tests aléatoires : La stratégie de test aléatoire est la méthode conventionnelle probabiliste pour générer des entrées de test. La distribution de probabilité, décrivant la fréquence avec laquelle différents éléments du domaine des entrées sont sélectionnés quand le logiciel est en utilisation réelle, est utilisée dans ce type de tests. Cette stratégie consiste à générer des données de test aléatoires basées sur une distribution uniforme à travers le domaine des entrées [DUR84]. L avantage d utiliser les tests aléatoires est que des évaluations quantitatives de la fiabilité opérationnelle d'un logiciel peuvent être déduites. D un autre coté, les tests aléatoires peuvent être vus comme une forme dégénérée du «subdomain testing» dans le sens ou il n y a qu un seul «sous-domaine» le domaine des entrées entier. Les tests statistiques sont basés sur une définition non-usuelle des tests aléatoires [DEN04] : ils visent à fournir une couverture «équilibrée» d un modèle du logiciel cible, aucune partie du modèle n est rarement ou jamais exercée durant le test. Avec cette approche, la méthode pour générer des modèles (patterns) de tests statistiques combine l utilisation d un critère de test avec une génération aléatoire. L ensemble de patterns de tests statistiques est ensuite défini par deux paramètres, qui doivent être déterminés en fonction du critère de test utilisé. Ceux-ci sont comme suit : 1. Le profil de test ou la distribution des entrées, d où sont tirés les patterns aléatoirement. 2. le volume du test ou d une manière équivalente le nombre de patterns en entrée qui sont générés. Les avantages majeurs de l utilisation des tests statistiques sont [CUR86][WHI94] : - premièrement, les tests peuvent être exécutés sur la base de l'utilisation réelle du logiciel, - deuxièmement, ils laissent l utilisation de techniques d inférence statistiques pour calculer les aspects probabilistes du processus de test, et 19

Chapitre I : LES TESTS LOGICIELS - troisièmement, dans beaucoup d applications, les tests peuvent être complètement automatisés, de la génération de données de test à l analyse des résultats de test. I.4.2 Comparaison des techniques de test Tests statiques tests dynamiques : L évaluation expérimentale des revues et des inspections du code ont démontré l efficacité des techniques de test statiques en détectant 30% à 70% d erreurs de conception et de codage dans un logiciel typique [DEM87][FAG86]. Par ailleurs, l approche formelle, utilisant la vérification mathématique, peut détecter plus de 90% des erreurs dans un programme [MIL87]. Les tests statiques sont souvent plus efficaces et moins coûteux que les tests dynamiques dans la détection des erreurs [GIL93][LAU89], mais ils dépendent fortement du profil et de l expérience du testeur [DEM78]. Aussi, les tests statiques peuvent s appliquer à toutes les représentations du système comme par exemple les documents de spécifications, les diagrammes de conception ou encore le code source du logiciel, et plus une erreur est détectée tôt dans le cycle de vie moins elle sera coûteuse à corriger. Quant aux tests dynamiques, ils ne s appliquent que sur une implémentation, mais leur avantage réside dans le fait qu ils servent à démontrer que le logiciel est opérationnel. Tests boite noire tests boite blanche L évaluation de la performance des tests boite noire et des tests boite blanche [POS96] appliqués au problème du triangle de Myers [MYE04], a donné les résultats expérimentaux suivants : Tests «boite blanche» Tests «boite noire» Taux de couverture du code Elevé Elevé Taux de détection d erreurs Bas (quatre erreurs non trouvées) Elevé (Plus élevé que celui des tests boite blanche) Taux de couverture des besoins Inconnu Elevé Tableau 1 : Comparaison entre les tests «boite noire» et les tests «boite blanche» Il est important d examiner pourquoi une distinction apparaît entre les tests boite noire et les tests boite blanche. En fait, les tests boite noire sont typiquement utilisés pour vérifier si le produit est conforme aux spécifications. Mais que se passera-t-il si quelque chose dans le 20

Chapitre I : LES TESTS LOGICIELS produit ne satisfait pas les spécifications? Que se passera-t-il si le logiciel accompli des taches indésirables que les entrées des boites noires n auront pas détecté? C est là que les techniques de test boite blanche interviennent. Elles permettent d examiner le code en détail en étant sûr qu un certain taux de couverture des tests est assuré au minimum. Les tests boite blanche sont eux-mêmes insuffisants lorsque le logiciel sous test n assure pas une des tâches attendues et l examen du code n est pas à même de révéler cela. L utilisation des tests boite noire sera donc utile pour repérer les fonctionnalités manquantes. Tests déterministes tests aléatoires Une comparaison empirique, qui évalue le taux de détection d erreurs, entre les tests déterministes et les tests aléatoires a été réalisée par Thévenod-Fosse et Waeselynck [THE91]. Les résultats de cette comparaison montrent que : Pour les erreurs régulières, les techniques de test déterministes sont moins efficaces que les techniques de test aléatoires. Pour les erreurs marginales, ce sont les tests statistiques qui donnent de meilleurs résultats. Les erreurs régulières sont celles qui causent des défaillances dues à un comportement incorrect du logiciel pour un critère donné de sélection des entrées de test, alors que les autres sont marginales. I.5 LE PROCESSUS DE TEST Afin de pouvoir planifier et exécuter des tests sur un logiciel, les testeurs doivent prendre en considération un certain nombre de facteurs tels que : le logiciel et les fonctions qu il automatise, les entrées et la façon dont elles peuvent se combiner, et l environnement dans lequel le logiciel va éventuellement opérer. Le processus de test consomme du temps, un planning sera donc nécessaire afin de maîtriser les délais. Le processus de test de logiciel peut être approché [WHI00], de façon claire, en quatre phases : 1. modélisation de l environnement du logiciel. 2. sélection des scénarios de tests. 3. exécution et évaluation des scénarios de tests. 4. mesure de la progression des tests. 21

Chapitre I : LES TESTS LOGICIELS Mesure de la progression Modélisation de l environnement de tests Sélection des scénarios de tests Exécution et évaluation des tests Echec Succès Tests de régression Figure 8 : Processus de test dynamique I.5.1 Phase 1 : modélisation de l environnement du logiciel Simuler l interaction entre le logiciel et son environnement est une des tâches des testeurs. Ces derniers doivent identifier et simuler les interfaces que le logiciel utilise, et énumérer les entrées intervenant dans chaque interaction. Ceci pourrait être le problème fondamental que les testeurs rencontrent, vu que les interfaces, les interactions et les entrées peuvent être variées (formats de fichiers, protocoles de communication, interfaces de programmation, ). Il existe, cependant, quatre interfaces communes : a. Les «Interfaces Homme» qui incluent toutes les méthodes communes que tout le monde utilise pour communiquer avec le logiciel. La plus importante est la GUI (Graphical User Interface), mais de plus anciennes méthodes sont toujours utilisées comme l interface de lignes de commande. Les mécanismes d entrée possibles à considérer sont : le clique de souris, l entrée clavier, et tout autre périphérique. Les testeurs doivent décider comment assembler ces données pour un test effectif. b. Les «Interfaces logicielles», appelées APIs (Application Programming Interface), qui permettent l utilisation d un système d exploitation, une base de données ou une librairie d exécutables par le logiciel à tester. Les services assurés par ces applications 22

Chapitre I : LES TESTS LOGICIELS seront modélisés comme des entrées de test. Les testeurs doivent contrôler les services attendus et inattendus, ce qui n est pas une tâche facile. c. Les «Interfaces de système de fichiers» qui existent lorsque le logiciel manipule des données de fichiers externes. Les développeurs doivent, dans ce cas, assurer le contrôle d erreurs, afin de déterminer si les fichiers manipulés contiennent les données appropriées et le bon format. C est donc aux testeurs de vérifier que le travail a été réalisé correctement, en générant des fichiers de tests qui contiennent une variété de données et de formats. d. Les «Interfaces de communication» qui permettent un accès direct aux périphériques physiques en utilisant un protocole de communication particulier. Les testeurs doivent générer des flots de protocoles valides et non-valides pour effectuer les tests, ils doivent assembler - et envoyer au logiciel sous test plusieurs combinaisons différentes de commandes et de données, dans le format de paquet adéquat. Ensuite, les testeurs doivent comprendre et contrôler les interactions de l utilisateur qui ne rentrent pas dans le contrôle du logiciel. Par exemple : un utilisateur supprime des fichiers en utilisant le système d exploitation alors qu ils sont ouverts par un autre utilisateur ; que va-t-il se passer si le logiciel tente d accéder aux fichiers en question? En résumé, les testeurs doivent donc recenser et tester toutes les interactions possibles avec l environnement du logiciel à tester, ce qui peut être un problème lorsque les interactions sont de tailles infinies ou complexes. Dans ce cas, les testeurs doivent sélectionner soigneusement des valeurs pour chaque variable en entrée et décider du séquencement des entrées. La technique la plus utilisée pour la sélection des valeurs est le «boundary value partitionning» [4] qui permet de prendre les valeurs aux limites ou autour des limites. Pour le séquencement des entrées, les testeurs doivent traiter chaque entrée en déterminant les évènements qu elle engendre. Un langage formel peut être utilisé ici pour pouvoir visualiser l ensemble des tests possibles, en affectant un symbole de l alphabet du langage à chaque événement. Ainsi, un modèle formel peut être généré. Le modèle est une représentation qui décrit comment les entrées et les symboles d événement sont combinés pour faire des mots et des phrases syntaxiquement valides. Ces phrases sont des séquences d entrées qui peuvent être appliquées au logiciel sous test. 23

Chapitre I : LES TESTS LOGICIELS I.5.2 Phase 2 : sélection des scénarios de tests L ensemble des scénarios de tests peut être infini, il s agit là de sélectionner un sous-ensemble qui requiert un temps relativement correct pour l exécution des tests, et qui assure un certain taux de couverture du code ou du domaine des entrées. La couverture du code est assurée par l exécution de chaque ligne du code au moins une fois. La couverture du domaine des entrées est assurée par l application de chaque événement externe généré. Donc les testeurs doivent définir un but de couverture et fixer le taux de couverture à assurer. Afin de sélectionner un ensemble de scénarios «assez bon» pour faire un bon test, les testeurs définissent le critère d adéquation des données de test. Ce critère permet de déterminer à posteriori si un cas de test est intéressant. En pratique, le critère d adéquation le plus utilisé est le taux de détection d erreurs. Aussi, il faudra choisir une technique de test en fonction du but à atteindre. I.5.3 Phase 3 : exécution et évaluation des scénarios de tests Une fois l ensemble de scénarios de tests sélectionné, les testeurs convertissent les scénarios en une forme exécutable, souvent en code, de telle sorte que l action d un utilisateur type soit simulée. Le code généré doit fournir des informations qui aident les testeurs à identifier les défaillances et donc à isoler les erreurs. L évaluation des scénarios implique la comparaison des sorties, qui résultent de l exécution du scénario de test, avec les sorties prévues dans les spécifications. Il existe deux approches pour évaluer les scénarios de test : 1. La formalisation : qui consiste à formaliser l écriture des spécifications, ainsi que la façon dont la conception et le codage y sont dérivés. Le fait de spécifier formellement les spécifications permet de simplifier la comparaison entre le comportement réel et le comportement prévu. 2. Le code de test intégré (embedded test code) : Il existe deux types de code de test intégré. Le plus simple est celui qui expose certaines données ou certains états d objets internes permettant de juger la correction par rapport à un oracle. Comme cette fonctionnalité est implémentée, elle sera invisible aux utilisateurs du logiciel à tester. Les testeurs peuvent accéder aux résultats du code de test à travers une API de test ou un debugger. 24

Chapitre I : LES TESTS LOGICIELS Un type plus complexe de code de test intégré représente des programmes qui s autotestent. Cela implique la programmation d opérations à exécuter puis à annuler, l état du logiciel qui en résulte devrait être équivalent à l état pré-opérationnel. Le problème qui se pose est que parfois un bug dans la première opération peut masquer un bug dans la deuxième. Les tests de régression : Une fois les défaillances détectées par les testeurs, les développeurs créent une nouvelle version du logiciel dans laquelle les erreurs seront localisées et corrigées. La nouvelle version sera à son tour testée, c est ce que l on appelle le test de régression. Les tests de régression doivent permettre d exécuter, une nouvelle fois, chaque test de la version n-1 sur la version n. Par ailleurs, les nouvelles versions montrent souvent de nouvelles fonctionnalités extensives, en plus des erreurs corrigées. C est pourquoi les tests de régression prennent souvent plus de temps. Un autre inconvénient lié aux tests de régression est le fait que le critère d adéquation des données de test peut être modifié, alors qu on doit réexécuter les mêmes scénarios que ceux de la version précédente. Il faudra alors s assurer qu une version fiable a été réalisée. I.5.4 Phase 4 : mesure de la progression des tests Un des aspects importants des tests est de savoir où en est le processus. Des mesures par comptage (exemple : nombre de bugs, nombre d entrées, ) sont parfois utilisées, mais l interprétation de ces mesures est difficile et ne donne pas de bonnes indications sur la progression des tests. Pour cela, les testeurs enrichissent ces mesures par des réponses à des questions conçues pour vérifier la complétude des tests structurels et fonctionnels. Par exemple : Pour la complétude des tests structurels : ai-je testé les erreurs communes de programmation? ai-je forcé l initialisation et l utilisation de toutes les données internes? Pour la complétude des tests fonctionnels : ai-je pensé aux différentes situations où le logiciel peut défaillir et sélectionné des tests montrant ses non défaillances? ai-je exécuté tous les scénarios qu un utilisateur peut exécuter? 25

Chapitre I : LES TESTS LOGICIELS Les testeurs sont toujours à la recherche de mesures qui leur permettraient de savoir quand arrêter les tests, ou encore de déterminer quand un produit est prêt à être livré. I.6 CONCLUSION Le test de logiciel est un travail d équipe, les développeurs ne devraient pas tester leurs propres logiciels, cette lourde tâche revient donc aux testeurs. Le processus de test de logiciels fait intervenir un certain nombre d acteurs (testeurs, développeurs, ), qui sont dotés d une intelligence leur permettant de planifier et coordonner les tests, de réagir à la suite de détection d erreurs, et de savoir quand arrêter les tests. Notre étude du domaine des tests logiciels nous a permis d avoir une vision globale sur le processus de test de logiciels, et de dégager les différents problèmes qui se posent. Ces derniers sont résumés dans ce qui suit : Comment sélectionner un ensemble de cas de test optimal? Comment choisir la bonne technique de test? Comment tester une nouvelle version du logiciel sans reprendre les tests à zéro (tests de régression)? Comment répartir les tests unitaires entre les testeurs de façon à optimiser la stratégie d intégration? Comment mieux tester les caractéristiques du système? Comment automatiser les tests statiques (exploiter l expertise des testeurs)? Quand doit-on arrêter les tests? Comment mesurer la progression des tests? Les différents problèmes que nous avons pu recenser, permettent de constater la complexité des tests logiciels. Certains travaux se sont orientés dans la modélisation des tests logiciels en utilisant le concept d agent [CHO02][DHA05][DHA06]. Ces travaux ont mené à de bons résultats pour la résolution de certains problèmes tels que l explosion combinatoire lors de la sélection de l ensemble des cas de tests, ou l allocation optimale des ressources lors des tests unitaires dynamiques. Dans le chapitre qui suit, nous présentons un état de l art sur les systèmes multi-agents ainsi que leur utilisation pour la modélisation des tests logiciels. 26

Chapitre II : LES SYSTEMES MULTI-AGENTS II Chapitre II : Les systèmes multi-agents II.1 INTRODUCTION Au début des années 70, parallèlement à l'intelligence Artificielle (IA) classique, de nouveaux systèmes et problèmes concernant l'étude des comportements collectifs ont été développés donnant naissance à une nouvelle branche de l IA nommée l Intelligence Artificielle Distribuée (IAD) [BON88][HUH87][FER88]. L intérêt principal de l IAD est de remédier aux insuffisances de l IA classique, en proposant de distribuer l expertise sur un groupe d agents capables de travailler et d agir dans un environnement commun et de résoudre les éventuels conflits. L activité coopérative entre agents fait apparaître de nouvelles notions telles que la coopération, la coordination d actions, la négociation et l'émergence [DAU97]. Les systèmes multi-agents (SMA) constituent un des axes de l IAD, ses systèmes permettent de faire coopérer un ensemble d agents dotés d un comportement intelligent et de coordonner leurs buts et leurs plans d actions pour résoudre un problème. L approche multi-agents est justifiée par : L adaptation à la réalité, La coopération, 27

Chapitre II : LES SYSTEMES MULTI-AGENTS La résolution de problèmes complexes, L intégration d expertise incomplète, La modularité, L efficacité, La fiabilité, La réutilisation. Dans la première partie de ce chapitre, nous allons d abord définir les différents concepts utilisés, puis détailler les différentes notions liées aux concepts «agent» et «système multiagents» (SMA). Puis, dans la deuxième partie, nous allons présenter les travaux effectués dans la modélisation des tests logiciels par le concept d agent. 28

Chapitre II : LES SYSTEMES MULTI-AGENTS PARTIE 1 : ETAT DE L ART II.2 LES AGENTS II.2.1 Définition d un agent Définir ce qu est un agent est une tâche assez difficile dans la mesure où ce terme est largement utilisé dans différents domaines de recherche et de développement. Pour cela nous avons sélectionné quelques définitions que nous avons jugées assez simples et pertinentes. D après le dictionnaire Larousse un agent est : «tout ce qui agit, opère.» Le terme agir signifie : être ou entrer en action ; faire quelque chose ; produire un effet, exercer une influence ; adopter telle attitude, se comporter, se conduire ; faire agir, animer. Le terme opérer signifie : accomplir une action, effectuer une série d actes permettant d obtenir, d accomplir quelque chose ; avoir pour résultat ; produire ; effectuer une action ; procéder, agir d une certaine manière. Environnement Perception AGENT Action Figure 9 : Aperçu externe et général d un agent [MAN02] «Un agent est une entité logicielle ou physique à qui est attribuée une certaine mission qu elle est capable d accomplir de manière autonome et en coopération avec d autres agents.» [BRI01] 29

Chapitre II : LES SYSTEMES MULTI-AGENTS Un agent peut être défini comme une entité, physique ou abstraite, capable d'agir sur elle-même et sur son environnement, pouvant communiquer avec d'autres agents et dont le comportement est la conséquence de ses observations, de sa connaissance et des interactions avec les autres agents [FER88]. Jennings, Sycara et Wooldridge [JEN98] ont proposé la définition suivante pour un agent : «Un agent est un système informatique, situé dans un environnement, et qui agit d une façon autonome et flexible pour atteindre les objectifs pour lesquels il a été conçu.» Les notions situé, autonome et flexible sont définies comme suit : - situé : l agent est capable d agir sur son environnement à partir des entrées sensorielles qu il reçoit de ce même environnement. - autonome : l agent est capable d agir sans l intervention d un tiers (humain ou agent) et contrôle ses propres actions ainsi que son état interne; - flexible : l agent dans ce cas est : * capable de répondre à temps : l agent doit être capable de percevoir son environnement et d élaborer une réponse dans les temps requis ; * proactif : l agent doit exhiber un comportement proactif et opportuniste, tout en étant capable de prendre l initiative au bon moment; * social : l agent doit être capable d interagir avec les autres agents (logiciels et humains) quand la situation l exige afin de compléter ses tâches ou aider ces agents à accomplir les leurs. La technologie agent représente un nouveau paradigme, nous sommes passés de la programmation classique à la programmation orientée objet et aujourd hui on parle de programmation orientée agent [JEN00][CHA01]. D ailleurs, il convient de faire la distinction entre «agent» et «objet». Un agent se distingue d un objet informatique ou d un programme classique par sa capacité à agir sans qu il ait été explicitement sollicité. Un objet répond lorsqu on fait appel à une de ses méthodes, alors qu un agent effectue une action sans qu on le lui demande. On dit qu un agent est «autonome» car il est capable d un comportement dirigé par des buts internes [MAN02]. 30

Chapitre II : LES SYSTEMES MULTI-AGENTS C A P T E U R S Variables d état interne Sélecteur d actions Actions Figure 10 : Représentation d un agent II.2.2 Modèle d agent [BON94] Figure 11 : Modèle d agent [BON94] Un agent est principalement caractérisé par : Son rôle ; Ses compétences ; Ses buts et ses intentions ; Ses croyances ; Ses capacités décisionnelles ; Ses capacités communicatives ; 31

Chapitre II : LES SYSTEMES MULTI-AGENTS Ses capacités d apprentissage. II.2.3 Les types d agents On distingue deux types d agents : les agents cognitifs et les agents réactifs. Suivant le type d'agents que l'on trouvera dans un système multi-agents, on parlera de systèmes cognitifs ou de systèmes réactifs. Cependant, il est possible de combiner les deux types d agents pour obtenir des agents hybrides bénéficiant des avantages de chaque type. II.2.3.1 Agents cognitifs Un agent cognitif dispose d une capacité de raisonnement sur une base de connaissance et d une aptitude à traiter des informations notamment celles relatives à la gestion des interactions avec les autres agents et son environnement [DIE90], ce qui lui permet d effectuer seul des opérations complexes. On dit que ce type d agents est de forte granularité. La granularité représente le degré de détail des connaissances de l agent. Elle exprime la complexité des fonctionnalités de l agent. Un agent cognitif peut avoir les caractéristiques suivantes [DEM90][LAB93][KHO94] : a. Intentionnalité Une intention est la déclaration explicite des buts et des moyens d y parvenir [SEA83][SEA90]. Un agent est dit intentionnel lorsqu il est guidé par ses buts. En fait, l intentionnalité d un agent révèle sa volonté d atteindre un but ou d effectuer une action. La notion d objectif est parfois utilisée pour exprimer la notion d intentionnalité [MIN88]. b. Rationalité Principe de rationalité [NEW82]: «Si un agent sait qu une de ses actions lui permet d atteindre un de ses buts, il la sélectionne». Un agent est dit rationnel lorsqu il suit le principe de rationalité. Les agents rationnels sont capables de sélectionner les meilleures actions permettant d atteindre leurs buts selon des critères d évaluation de leurs actions, ce qui justifie leurs décisions. De plus, la rationalité permet l utilisation efficace des ressources par l agent. 32

Chapitre II : LES SYSTEMES MULTI-AGENTS c. Engagement La notion d engagement est une des caractéristiques essentielles de l agent coopératif. Un agent coopératif construit un plan pour atteindre un but, et s engage à accomplir les actions qui satisfont ses buts en se donnant les moyens nécessaires pour y parvenir. Sa particularité réside dans le fait qu il planifie ses actions par coordination et négociation avec les autres agents. d. Adaptativité Un agent est dit adaptatif lorsqu il est capable de contrôler ses aptitudes selon les agents avec lesquels il interagit. Cette caractéristique confère à l agent un haut degré de flexibilité. e. Intelligence On dit qu un agent est intelligent lorsqu il s agit d un agent cognitif qui est intentionnel, rationnel et adaptatif. a) Structure d un agent cognitif Un agent cognitif se distingue par : son savoir-faire, ses croyances, sa connaissance de contrôle, son expertise et sa connaissance de communication. Savoir-faire Croyances Contrôle Expertise Communication Figure 12 : Structure interne d un agent - Savoir-faire : le savoir-faire est une interface dans laquelle se trouve la déclaration des connaissances et des compétences d un agent. Grâce à cette interface, la sélection des agents à solliciter pour une tâche donnée est facilitée. - Croyances : on dit qu un agent possède des croyances dans la mesure où les connaissances qu il possède sur lui-même et sur son environnement ne sont pas 33

Chapitre II : LES SYSTEMES MULTI-AGENTS forcément objectives. La formalisation de ces connaissances incertaines est à la base de la conception d un «SMA», du fait qu elle détermine en grande partie le comportement «intelligent» des agents. - Contrôle : la connaissance de contrôle d un agent représente ses buts, ses intentions, ses plans et ses tâches. - Communication : afin de pouvoir interagir avec d autres agents, l agent doit posséder un protocole de communication afin d assurer une bonne coopération et une bonne coordination des actions. Remarque : la connaissance liée au mode de coopération peut s ajouter aux autres types de connaissances. b) Fonctionnement d un agent cognitif Autres agents Perception Communication (négociation) CROYANCES BUTS Décision, planification EXPERTISE Exécution PLANS INTENTIONS Agent cognitif Figure 13 : Architecture fonctionnelle d un agent cognitif Les agents sont immergés dans un environnement dans lequel ils interagissent. Les fonctions principales d un agent sont : 1. percevoir 2. décider 3. agir A cela peuvent s ajouter d autres fonctions comme: - la détection de conflits, 34

Chapitre II : LES SYSTEMES MULTI-AGENTS - la révision des croyances (connaissances), - la coopération (négociation, coordination), - l apprentissage, etc. L agent dispose de connaissances, de croyances et de buts. Sa fonction de perception lui permet d acquérir des connaissances sur l environnement qui l entoure, et de mettre à jour ses croyances et ses connaissances. Suite à une perception, l agent procède à la planification de ses actions mais pour cela il doit d abord décider quel est le but qu il doit atteindre en priorité. Viendra ensuite la phase d exécution du plan d action, c est-à-dire l agent va agir. La perception : L origine des connaissances d un agent provient de : - son savoir initial, - la perception proprioceptive (perception de soi), et la perception extéroceptive (perception de son environnement), - la communication avec les autres agents. Les connaissances qui proviennent de la perception et du savoir initial sont généralement considérées comme des connaissances certaines car elles n ont subi aucune modification, alors que les connaissances provenant des autres agents sont considérées comme incertaines car elles évoluent sans que l agent en soit automatiquement informé. Prise de décision : Suite à une perception ou à une interaction avec son environnement, l agent doit décider quel but il doit atteindre en premier, puis décider des actions à entreprendre pour satisfaire ce but. L agent doit analyser la situation, en se basant sur ces connaissances et ses croyances, afin de sélectionner le but qui a le plus d influences positives. Pour faire son choix, l agent se base sur son savoir initial et ses croyances. Planification : L intelligence artificielle distribuée offre des possibilités de planification dynamique. Vu que les agents interagissent entre eux, un plan d action peut être révisé après son exécution. La planification peut être soit centralisée ou distribuée. Dans la planification centralisée, un agent central doit décomposer le problème en sousproblèmes. A chaque sous-problème correspond un plan partiel. Les plans partiels sont 35

Chapitre II : LES SYSTEMES MULTI-AGENTS ensuite distribués aux agents pour les exécuter. L agent central est chargé de contrôler les actions des agents pour éviter les éventuels conflits. Dans la planification distribuée, chaque agent construit son propre plan d action en coordination avec les autres agents afin d obtenir un plan global cohérent. L agent va donc alterner planification, exécution et révision de parties de son plan. II.2.3.2 Agents réactifs Les agents réactifs répondent au principe «stimulus/action», ce sont des agents à faible granularité. Ce type d agents ne dispose que d un protocole et d un langage de communication réduits, afin de leur permettre de percevoir les stimuli provenant de leur environnement et de répondre à ces derniers par des actions. Contrairement à ce qu on croit, les agents réactifs peuvent faire émerger des comportements qui correspondent à leurs buts. En fait, même si les agents d un SMA ne sont pas «intelligents», ils peuvent engendrer un comportement global intelligent. A l origine, cette approche réactive a résulté de travaux, réalisés au MIT par Brooks [BRO89], montrant l efficacité de l utilisation de plusieurs milliers de micro-robots identiques travaillant ensemble sur une tâche plutôt qu un seul gros robot. D autres travaux ont été développés, comme ceux d une équipe de l université de Bruxelles qui a développé des sociétés de micro-robots utilisés en milieu hostile ou au recueil d échantillons sur d autres planètes [ERC91]. Ces micro-robots sont capables de se débrouiller en s adaptant à l environnement dans lequel ils se trouvent, et en coordonnant leurs actions pour atteindre leurs buts, tout en assurant le relais lorsque l un d eux tombe en panne. a) Structure d un agent réactif Un agent réactif peut être modélisé par un simple objet doté d un comportement et d un moyen de communication avec les autres agents. Il n a pas de connaissance sur les autres, de capacité de raisonner sur les messages qu il reçoit, ou de développer des stratégies de contrôle. Un agent réactif est plus centré sur le comportement que sur la connaissance. En fait, un agent réactif n a pas de représentation explicite des compétences et des rôles des autres agents. Ses connaissances se limitent aux relations de dépendance qu il a avec les autres agents. 36

Chapitre II : LES SYSTEMES MULTI-AGENTS b) Fonctionnement d un agent réactif Un agent réactif fonctionne selon le principe stimulus/action. Il perçoit les événements provenant de son environnement grâce à sa capacité de perception. Ces connaissances sont représentées par un ensemble de relations «condition-action», où une condition représente un événement. Ensuite, l agent réactif agit en fonction de ces connaissances en prenant la décision d une action, puis il exécute cette action. Environnement Agent réactif Évènement Perception Décision d une action Exécution de l action Action Figure 14 : Fonctionnement d un agent réactif II.2.3.3 Agents hybrides A partir de leurs définitions, on peut facilement distinguer un agent cognitif d un agent réactif. Mais dans la littérature la confusion existe, par exemple, un agent qui adapte son plan en temps réel suivant les changements de l environnement est de type réactif [MAV00], alors que la notion de plan est plutôt utilisée dans l approche cognitive [AND03]. Afin de déterminer le type d agent à utiliser, Ferber propose de déterminer d abord la relation entre l agent et son environnement en essayant de savoir le type de représentation du monde qui l entoure : si la représentation est sub-symbolique, c est-à-dire basée sur ses capacités sensori-motrices, on parlera d agent réactif ; par contre, si la représentation est symbolique et explicite et lui permet de raisonner on parlera d agent cognitif. Dans le cadre de la Vie Artificielle, on remarque que : les animaux sont le plus souvent modélisés comme des agents réactifs car leurs comportements est à base d instinct ; par contre, les humains sont plutôt considérées comme des agents cognitifs étant donné que leur capacité à raisonner prime sur leur partie instinctive [AND03]. 37

Chapitre II : LES SYSTEMES MULTI-AGENTS Pour modéliser certains systèmes, nous avons parfois besoin d agents hybrides. Les agents hybrides sont une combinaison des deux types d'agents qui permet de maximiser les forces et de minimiser les faiblesses de chaque approche (cognitive et réactive). II.2.3.4 Comparatif entre agents cognitifs et agents réactifs Les systèmes d agents cognitifs sont basés sur la coopération entre un petit nombre d'agents. La résolution des problèmes se fait grâce aux compétences de chaque agent, et par la capacité des agents à coordonner leurs actions ainsi qu'à coopérer entre eux. Les agents utilisés dans ces systèmes sont complexes du fait de leur forte granularité. Les systèmes d agents réactifs sont eux basés sur la coopération entre un grand nombre d'agents de faible granularité. Ces systèmes fonctionnent selon des mécanismes simples de réactions aux événements (stimulus/action) pouvant faire émerger des comportements correspondant aux objectifs poursuivis. Dans le tableau qui suit, nous présentons les principales différences qui existent entre les systèmes d agents cognitifs et les systèmes d agents réactifs. Systèmes d agents cognitifs Représentation explicite de l environnement Agents complexes Petit nombre d agents Prise en compte des actions passées Systèmes d agents réactifs Pas de représentation explicite de l environnement Fonctionnement stimulus/action Grand nombre d agents Pas de mémoire des actions passées Tableau 2 : Comparatif entre Agents cognitifs et Agents réactifs [REI90] II.3 SYSTÈME MULTI-AGENT (SMA) II.3.1 Définition d un SMA Un système multi-agent est «un ensemble d entités qui coordonnent leurs connaissances, buts, expériences et plans pour agir ou résoudre des problèmes, incluant le problème de la coordination inter-agent lui-même» [BON88] ou encore «un monde artificiel peuplé de processus inter-agissants est appelé système multi-agents» [AVO92]. On peut donc dire qu un système multi-agent est un ensemble d agents qui interagissent entreeux pour résoudre un problème dont le comportement global est intelligent. 38

Chapitre II : LES SYSTEMES MULTI-AGENTS Le comportement du système est la résultante des interactions entre les comportements individuels des agents. A 1 A 2 A 3 A 4 A 5 A i Relation organisationnelle Interaction Agent i Vue de l environnement / Sphère d influence Environnement Figure 15 : Vue canonique d un système multiagent [JEN00] Jacques Ferber définit un système multi-agents comme suit [FER95]: "On appelle système multi-agents (ou SMA) un système composé des éléments suivants : 1. Un environnement E, c'est à dire un espace disposant généralement d'une métrique. 2. Un ensemble d'objets O. Ces objets sont situés, c'est à dire que, pour tout objet, il est possible à un moment donné d'associer une position dans E. Ces objets sont passifs, c'est à dire qu'ils peuvent être perçus, crées, détruits et modifiés par les agents. 3. Un ensemble A d'agents, qui sont des objets particuliers (A O), lesquels représentent les entités actives du système. 4. Un ensemble de relations R qui unissent des objets (et donc des agents) entre eux. 5. Un ensemble d'opérations Op permettant aux agents de A de percevoir, produire, consommer, transformer et manipuler des objets de O. 39

Chapitre II : LES SYSTEMES MULTI-AGENTS 6. Des opérateurs chargés de représenter l'application de ces opérations et la réaction du monde à cette tentative de modification, que l'on appellera les lois de l'univers." Figure 16 : Système multi-agent Un exemple de système multi-agent est une équipe de robots footballeurs. Dans ce système, si chaque robot a un comportement bien précis et limité, adapté à sa fonction dans l équipe (attaquant, arrière gauche, ), l ensemble qu ils forment a un objectif commun qui est atteint par le résultat de leurs actions individuelles et interactions [MAN02]. II.3.2 Environnement d un système multi-agent L environnement dans un système multi-agent est un élément assez important. Ce peut être l environnement géographique, social, informatique, etc., selon le système en question. L'environnement d'un agent désigne tout ce qui est extérieur à l'agent. On distingue l'environnement dit social, c'est-à-dire les agents qu'il connaît, et l'environnement dit physique constitué des ressources matérielles présentes dans le champ de perception de l'agent. L'environnement possède les caractéristiques suivantes [RUS95][LIN01] : Accessible ou inaccessible : dans un environnement accessible, le système peut obtenir une information complète, exacte et à jour sur l'état de son environnement. Dans un environnement inaccessible, seule une information partielle est disponible. 40

Chapitre II : LES SYSTEMES MULTI-AGENTS Continu ou discret : Dans un environnement continu, le nombre d'actions et de perceptions possibles dans cet environnement est infini. Dans un environnement discret, le système possède des perceptions distinctes, clairement définies qui décrivent l'environnement. Déterministe ou non déterministe : Dans un environnement déterministe, une action a un effet unique et certain. Si le système agit dans son environnement, il n'y a aucune incertitude sur l'effet de son action sur l'état de l'environnement. L'état suivant de l'environnement est complètement déterminé par l'état courant. Dans un environnement non déterministe, une action n'a pas un effet unique garanti. Par nature, le monde physique réel est un environnement non déterministe. Dynamique ou statique : L'état d'un environnement dynamique dépend des actions du système qui se trouve dans cet environnement mais aussi des actions d'autres processus. Aussi, les changements ne peuvent pas être prédits par le système. Un environnement statique ne peut changer sans que le système agisse. II.3.3 L organisation dans un système multiagent On peut facilement assimiler un système multiagent à une société d agents basée sur un ensemble de règles régissant les interactions entre ses membres, et donc caractérisée par son organisation. L organisation d un système multi-agent est la manière dont le groupe est constitué, à un instant donné, pour pouvoir fonctionner. Elle décrit l ensemble des composants fonctionnels du système, leurs natures, leurs responsabilités et leurs besoins en ressources ainsi que les liens de communication entre agents [LAB93]. Dans un système multi-agent, les agents ont des rôles. Le cadre organisationnel fixe les rôles des agents dans un groupe et donc les règles d interaction entre eux. Dans un système multi-agent, l organisation peut être statique ou dynamique. Lorsque l organisation est dynamique, le groupe d agents se réorganise en fonction de la tâche à accomplir. En IAD, les structures organisationnelles se classent selon trois facteurs [LAB93]: 1. le type de décentralisation qui est aussi lié au type de communication entre agents ; 2. le type des agents du groupe ; 3. le mode de coopération entre les agents. 41

Chapitre II : LES SYSTEMES MULTI-AGENTS En général, on retrouve deux formes d organisation : la première est une organisation émergente et la deuxième est une organisation support d activité. Organisation émergente : Dans le cas d une société d agents réactifs, par exemple, la structure organisationnelle émerge des comportements de ses membres, c est alors qu une forme d organisation se met en place graduellement. Organisation support d activité : Cette structure organisationnelle est plus ou moins flexible et autoadaptative [MAN99], mais les comportements des agents vis-à-vis de leurs congénères sont limités par leurs rôles respectifs. Ce type d organisation se rapproche des organisations humaines car chaque agent est autonome tout en ayant connaissance de ses devoirs et de la manière dont il doit se comporter avec les autres agents. Par exemple, un agent se comportera différemment avec un agent pair (même niveau hiérarchique) qu avec un agent manager (supérieur hiérarchique). II.3.4 Coopération entre agents Dans les systèmes multi-agents, les agents sont amenés à coopérer pour la résolution des problèmes, la notion de coopération est ici très importante dans la mesure où elle permet à un agent de [LAB93]: Déléguer une tache qu il ne sait pas résoudre à un autre agent, Interrompre un plan pour aider d autres agents, Intégrer des informations provenant des autres agents, et Mettre à jour sa représentation de l environnement. Coopération et structure d organisation : D après Bond [BON90], deux architectures d organisation pour les sociétés d agents existent : la structure horizontale et la structure verticale. La structure horizontale est utilisée lorsqu il n y a pas de relation maître esclave entre les agents, ils sont tous au même niveau. Dans ce type d organisation, on peut avoir un groupe d agents de différentes spécialités travaillant ensemble pour résoudre un même problème. La structure verticale est, par contre, utilisée lorsqu une hiérarchie existe entre les agents. Les agents, dans ce type d organisation, sont structurés par niveaux. Chaque niveau représente un 42

Chapitre II : LES SYSTEMES MULTI-AGENTS degré d abstraction du problème. Les agents d un même niveau sont organisés en structure horizontale. Les agents de telles sociétés fonctionnent comme suit : L agent reçoit le problème à résoudre d un agent supérieur dans la hiérarchie, il le décompose en sous-problèmes qu il : - peut résoudre localement, - pourrait résoudre en coopérant avec les autres agents du même niveau, - fait suivre aux agents de niveau inférieur. Modes de coopération : Indépendamment de l organisation des agents, la coopération peut se faire suivant les modes suivants : 1. Mode «coopération par partage de tâches et de résultats», où la prise en compte locale de plans d autres agents est possible. 2. Mode «commande» : un agent superviseur décompose le problème en sousproblèmes qu il répartit entre les autres agents. Ces derniers renvoient les solutions partielles trouvées à l agent superviseur. 3. Mode «appel d offre» : l agent A décompose le problème puis diffuse la liste des sous-problèmes aux agents Xi. Parmi les agents Xi certains vont vouloir soumettre une offre à l agent A ; ce dernier va sélectionner les offres puis distribuer les sousproblèmes aux agents. Ensuite, le système suivra le mode commande. 4. Mode «compétition» : l agent A décompose le problème puis il diffuse la liste des sous-problèmes aux agents Xi, comme dans le mode appel d offre. Chaque agent Xi procède à la résolution d un ou de plusieurs sous-problèmes, puis il envoie les résultats à l agent A. Enfin, l agent A fait le tri parmi les résultats envoyés par les différents agents. II.3.5 Résolution de conflits Lorsque des agents doivent coopérer entre eux, il peut y avoir des situations conflictuelles. Afin d éviter les conflits éventuels, les agents peuvent être amenés à coordonner leurs activités et à négocier leurs actions pour atteindre leurs buts. II.3.5.1 Coordination La coordination [LAB93] permet aux agents de considérer toutes les taches et de ne pas dupliquer le travail. La coordination est liée à la planification et à la résolution de conflits. 43

Chapitre II : LES SYSTEMES MULTI-AGENTS Aussi, la coordination peut être centralisée ou décentralisée : si elle est centralisée, un système central détermine et planifie globalement les actions des différents agents ; par contre, si elle est décentralisée, les agents sont totalement autonomes et c est à eux d identifier les éventuels conflits et de les résoudre localement. II.3.5.2 Négociation Pour résoudre les conflits entre agents, on utilise des mécanismes de négociation pour trouver une solution. Pour cela, le système doit prendre en considération les buts sur lesquels il doit se focaliser, et les différents points de vue des agents. La négociation est caractérisée par [LAB93] : - un nombre faible d agents impliqués dans le processus, - un protocole minimal d actions : proposer, évaluer, modifier et accepter ou refuser une solution. A l issue d une négociation, on peut aboutir soit à un compromis, ou bien à la modification des croyances de certains agents afin de faire prévaloir un point de vue. Pour faciliter la convergence vers une solution, dans un processus de négociation, l utilisation d un protocole est nécessaire [LAB93]. Par exemple, lors d une négociation entre deux agents A et B, la structure de négociation serait comme suit [LAB93]: 1. A fait une proposition ; 2. B évalue la proposition et détermine la satisfaction qui en résulte ; 3. Si l agent B est satisfait alors arrêt, sinon B élabore une contre-proposition et donne des arguments ; 4. Si A considère les arguments de B alors on reprend ce schéma en inter-changeant A et B, sinon il faut faire intervenir un troisième agent. II.3.6 Communication entre agents Sans communication, il est impossible de synchroniser les actions des agents et de résoudre les conflits par la négociation. La notion de communication est à la base de la résolution coopérative des problèmes. Pour pouvoir communiquer, un agent doit : connaître les agents avec lesquels il est en relation (accointances), utiliser un support de communication, et utiliser un langage de communication commun. 44

Chapitre II : LES SYSTEMES MULTI-AGENTS a) Support de communication : Les mécanismes de communication les plus utilisés comme support de communication sont : le mécanisme du «tableau noir» et le mécanisme de message. En fait, ces mécanismes sont basés sur les modèles de systèmes d Intelligence Artificielle Distribuée : le modèle de tableau noir et le modèle acteur. a.1. Mécanisme du tableau noir Le mécanisme du tableau noir est souvent présenté en utilisant la métaphore suivante [WEI99]: «Imaginez un groupe de spécialistes (agents humains ou autres) assis à côté d'un grand tableau noir. Les spécialistes travaillent en coopération pour résoudre un problème, en utilisant le tableau noir comme lieu de travail pour dégager la solution. La résolution des problèmes commence quand le problème et les données initiales sont écrits sur le tableau noir. Les spécialistes observent le tableau noir, recherchant l opportunité d'apporter leur expertise à la solution en développement. Quand un spécialiste trouve une information suffisante pour apporter une contribution, il l inscrit sur le tableau noir. Cette information additionnelle peut permettre à d'autres spécialistes d'apporter leur expertise. Ce processus d'ajout des contributions au tableau noir continue jusqu'à ce que le problème ait été résolu.» Tableau noir (zone de communication) SC1 SCi SCn Mécanisme de contrôle Figure 17 : Architecture du modèle de tableau noir Un système utilisant un tableau noir est basé sur les trois composants suivants [HAY85][ENG88][FER89][HAT91] : 45

Chapitre II : LES SYSTEMES MULTI-AGENTS o Le tableau noir Le tableau noir représente une zone de données commune qui contient les données, les solutions en développement et la solution globale du problème à résoudre. Cette zone est accessible aux différentes sources de connaissances. o Les sources de connaissances (SC) ou «Knowledge Sources» Une source de connaissance est une entité disposant d une expertise particulière comme un spécialiste dans la métaphore présentée précédemment, elle peut être représentée par un module. Ainsi, l ensemble des modules représente les connaissances du domaine nécessaire à la résolution du problème. Chaque source de connaissance contribue à la résolution du problème en fournissant des éléments d informations. Les sources de connaissances représentent les agents d un système multi-agents. La communication entre les différents agents se fait via le tableau noir sans s appeler mutuellement, chacun ignorant l existence de l autre. C est à partir de cette coopération aveugle que devra naître la solution au problème commun [MEL04]. o Le mécanisme de contrôle Ce mécanisme est responsable du contrôle du cours de la résolution des problèmes. Ce composant de contrôle peut être vu comme étant un spécialiste qui dirige la résolution des problèmes, en considérant l'avantage global des contributions qui seraient apportées par les sources de connaissances [WEI99]. Les systèmes basés sur un tableau noir sont caractérisés par une communication indirecte et centralisée, ce qui peut produire des goulots d étranglement [MAN02]. a.2. Mécanisme par messages A l origine, le mécanisme par envoi de messages a été étudié dans le cadre des modèles acteurs [BRI89]. Le modèle acteur est une extension du modèle objet par ajout de la notion d activité. Les objets appelés acteurs sont des agents actifs, autonomes, communiquant entre eux librement. Les acteurs évoluent dans un environnement dynamique, dans lequel des activités se créent, se déroulent et s achèvent. Les acteurs participent aux activités, en communiquant entre eux pour se confier ou se déléguer des tâches et se transmettre des résultats [MAS90]. Au niveau local, un acteur est constitué de trois composants : - une connaissance de son environnement ; 46

Chapitre II : LES SYSTEMES MULTI-AGENTS - une connaissance d un ensemble de noms d autres acteurs ; - un ensemble de données. Ces composantes permettent la définition du comportement local de l acteur en fonction du message qu il reçoit. Par exemple, lorsqu un acteur reçoit un message, il ne peut le transmettre qu aux acteurs qu il connaît. Il peut aussi créer de nouveaux acteurs ou modifier son état interne. Le mécanisme par envoi de messages, contrairement au mécanisme du tableau noir, permet une distribution totale des connaissances et du contrôle [FER89]. Un acteur peut représenter un agent. Chaque agent manipule sa propre base de connaissance locale, et il peut envoyer des messages aux autres agents de façon directe. Base locale Agent Agent Agent Base locale Agent Agent Base locale Base locale Base locale Figure 18 : communication par envoi de messages b) Protocole de communication : Pour pouvoir échanger des informations et coopérer pour la résolution d un problème, les agents doivent disposer d un langage commun. Ce langage est un ensemble de primitives qui constituent un protocole de communication. Dans tout protocole de communication, on retrouve les quatre primitives de base suivantes : - Etablir une connexion entre deux entités ; - Identifier un nœud destinataire dans un réseau de communication ; - Envoyer des données ; 47

Chapitre II : LES SYSTEMES MULTI-AGENTS - Recevoir des données. Un des langages les plus populaires [MAN02] est le langage KQML (Knowledge Query and Manipulation language). Le KQML a été conçu comme un format standard de message, autorisant un protocole de communication temps réel supportant le partage d informations entre les agents. c) Définition des accointances : Les accointances représentent les relations entre agents. Ces relations peuvent être statiques (définies dès la conception), ou alors elles peuvent être déclarées de manière dynamique en fonction des changements de l environnement. Donc lorsqu il s agit de définir les accointances dynamiquement, il faudra déterminer la capacité de l agent à reconnaître d autres agents coopératifs. La reconnaissance des autres agents dans l environnement dépend de leur localisation et de la capacité perceptive de l agent. Ainsi, les agents peuvent percevoir les agents qui agissent dans le même environnement. II.3.7 Contrôle et prise de décision Les mécanismes de contrôle, dans un système multi-agents, peuvent très bien se faire par les mécanismes de contrôle locaux des agents. Ou encore, le contrôle du système peut être attribué à des agents particuliers (superviseurs) qui auront soit des relations «maître - esclave» avec les autres agents, soit des relations de «guide» pour la mise en action ou en attente des agents. Les mécanismes de décision prennent en charge tout ce qui concerne l allocation de tâches ou de ressources lorsqu il s agit de résoudre un conflit, incluant la partie décisionnelle des protocoles de négociation. II.3.8 Conception d un système multi-agent Plusieurs méthodologies de développement de systèmes multi-agents ont été jusque là proposées [WOO00][DEL99][KIN96][ELA99][KEN96][COL96][MOU96][IGL98][GLA96]. Ces méthodologies représentent soit une extension des méthodologies orientées-objet, soit une extension des méthodologies à base de connaissance. Aussi, ces méthodologies sont largement critiquées et elles sont jugées incomplètes [SAB01][SAB02]. De façon générale, pour concevoir un SMA, il faut procéder à la spécification de chaque agent qui le compose puis à la spécification des interactions entre agents. 48

Chapitre II : LES SYSTEMES MULTI-AGENTS II.3.8.1 Spécification d un agent La notion d agent est difficile à spécifier. Pour rendre cette tâche plus facile, nous allons mettre en évidence les principales caractéristiques nécessaires à la conception d un agent. Ces caractéristiques sont [MAN02]: - le niveau de granularité souhaité ; - l identité propre de l agent ; - et, le type de raisonnement que l agent utilise pour manipuler les informations qu il reçoit. a) Informations manipulées Le concepteur doit déterminer les informations manipulées dans le système à concevoir, une étude doit donc être faite afin d extraire l expertise nécessaire pour traiter ces informations. Le concepteur doit effectuer un choix dans la définition des agents ainsi que les informations que ces derniers peuvent manipuler. Aussi, il faudra faire la distinction entre les agents (acteurs de l environnement) et les objets (c est-à-dire les informations propres à cet environnement). La granularité des agents est déterminée à partir des informations manipulées par ces derniers. Aussi, le nombre d agents nécessaire sera déterminé de manière à réduire les temps de calculs. b) Identité de l agent L agent possède une identité [MAN02]: un nom et un numéro qui l identifie dans la classe d agents. Du fait qu il est identifié, l agent possède des caractéristiques comportementales prédéfinies qui sont persistantes sur des périodes relativement longues. c) Capacités perceptives Le concepteur doit définir, pour chaque agent, si sa perception est locale (vue partielle) ou globale, et si l agent a la possibilité d intégrer dans ces connaissances de nouvelles informations acquises en agissant ou en se déplaçant dans son environnement. La capacité de perception d un agent lui permet de mettre à jour la représentation qu il a de son environnement. Cette représentation est une modélisation de l environnement qui est limitée par la sphère d influence de l agent (voir la Figure 15 page 39). La perception peut être de deux types : 49

Chapitre II : LES SYSTEMES MULTI-AGENTS La perception passive où l agent reçoit des données sans qu il n ait réalisé d action particulière pour les obtenir ; ou La perception active qui est le résultat d une action entreprise par l agent. Par exemple, un robot qui reçoit des données à l aide de ses capteurs en explorant son environnement. d) Raisonnement de l agent Le concepteur doit déduire le type de raisonnement qu un agent utilise, à partir de la façon dont ce dernier doit traiter les informations qu il perçoit. Un agent peut avoir soit un raisonnement «réflexe» ou «réactif», soit un raisonnement «cognitif», ou bien un mélange des deux (hybride). En fait plus le raisonnement des agents est simple, plus les interactions entre agents devront être performantes. e) Capacités d action Nous avons vu précédemment, que chaque agent d un système agit en fonction des événements survenus dans son environnement. C est pourquoi le concepteur d un système doit définir la capacité d action de chaque agent, afin de permettre aux agents d agir et de modifier l environnement. Dans le cas d un agent réactif, la capacité d action fait suite à un ensemble de conditions vérifiées dans le monde extérieur à cet agent. Par contre, pour un agent de plus haut niveau, cette capacité d action peut être définie par un processus de planification. Avec une telle capacité, l agent peut générer un ensemble d actions (plan) à effectuer ou à faire réaliser par d autres agents, et ce en fonction de ses connaissances et ses croyances ainsi que ses buts. II.3.8.2 Spécification des interactions Les interactions entre agents représentent un aspect important dans un système multi-agent. Dans ce qui suit nous allons détailler les deux éléments liés aux interactions inter-agents, à savoir la capacité communicative et la capacité sociale. a) Capacités communicatives La mise en œuvre de la communication entre agents rencontre des contraintes particulières. Ces contraintes sont classées en trois niveaux : - la définition du support de la communication, 50

Chapitre II : LES SYSTEMES MULTI-AGENTS - l utilisation d un langage de communication, et - la définition des accointances d un agent. Le concepteur devra définir : le mécanisme de communication adéquat (mécanisme de tableau noir ou mécanisme par message), le langage que les agents utiliseront pour pouvoir communiquer, et les accointances afin de savoir qui doit communiquer avec qui. b) Capacités sociales Les capacités sociales d un agent représentent essentiellement la notion de coordination. Il s agit là de déterminer si un agent possède une fonction de coordonnateur, dans un contexte centralisé. Cet agent coordonnateur se charge de rassembler toutes les informations nécessaires à la coordination de l ensemble (il connaît les taches à réaliser et les agents ayant les capacités correspondantes) afin de pouvoir allouer les tâches aux agents. Aussi, ce rôle de coordination permet de gérer les contraintes, de ressources et de temps, entre les actions à planifier [MAN02]. Dans un contexte distribué, comme pour les SMA, la coordination est également distribuée dans le sens où lorsqu il est nécessaire de coordonner un groupe d agent, elle doit être mise en œuvre localement. Du moment où des agents doivent interagir pour régler des conflits, des capacités sociales s avèrent nécessaires. 51

Chapitre II : LES SYSTEMES MULTI-AGENTS PARTIE 2 : LES SMA ET LES TESTS LOGICIELS II.4 Travaux sur la modélisation des tests logiciels par les SMA Les recherches que nous avons effectués sur l utilisation des systèmes multi-agents pour la modélisation des tests logiciels, nous ont mené à la découverte de quelques travaux réalisés dans le domaine : les travaux de «Choi & Choi» [CHO02], et les travaux de «Dhavachelvan, Uma & Venkatachalapathy» [DHA05][DHA06]. Dans ce qui suit nous allons résumer le contenu de ces travaux. Travaux de «Choi & Choi» Choi et Choi ont proposé un système nommé TAS (Test Agent System). Ce système fournit une assistance au testeur (humain), tout en limitant l intervention de ce dernier. Le TAS est composé de trois agents : l agent «User Interface» qui est chargé de l échange de données avec le testeur (humain), l agent «Test Case Selection & Testing» qui est chargé de sélectionner et exécuter les tests sur l ensemble des cas de tests, et l agent «Regression Test» qui est chargé des tests de régression. Les agents du TAS possèdent les propriétés suivantes : l autonomie, la sociabilité, et l intelligence. Les agents du TAS mènent les tests de façon autonome en employant des règles intelligentes dans le processus de test. Le TAS traite les tests de logiciels programmés en langages orientés-objet, pour des besoins exprimés par l industrie. Agent «User Interface» Agent «Test Case Selection & Testing» Agent «Regression Test» Figure 19 : Les agents du TAS 52

Chapitre II : LES SYSTEMES MULTI-AGENTS Le système proposé intègre un environnement de test graduel allant des tests unitaires aux tests système. Le TAS reçoit en entrée une quantité massive de cas de tests et les diagrammes de conception nécessaires pour les tests. Description des agents du TAS : Agent «User Interface» : Le but principal de cet agent est de voir si le test a réussi ou échoué. L agent «User Interface» est organisé en cinq parties : Une première partie se charge de la planification des tests pour déterminer l ordre d exécution des taches de test. Une deuxième partie se charge de la sélection automatique des listes de tests. Une troisième partie se charge de déduire les buts des tests pour les tests de régression. Une quatrième partie se charge d expliquer le statut de la mémoire pour la gestion des ressources mémoire. Et puis, une cinquième partie se charge de présenter les résultats des tests sur écran. Agent «Test Case Selection & Testing»: Le but de l agent «Test Case Selection & Testing» est de sélectionner un ensemble optimal et d exécuter les tests sur cet ensemble. Cet agent est composé de : Une section pour la sélection des cas de tests, Un conducteur de test qui exécute les tests, et Un oracle de test pour comparer les résultats obtenus par rapport aux résultats prévus. Ce qui permet aussi de pouvoir exprimer la mesure de la qualité des cas de tests (Mesure Qualité = nombre de cas de tests dont les résultats correspondent aux résultats prévus / nombre total de cas de tests). Agent «Regression Test» : Le but de l agent «Regression Test» est de sélectionner les items concernés par les tests de régression ainsi que les items qui y sont liés, puis d exécuter les tests de régression. Cet agent est formé d un moteur de raisonnement qui cherche les items de tests sur lesquels les tests de régression doivent s exécuter et les items qui y sont liés en utilisant des hyperliens. 53

Chapitre II : LES SYSTEMES MULTI-AGENTS Le TAS de Choi & Choi offre les avantages suivants : Les tests sont conduits de façon autonome ce qui limite au maximum l intervention du testeur (humain), L ensemble des cas de tests sélectionnés est optimal (sans redondance et consistant), ce qui réduit le temps de tests, d une part et d autre part, augmente l efficacité de la détection d erreurs. En fait, le système proposé par Choi & Choi permet au testeur de se concentrer plus particulièrement sur la surveillance et l analyse des résultats des tests. L implémentation du système TAS a permis de constater l efficacité de l architecture proposée dans la mesure où la réduction du temps de test est de l ordre de 39.6% pour tout le processus, et le taux de détection d erreurs s est amélioré. Travaux de «Dhavachelvan, Uma & Venkatachalapathy» Dans leurs derniers travaux parus dans l article «A new approach in development of distributed framework for automated software testing using agents» [DHA06], Dhavachelvan et al. proposent un système multi-agent qui prend en charge les tests de plusieurs produits logiciels en même temps. Le système proposé couvre les tests unitaires uniquement. Ce système fournit une justification quantitative, par les résultats expérimentaux, de l utilité des SMA pour les tests de systèmes complexes. Le SMA proposé permet de faire les tests de plusieurs produits logiciels simultanément. De ce fait, le problème majeur à résoudre est celui de l allocation des ressources nécessaires à la conduite des tests. Le système multi-agent proposé est constitué de : Un ensemble d agents distributeurs, Un ensemble d agents testeurs, et Un ensemble d agents testeurs clones. Chaque agent testeur peut créer un ensemble de clones. L approche hybride a été adoptée pour la construction des différents groupes d agents. 54

Chapitre II : LES SYSTEMES MULTI-AGENTS M o n d e e x t e r n e Agents distributeurs Agents testeurs Agents testeurs clones Figure 20 : représentation du système multi-agent de Dhavachelvan et al. [DHA06] De façon générale, un agent distributeur est chargé d analyser et de sélectionner le produit que ses agents testeurs sont capables de tester, d allouer et de négocier les ressources nécessaires à l exécution des tests. Il est aussi chargé de la coordination des activités de ses agents testeurs. Un agent testeur est spécialisé dans une et une seule technique de test, il peut créer un à plusieurs agents testeurs clones. Le nombre maximum d agents clones est de (N-1), N étant le nombre de techniques de tests possibles. Le système proposé autorise l intervention du testeur (humain) pour sélectionner les fonctions exactes à tester, après que les agents testeurs et leurs clones aient découpé le produit logiciel en modules et fonctions. Description des agents du SMA proposé : Agent distributeur : Cet agent est structuré en trois couches : Couche sociale : allocation et négociation des ressources, allocation des taches, classification des techniques de test. Couche réactive : analyse et sélection des produits. Couche cognitive : intégration des rapports de test. 55

Chapitre II : LES SYSTEMES MULTI-AGENTS Agent testeur : Cet agent possède trois couches : Couche sociale : clonage, distribution des taches aux agents clones. Couche réactive : génération automatique des drivers (pilotes) de tests, génération et exécution des cas de tests. Couche cognitive : prédiction du temps de test. Agent testeur clone : La structure d un agent clone est identique à celle de l agent testeur qui l a créé. Mais des restrictions existent pour l agent clone : sa responsabilité est réduite aux taches de tests. L agent clone ne fonctionne pas en mode distributeur, son supérieur hiérarchique est l agent testeur qui l a créé et avec lequel il interagit pour échanger, fournir et recevoir des services, des données et des connaissances. Le clonage dans le système multi-agent de Dhavachelvan et al. offre les avantages suivants : Amélioration du critère d adéquation, Augmentation du taux de détection d erreurs, Réduction des temps d exécution des tests Mais ceci a le désavantage d engendrer une augmentation des testeurs (humains) pour ce qui est manuel car l intervention du testeur est requise pour choisir les fonctions ou modules à tester. II.5 Discussions L utilisation des agents pour automatiser le processus de test est une solution assez intéressante pour régler les problèmes liés aux tests comme la génération des meilleurs scénarios de tests par exemple. D autre part, le concept agent permet de simuler le comportement du testeur, surtout que ce dernier prend une part importante dans la bonne conduite du processus d où l intérêt de l approche. Les systèmes multi-agents conçus par «Choi & Choi» ou «Dhavachelvan et al.» ont donné de bons résultats expérimentaux : réduction du temps de test, amélioration du taux de détection d erreurs, réduction des ressources nécessaires aux tests, etc. Mais, ces systèmes ne permettent de résoudre que quelques problèmes relatifs au processus de tests. 56

Chapitre II : LES SYSTEMES MULTI-AGENTS Le système proposé par Choi & Choi traite les problèmes suivants : Sélection d un ensemble de cas de tests optimal, Les tests de régression (sélection des items concernés), L arrêt des tests, La gestion des ressources mémoire (allocation des ressources). Le système proposé par Dhavachelvan, Uma & Venkatachalapathy traite les problèmes suivants : Allocation et négociation des ressources, Prédiction des temps de tests qui permet de mesurer la progression des tests, Génération et sélection des cas de tests unitaires. Le contexte particulier du système de Dhavachelvan et al. fait que le problème principal est l allocation et la négociation des ressources, car ce système permet les tests de plusieurs produits logiciels simultanément. Les systèmes proposés se limitent aux tests dynamiques et donc ne permettent pas d avoir une approche permettant de modéliser le processus global de test. Les tests statiques ne sont pas pris en compte alors que leur efficacité a été démontrée [DEM87][FAG86][MIL87] pour la détection d erreurs. II.6 CONCLUSION Vu l intérêt du concept agent, pour la résolution de problèmes, l utilisation d un système multi-agent pour la modélisation du processus de test logiciel représente une perspective assez intéressante. Modéliser le processus de test logiciel consiste à identifier les différents problèmes à résoudre pour pouvoir mieux identifier les agents et leurs rôles, et identifier les différentes interactions qui existent entre les agents. Les travaux effectués dans la modélisation des tests logiciels par un système multi-agent se sont avérés efficaces pour la résolution de certains problèmes tels que l explosion combinatoire des cas de tests ou l allocation des ressources. Il reste cependant quelques problèmes qui ne sont pas encore résolus comme l automatisation des tests statiques. Dans le chapitre suivant, nous allons présenter notre approche de modélisation du processus de test logiciel par un système multi-agent. 57

Chapitre III : CONCEPTION III Chapitre III : Conception III.1 INTRODUCTION Le système multi-agent que nous proposons possède la particularité de prendre en compte les tests statiques en plus des tests dynamiques. Notre démarche de modélisation commence par le découpage du problème global en sous-problèmes pour déduire une architecture globale, puis nous procéderons à la spécification des agents de notre système et des interactions qu il y a entre eux. III.2 Découpage du problème global en sous-problèmes Pour une meilleure modélisation du processus de test logiciel, nous allons découper le système global de façon à faire ressortir les sous-problèmes à résoudre. Les sous-problèmes recensés sont les suivants : Génération d un ensemble de cas de test optimal (explosion combinatoire) ; Choix des techniques adéquates ; Tests de régression ; Parallélisation des tests unitaires ; Intégration des unités ; Tests des caractéristiques du système ; Automatisation des tests statiques (exploiter l expertise des testeurs) ; Arrêt des tests ; Mesure de la progression des tests. 58

Chapitre III : CONCEPTION Problèmes de tests logiciels Tests statiques Tests de régression Tests unitaires Progression des tests Génération des cas de tests Tests d intégration Tests système Figure 21 : Découpage du problème global en sous-problèmes Dans le tableau qui suit, nous mettons en évidence les interdépendances entre les sousproblèmes précédemment énumérés. Sousproblème Tests statiques Génération des cas de tests Tests de régression Tests d intégration Tests unitaires Tests système Progression des tests Tests statiques Génération des cas de tests Tests de régression Tests d intégration Tests unitaires Tests système Progression des tests + + + + + + + + + + + + + + + + + + + + + + + + + + + Tableau 3 : Interdépendances entre sous-problèmes Le découpage du programme global ainsi que les interdépendances entre les sous problèmes associés nous amène à adopter comme démarche globale de test logiciel le processus de test suivant : 59

Chapitre III : CONCEPTION Produit logiciel (documents de conception, code,...) Tests statiques Produit logiciel testé (documents de conception, ) Tests de régression Code Tests unitaires Tests d intégration Mesure de progression Tests système Code testé Figure 22 : Processus global de test Notre système commence d abord par effectuer des tests statiques sur les produits logiciels (documents de conception, code, ) afin de détecter les erreurs au plus tôt. Puis, en ce qui concerne le code du logiciel, le système effectue des tests dynamiques afin de s assurer que le logiciel est opérationnel. Lors des tests dynamiques, notre système commence par exécuter les tests unitaires, ensuite les tests d intégration puis les tests systèmes. Les tests de régression sont effectués lorsque le code a été corrigé suite à la détection d erreurs. Tout au long du processus, notre système mesure la progression des tests. Notre système s arrête lorsque les tests système sont achevés. 60

Chapitre III : CONCEPTION L examen approfondi de notre modélisation, nous a permis de déduire une architecture globale du système multi-agents que nous proposons dans ce qui suit. III.3 Architecture du SMA pour la modélisation du processus global de test L architecture globale de notre système multi-agents est représentée dans la figure suivante : «SMA pour le processus de test logiciel» Testeur (humain) Agent superviseur Agent analyseur Agent test unitaire Agent de régression Agent test d intégration Agent test système Figure 23 : Architecture globale du système multi-agents pour le processus de test logiciel Cette architecture est basée sur un groupe d agents constituant notre système multi-agents. Ces agents communiquent entre eux pour effectuer les taches relatives au processus de test logiciel. Ce groupe d agent est organisé de façon à ce qu un agent superviseur contrôle et coordonne les différentes tâches, c est cet agent là qui va piloter les tests. Chaque agent de notre système possède sa propre base de connaissances. Dans ce qui suit nous allons procéder à la spécification des différents agents du système multi-agents que nous proposons, puis à la spécification des interactions qui existent entre eux. 61

Chapitre III : CONCEPTION III.3.1 Spécification des agents Pour la spécification des agents, nous allons présenter pour chaque agent son rôle et les taches qu il peut accomplir. Notre système multi-agents est composé de six agents (classes d agents): agent superviseur, agent analyseur, agent de régression, agent test unitaire, agent test d intégration et agent test système. Dans ce qui suit nous allons présenter, pour chaque agent, son rôle et ses tâches. 1. Agent superviseur : Rôle : pilotage des tests Tâches : - Réception du produit logiciel à tester, des plans de tests, des délais. - Planification des taches. - Allocation des ressources. - Allocation des taches (tests statiques, tests unitaires, intégration, système, régression, ). - Mise à jour de l historique des tests. - Elaboration d états de progression des tests. - Réception des rapports de tests partiels et élaboration des rapports globaux. 2. Agent analyseur : Rôle : expert dans une technique statique Tâches : - Soumission aux appels d offre du superviseur. - Analyse d un produit logiciel. - Envoi d informations sur la progression des tests. - Envoi de rapport de tests statiques. - Prédiction des temps de test. 3. Agent de régression : Rôle : organisation des tests de régression Tâches : - Réception du nouveau code. - Vérification de l adéquation des cas de tests de la version antérieure du logiciel. - Envoi d informations sur la progression des tests. - Envoi de rapport de tests de régression. 62

Chapitre III : CONCEPTION - Prédiction des temps de test. - Soumission aux appels d offre du superviseur. 4. Agent test unitaire : Rôle : expert en tests unitaires Tâches : - Génération et sélection de cas de tests unitaires. - Exécution des tests. - Envoi d informations sur la progression des tests. - Envoi de rapport de tests. - Prédiction des temps de test des unités logicielles. - Soumission aux appels d offre du superviseur. 5. Agent test d intégration : Rôle : intégration d unités Tâches : - Intégration des unités. - Génération et sélection de cas de tests d intégration. - Exécution des tests d intégration. - Envoi d informations sur la progression des tests. - Envoi de rapport de tests d intégration - Prédiction des temps de test. - Soumission aux appels d offre du superviseur. 6. Agent test système : Rôle : exécution des tests système (expert dans le test d une caractéristique) Tâches : - Génération et sélection de cas de tests système. - Exécution des tests. - Envoi d informations sur la progression des tests. - Envoi de rapport de tests système. - Prédiction des temps de test. - Soumission aux appels d offre du superviseur. 63

Chapitre III : CONCEPTION III.3.2 Modélisation globale du processus de test Le processus global de test logiciel, sur lequel est basé notre système, est lui-même composé d un certain nombre de processus, nous les avons recensés comme suit : Processus de tests unitaires ; Processus de tests d intégration ; Processus de tests système ; Processus de tests statiques ; Processus de tests de régression ; Processus de mesure de la progression des tests. Dans ce qui suit, nous allons modéliser les différents processus cités ci-dessus. Afin de mieux représenter les interactions entre agents, nous avons choisi d utiliser la notation UML (Unified Modeling Language) [BAU05]. Actuellement, les extensions d UML permettent de décrire les notions relatives aux agents comme la représentation des interactions entre agents. Il faut noter que l extension d UML pour la modélisation des systèmes multi-agents connaît actuellement un engouement particulier de la part des chercheurs et des développeurs, ce qui conforte notre choix de notation. III.3.2.1 Modélisation du processus de tests unitaires Description du processus : L agent superviseur est chargé de répartir les unités logicielles à tester aux différents agents de tests unitaires disponibles. Pour ce faire, l agent superviseur lance un appel d offre aux agents tests unitaires disponibles, dans la limite des ressources allouées, afin d obtenir les meilleurs temps d exécution des tests unitaires. Les agents tests unitaires sollicités doivent répondre à l appel d offre en soumettant une proposition pour chaque unité qu ils peuvent tester. Dès que l agent superviseur reçoit les offres, il doit sélectionner les meilleures afin d optimiser le temps global des tests unitaires. Une fois la sélection effectuée, les agents tests unitaires sélectionnés doivent effectuer les tests unitaires. Ces derniers commencent d abord par générer les meilleurs cas de tests pour les unités à leur charge, puis pour chaque unité lancer l exécution des tests aussitôt que les cas de tests sont disponibles. Une fois l exécution des tests d une unité terminée, l agent test unitaire envoie un rapport de test unitaire à l agent superviseur. 64

Chapitre III : CONCEPTION A la fin des tests de toutes les unités, l agent superviseur génère un rapport de test unitaire global qui sera envoyé au testeur (humain). Le testeur devra par la suite donner une évaluation finale des résultats des tests. Cette dernière sera ensuite envoyée à l agent superviseur, ce qui permettra de connaître les unités correctes et celles qui sont à corriger. Les résultats des tests et leur évaluation finale seront mémorisés afin de constituer l historique des tests. La représentation graphique du processus de tests unitaires est illustrée dans la Figure 24. Agent test unitaire 1 1,2, 3,4,5 Agent test unitaire 2 1,2, 3,4,5 Agent superviseur... 4,5,6 1,2,3,4,5 Agent test unitaire m Testeur (humain) 1 : Appel d offre 2 : Offre 3 : Affectation de taches 4 : Unités à tester + Spécifications 5 : Résultats de tests 6 : Evaluation des résultats Figure 24 : Représentation graphique de l architecture de communication du processus tests unitaires Le diagramme d activité du processus de tests unitaires est illustré dans la Figure 25. 65

Chapitre III : CONCEPTION Testeur (humain) Agent superviseur Agent test unitaire Allocation des ressources Appel d offre Traitement de l appel d offre Sélection des offres Allocation de taches Génération de cas de tests Exécution des tests Génération de rapport de tests Génération de rapport de tests Evaluation des résultats de tests Mise à jour Historique des tests Figure 25 : Diagramme d activité du processus de tests unitaires 66

Chapitre III : CONCEPTION Scénario de parallélisation des tests unitaires : L agent superviseur comptabilise le nombre d agents tests unitaires disponibles en leur envoyant un message pour connaître leur statut. Les agents disponibles seront ensuite sollicités afin de répondre à un appel d offre pour effectuer les tests unitaires des unités logicielles. Les agents sollicités doivent répondre à l appel d offre de l agent superviseur en fournissant la liste des unités qu ils peuvent tester et le temps prévu pour le test de chacune d elles. Une fois toutes les offres réceptionnées, l agent superviseur sélectionne les meilleures offres, puis affecte les unités logicielles aux agents test unitaire choisis de façon à paralléliser au mieux leur intégration en accord avec la stratégie d intégration choisie. Le diagramme de séquence qui suit montre les interactions entre les différents agents. Agent superviseur Agent test unitaire Demande-statut Info-statut Appel-offre Refus x Offre Rejet-offre x Accept-offre Résultat-test-unité (U1) Résultat-test-unité(Un) Figure 26 : Diagramme de séquence du scénario «parallélisation des tests unitaires» 67

Chapitre III : CONCEPTION Primitives d interactions : Primitive Désignation Demande-statut L agent superviseur demande le statut d un agent test unitaire pour savoir s il est disponible. Info-statut L agent test unitaire envoie un message pour informer l agent superviseur s il est disponible ou non. Appel-offre L agent superviseur envoie un appel d offre. Refus L agent test unitaire informe l agent superviseur qu il refuse de répondre à son appel d offre. Offre L agent test unitaire envoie une offre à l agent superviseur. Rejet-offre L agent superviseur informe l agent test unitaire que son offre a été rejetée. Accept-offre L agent superviseur informe l agent test unitaire que son offre a été acceptée. Résultat-test-unité (Ui) L agent test unitaire envoie le résultat des tests unitaire d une unité Ui. III.3.2.2 Modélisation du processus de tests d intégration Description du processus : L agent superviseur envoie au fur et à mesure les unités logicielles testées (correctes) pour être intégrées par les agents tests d intégration. L agent superviseur détermine le nombre d agents tests d intégration nécessaire en fonction des paramètres suivants : - le nombre de sous-systèmes, sachant qu un sous-système est un regroupement de plusieurs unités fortement connexes, - de la stratégie d intégration, et - des ressources disponibles. Chaque agent test d intégration procède à l intégration des unités à sa charge (intégration partielle) selon la stratégie adoptée. Puis, il génère les meilleurs cas de tests d intégration et exécute les tests. Après cela, un rapport de tests d intégration sera envoyé à l agent superviseur. Lorsque toutes les intégrations partielles auront été testées, l agent superviseur désignera un agent test d intégration qui procèdera à l intégration globale du système, ensuite à la génération des meilleurs cas de tests, puis à l exécution des tests. 68

Chapitre III : CONCEPTION Une fois l exécution des tests d intégration du système global terminée, l agent test d intégration envoie un rapport à l agent superviseur qui va le mémoriser dans l historique des tests puis va l envoyer à son tour au testeur (humain). Le testeur, après évaluation des résultats, retourne à l agent superviseur les résultats finaux des tests d intégration en précisant les unités en correction. Ces résultats finaux seront aussi mémorisés dans l historique des tests. La représentation graphique du processus de test d intégration est illustrée dans la Figure 27. Agent superviseur Agent test d intégration 1 1,2,3,4,5,6 1,2,3,4,5 Agent test d intégration 2 6,7 1,2,3,4,5... Agent test d intégration N Testeur (humain) 1 : Allocation de tâches 2 : Unités à intégrer 3 : Plan d intégration 4 : Intégration partielle 5 : Résultats d intégration partielle 6 : Rapport d intégration global 7 : Evaluation des résultats Figure 27 : Représentation graphique de l architecture de communication du processus de tests d intégration Le diagramme d activité du processus de tests d intégration est illustré dans la Figure 28. 69

Chapitre III : CONCEPTION Testeur Agent superviseur Agent test intégration 1 Agent test intégration N Allocation des ressources Allocation de taches Intégration des unités Intégration des unités Génération de cas de tests Génération de cas de tests Exécution des tests Exécution des tests Génération de rapport de tests Génération de rapport de tests Allocation de taches Intégration globale Génération de cas de tests Exécution des tests Génération de rapport Envoi des résultats Evaluation des résultats Mise à jour Historique Tests Figure 28 : Diagramme d activité du processus de tests d intégration 70

Chapitre III : CONCEPTION Scénario d attente d une unité non disponible Lorsqu une unité logicielle n est pas encore disponible (en correction ou en test de régression), l agent test d intégration qui doit l intégrer dans le système (ou le sous-système) envoie un message à l agent superviseur pour l avertir, puis se met en attente. Dès réception de l unité corrigée, l agent superviseur l envoie à l agent test d intégration pour continuer sa tache. Le diagramme de séquence qui suit montre les interactions entre les différents agents. Agent test unitaire/ Agent de régression Agent superviseur Agent test intégration Inform Unité (correcte) Unité (correcte) Résultat-test Figure 29 : Diagramme de séquence du scénario «attente d une unité non disponible» Primitives d interactions : Primitive Désignation Inform L agent test intégration informe l agent superviseur qu il lui manque une unité pour continuer sa tache. Unité(correcte) L agent superviseur reçoit une unité corrigée de l agent test unitaire ou de l agent de régression, et l envoie à l agent test intégration. Résultat-test L agent test intégration envoie le résultat des tests à l agent superviseur. 71

Chapitre III : CONCEPTION III.3.2.3 Modélisation du processus de tests système Description du processus : Afin de tester les caractéristiques que le système (logiciel) doit assurer, l agent superviseur doit sélectionner des agents pour accomplir ces tests. Pour chaque caractéristique à tester, l agent superviseur doit sélectionner un agent test système capable d accomplir la tache dans les meilleurs délais. Pour cela, il lance un appel d offre aux agents tests système. Puis, il sélectionne les meilleures offres et alloue les taches aux agents sélectionnés. Lorsqu un agent test système est sélectionné pour tester une caractéristique, il doit d abord générer les cas de tests puis exécuter les tests. Après l exécution des tests, l agent test système envoie le rapport de tests de la caractéristique qu il a testé à l agent superviseur. L agent superviseur envoie à son tour le rapport de test au testeur (humain) pour une évaluation finale, et procède à la mise à jour de l historique des tests. Lorsque le testeur retourne l évaluation finale des tests, l agent superviseur met à jour l historique des tests de nouveau. La représentation graphique du processus de test système est illustrée dans la Figure 30. 72

Chapitre III : CONCEPTION Agent superviseur Agent test système (Propriété «sécurité») 1,2,3,4,5,6 1,2,3,4,5,6 Agent test système (Propriété «robustesse») 6,7 1,2,3,4,5,6... Agent test système (Propriété «fiabilité») Testeur (humain) 1 : Allocation de tâche 2 : Système (logiciel) à tester 3 : Plan de tests système 4 : Appel d offre 5 : Offre 6 : Rapport de tests 7 : Evaluation des résultats Figure 30 : Représentation graphique de l architecture de communication du processus tests système Le diagramme d activité du processus de tests système est illustré dans la Figure 31. 73

Chapitre III : CONCEPTION Testeur Agent superviseur Agent test systeme Allocation des ressources Appel d offre Traitement de l appel d offre Sélection des offres Allocation de taches Génération de cas de tests Exécution des tests Génération de rapport Envoi des résultats Evaluation des résultats Mise à jour Historique Tests Figure 31 : Diagramme d activité du processus de tests système 74

Chapitre III : CONCEPTION III.3.2.4 Modélisation du processus de tests statiques Description du processus : Pour effectuer le test statique d un produit logiciel (code, documents, ), l agent superviseur doit solliciter des agents analyseurs. Selon qu il s agisse de tester du code, un document de spécifications ou un document de conception, il faudra sélectionner un agent capable d accomplir le test statique avec la technique requise dans les meilleurs délais. Pour cela, l agent superviseur lance un appel d offre aux agents analyseurs. Puis, il sélectionne la meilleure offre et alloue la tache à l agent sélectionné. L agent sélectionné doit ensuite lancer l analyse statique du produit. Après l analyse, l agent analyseur envoie le rapport de tests à l agent superviseur. Ce dernier envoie à son tour le rapport de test au testeur (humain) pour une évaluation finale, et procède à la mise à jour de l historique des tests. Lorsque le testeur retourne l évaluation finale des tests statiques, l agent superviseur met de nouveau à jour l historique des tests. La représentation graphique du processus de test statique est illustrée dans la Figure 32. Agent superviseur Agent analyseur 1,2,3,4,5 1,2,3,4,5... 2,6,7 Agent analyseur Testeur (humain) 1 : Allocation de tâche 2 : Produit logiciel à tester + spécifications 3 : Appel d offre 4 : Offre 5 : Rapport de tests 6 : Evaluation des résultats Figure 32 : Représentation graphique de l architecture de communication du processus de tests statiques 75

Chapitre III : CONCEPTION Le diagramme d activité du processus de tests statiques est illustré dans la Figure 33. Testeur Agent superviseur Agent analyseur Allocation des ressources Appel d offre Traitement de l appel d offre Sélection des offres Allocation de taches Analyse statique Génération de rapport Envoi des résultats Evaluation des résultats Mise à jour Historique Tests Figure 33 : Diagramme d activité du processus de tests statiques 76

Chapitre III : CONCEPTION Scénario d une analyse statique formelle Dans le cas du test d une portion critique du code ou de la vérification d un document de spécifications spécifié formellement, une analyse formelle est requise. Un agent analyseur sera sélectionné pour effectuer la tache par appel d offre. Une fois la tache allouée, l agent analyseur sélectionné effectue la vérification formelle du produit logiciel en question. A la réception des résultats des tests (rapport), l agent superviseur met à jour l historique des tests puis les envoie au testeur. Le diagramme de séquence suivant détaille les interactions entre les différents agents. Agent superviseur Agent analyseur Demande-statut Info-statut Appel-offre Refus x Offre Rejet-offre x Accept-offre Résultats-analyse Figure 34 : Diagramme de séquence du scénario «analyse statique formelle» 77

Chapitre III : CONCEPTION Primitives d interactions : Primitive Désignation Demande-statut L agent superviseur demande le statut d un agent analyseur pour savoir s il est disponible. Info-statut L agent analyseur envoie un message pour informer l agent superviseur s il est disponible ou non. Appel-offre L agent superviseur envoie un appel d offre. Refus L agent analyseur informe l agent superviseur qu il refuse de répondre à son appel d offre. Offre L agent analyseur envoie une offre à l agent superviseur. Rejet-offre L agent superviseur informe l agent analyseur que son offre a été rejetée. Accept-offre L agent superviseur informe l agent analyseur que son offre a été acceptée. Résultat-analyse L agent analyseur envoie le résultat des tests statiques. III.3.2.5 Modélisation du processus de tests de régression Description du processus : Lorsqu une nouvelle version du logiciel (code) est disponible, l agent superviseur sélectionne par appel d offre un agent de régression pour re-tester le code. L agent de régression sélectionné vérifie le critère d adéquation des données de tests sur la nouvelle version du code logiciel pour savoir si les cas de tests de la version antérieure sont bons. Si le critère d adéquation est bon, l agent de régression exécute les tests de nouveau. Après l exécution, l agent de régression envoie le rapport de tests de régression à l agent superviseur. Ce dernier envoie à son tour le rapport de test au testeur (humain) pour une évaluation finale, et procède à la mise à jour de l historique des tests. Lorsque le testeur retourne l évaluation finale des tests, l agent superviseur met de nouveau à jour l historique des tests. Si le critère d adéquation n est pas bon, l agent de régression informe l agent superviseur qui doit reprendre les tests (unitaires ou d intégration) de nouveau. La représentation graphique du processus de test de régression est illustrée dans la Figure 35. 78

Chapitre III : CONCEPTION Agent superviseur Agent de régression 1,2,3,4,5,6... 6,7 Agent de 1,2,3,4,5,6 régression Testeur 1 : Allocation de tâche 2 : Code à re-tester 3 : Cas de tests 4 : Appel d offre 5 : Offre 6 : Rapport de tests 7 : Evaluation des tests Figure 35 : Représentation graphique de l architecture de communication du processus tests de régression Le diagramme d activité du processus de tests de régression est illustré dans la Figure 36. 79

Chapitre III : CONCEPTION Testeur Agent superviseur Agent de régression Allocation des ressources Appel d offre Traitement de l appel d offre Sélection des offres Allocation de taches Vérification du critère d adéquation Exécution des tests Génération de rapport Envoi des résultats Evaluation des résultats Mise à jour Historique Tests Figure 36 : Diagramme d activité du processus de tests de régression 80

Chapitre III : CONCEPTION Scénario de non adéquation des cas de tests Les modifications apportées à la nouvelle version du code logiciel peuvent modifier, à leur tour, le critère d adéquation des données de test. Si c est le cas, les cas de tests générés pour tester la version précédente du code ne sont plus adéquats pour le test de la nouvelle version. Donc, l agent de régression doit informer l agent superviseur pour refaire les tests de nouveau (test unitaire ou test d intégration). Le diagramme de séquence suivant détaille les interactions entre les différents agents. Agent superviseur Agent de régression Critere(inadéquat) Figure 37 : Diagramme de séquence du scénario «non adéquation des cas de tests» Primitives d interactions : Primitive Désignation Critere(inadéquat) L agent de régression informe l agent superviseur que le critère d adéquation des données de test n est plus adéquat. 81

Chapitre III : CONCEPTION III.3.2.6 Modélisation du processus de mesure de la progression des tests Description du processus : Le testeur (humain) peut demander, à n importe quel moment durant le processus de test, l état de la progression des tests à l agent superviseur. Ce dernier sollicite, à ce moment là, les agents du groupe sélectionnés pour effectuer les taches pour lui envoyer des informations sur la progression des tests en cours. L agent superviseur doit attendre que chaque agent du groupe lui réponde, pour élaborer un état global sur la progression des tests qu il transmettra au testeur. La représentation graphique du processus de mesure de la progression des tests est illustrée dans la Figure 38. Agent superviseur Agents du groupe 1,2 1,3 Testeur 1 : Demande d état de progression des tests 2 : Informations sur la progression des tests 3 : Etat global de la progression des tests Figure 38 : Représentation graphique de l architecture de communication du processus de mesure de la progression des tests Le diagramme d activité du processus de mesure de la progression des tests est illustré dans la Figure 39. 82

Chapitre III : CONCEPTION Testeur (humain) Agent superviseur Agent du groupe Réception demande d état de progression Mesure de la progression Génération de rapport Génération de l état de progression global Mise à jour Historique des tests Figure 39: Diagramme d activité du processus de mesure de la progression des tests Le diagramme de séquence suivant détaille les interactions entre les différents agents. Testeur Agent superviseur Agent du groupe Demande-Etat-Progress1 Demande-Etat-Progress2 Envoi-Rapport Envoi-Etat-Progress Figure 40 : Diagramme de séquence du processus «mesure de la progression des tests» 83

Chapitre III : CONCEPTION Primitives d interactions : Primitive Désignation Demande-Etat- L agent superviseur reçoit une demande du testeur pour lui fournir un état Progress1 sur la progression des tests. Demande-Etat- L agent superviseur demande aux agents du groupe, auxquels ont été Progress2 allouées les taches de tests, de lui fournir des informations sur leur progression. Envoi-Rapport Un agent du groupe envoie à l agent superviseur son rapport de progression. Envoi-Etat- L agent superviseur envoie un état global sur la progression des tests. Progress III.4 CONCLUSION Dans ce chapitre, nous avons présenté l architecture du système multi-agents qui modélise le processus de test logiciel. L architecture proposée couvre les trois niveaux de tests suivants : les tests unitaires, les tests d intégration et les tests système. De plus, notre système offre la possibilité d utiliser les techniques de tests statiques et dynamiques. Les agents de notre système interagissent entre eux pour résoudre les problèmes qui se posent de façon intelligente. Ces agents possèdent une architecture hybride pour pouvoir mener à bien leurs buts. Notre approche de modélisation du processus de tests logiciels est bâtie à partir d une vue globale de tout le processus de test. Le système multi-agents conçu représente une nouvelle approche dans la mesure où il prend en charge toutes les activités du processus de test. 84

Conclusion générale CONCLUSION GÉNÉRALE Dans le processus de test logiciel, un certain nombre de problèmes complexes se posent. Ces problèmes requièrent des solutions adaptées où le temps et l efficacité jouent un rôle important. L automatisation partielle ou globale du processus de test est donc primordiale voir déterminante. La première étape de notre travail de recherche a été de dresser un état de l art sur le processus de tests logiciels, pour arriver à dégager les différents problèmes liés au processus lui même. Parmi ces problèmes citons par exemple : l explosion combinatoire lors de la sélection des meilleurs cas de tests, la parallélisation des tests unitaires, l automatisation des tests statiques, et la mesure de la progression des tests. Vu l intérêt du concept agent pour la résolution de problèmes, l utilisation d un système multi-agents pour modéliser le processus de test capable de résoudre les différents problèmes représente une solution assez intéressante. Certains chercheurs ont proposé des systèmes multi-agents permettant de résoudre certains problèmes, mais il n existe pas de système conçu pour avoir une maîtrise globale des différents problèmes liés au processus de test en général. En effet, le système de «Choi & Choi» permet de résoudre beaucoup de problèmes liés aux tests dynamiques mais ne prend pas en charge les tests statiques, et le système de «Dhavachelvan et al.» ne traite aussi que les tests dynamiques mais en se limitant aux tests unitaires uniquement. Aussi, notre travail a consisté à proposer une approche de modélisation du processus de test logiciel dans sa globalité par un système multi-agents. 85

Conclusion générale Le système proposé est constitué d agents capables d agir et d interagir entre eux pour conduire les tests statiques, les tests dynamiques, les tests unitaires, les tests d intégration, les tests système, les tests de régression, et pour mesurer la progression des tests. Les agents de notre système sont organisés de façon à ce qu un agent superviseur contrôle et coordonne toutes les tâches des autres agents du groupe. Ils possèdent une architecture hybride pour atteindre leurs buts. Comme perspectives à notre travail, nous proposons : - d étendre notre système aux autres étapes de développement du génie logiciel telles que l étape de conception et l étape de codage pour améliorer l étape de tests, - de procéder à la validation de notre approche par une expérimentation sur un cas réel de développement de logiciel, - de procéder à une validation formelle de l approche de test afin de garantir le respect des propriétés spécifiques à tout type de logiciels. 86

BIBLIOGRAPHIE [AND03] [ATE] [AVO92] [BAU05] [BEI90] [BER91] [BON88] [BON90] Thèse de Doctorat intitulée : «Proposition d un modèle d agents hybrides basé sur la motivation naturelle» Présentée par Fenintsoa ANDRIAMASINORO pour obtenir le Grade de Docteur de l Université de La Réunion. Spécialité : Informatique. Soutenue publiquement le 28 Août 2003. Institut de Recherche en Mathématiques et Informatique Appliquées Université de La Réunion. «Atelier B», http://www.atelierb.societe.com/ N.M. Avouris et L. Gasser. Distributed Artificial Intelligence: Theory and Praxis, Eurocourses - Computer and Information Science, Kluwer, pages 81-107, 1992. B. Bauer, J. Odell. UML 2.0 and Agents: How to build Agent-based Systems with the new UML Standard. Journal of Engineering Applications of Artificial Intelligence, vol.18, Issue: 2, pages 141-157, Mars 2005. B. Beizer. Software Testing Techniques, Ed. Van Nostrand Reinhold; 2 nd edition. Juin 1990. A. Bertolino. An overview of automated software testing, Journal of Systems and Software, 1991, 15, pp. 133 138. Bond, A et Gasser, L. Readings in distributed artificial intelligence. Morgan Kaufman, San Mateo, CA (1988). A. Bond. Distributed Decision Making in Organisation. IEEE Transactions on Systems, Man and Cybernitics Conference, Novembre 1990. [BON94] E. Bonabeau, G. Theraulaz. Intelligence Collective. Ed. Hermès, 1994. [BRI01] [BRI89] [BRO89] [BUR02] [CHA01] J.-P. Briot et Y. Demazeau. "Principes et architecture des systèmes multi-agents", Traité IC2, Informatique et systèmes d'information, Ed. Hermès, 2001. J.P. Briot, "Actalk : une plate-forme de modélisation des langages acteurs en Smalltalk-80". Actes 7e congrès reconnaissances des formes et intelligence artificielle, Paris, p.147-162 (1989). R. A. Brooks. A Robot that Walks: Emergent Behaviors From a Carefully Evolved Network. In Proceedings of the IEEE International Conference on Robotics and Automation, pages 692-694, 1989. I. Burnstein. Practical software testing: A Process-oriented approach, Ed. Springer, 2002. B.Chaib-draa, I.Jarras et B.Moulin. «Systèmes multiagents: Principes généraux et applications». Article dans: J.P.Briot et Y.Demazeau. «Principes et architecture des systèmes multi-agents».traité IC2, Informatique et systèmes d'information, Ed. Hermès, 2001. 87

[CHE96] [CHO02] [CHO03] [CHU97] [COL96] [CRO95] [CUR86] [DAI94] [DAU97] [DEL99] [DEM78] T. Chen, Y.Yu. On the expected number of failures detected by subdomain testing and random testing, IEEE Trans. Software Engineering, 22(2), pp.109-119. 1996. J. Choi, B. Choi. Test Agent System. International Journal of Software Engineering and Knowledge Engineering, Volume: 12, Issue: 3, p. 269-290. 2002. S. Chouali, Contribution du raffinement à la vérification de systèmes sous hypothèses d'équité. Thèse de doctorat, LIFC, Université de Franche-Comté, 2003. Huey-Der Chu, An evaluation scheme of software testing techniques, IFIP TC5 WG5.4 3 rd international conference on reliability, quality and safety of softwareintensive systems. Athens, Greece. Pages: 259-262, 1997. Ed. Chapman&Hall, Ltd, London, UK. A. Collinot, A. Drogoul, and P. Benhamou. Agent-oriented Design of a Soccer Robot Team. In Proceedings of the Second International Conference on Multi- Agent systems (ICMAS-96), pages 41-47, Kyoto, Japan, 1996. J. Crow, S. Owre, J Rushby, N. Shankar, M. Srivas. A Tutorial Introduction to PVS, Workshop on Industrial-Strength Formal Specification Techniques, 1995. P. Currit, M. Dyer, H. Mills. Certifying the reliability of software, IEEE Trans. Software Engineering, 12(1), pp. 3 11, 1986. G.T. Daich, G. Price, B. Ragland, M. Dawood, Software Test Technologies Report, August 1994. C. Daum-Lobko, "Systèmes multi-agents réactifs et résolution de problèmes". DEA de Robotique à l'université de Pierre et Marie Curie (Paris VI), juin 1997. http://daumlobko.free.fr/dea/index.html S.A. Deloach. "Multiagent Systems Engineering: A Methodology And Language for Designing Agent Systems". 1999. R. Demillo, R. Lipton, F. Sayard. Hints on test data selection: help for the practicing programmer, IEEE Computer, 9(4), pp. 34 41, 1978. [DEM87] R. Demillo, W. McCracken, R. Martin, J. Passafiume. Software testing and evaluation. (The Benjamin/ Cummings, 1987) [DEM90] Y. Demazeau et J.-P. Muller. Decentralized Artificial Intelligence. Elsevier Science Publishers B.V. (North Holland) 1990. [DEM91] [DEN04] [DHA05] Y. Demazeau, J-P. Muller. "From reactive to Intentional Agents". Decentralized Artificial Intelligence Editors. Vol 2.North Holland. 1991. A. Denise, M.-C. Gaudel, S.-D. Gouraud. A Generic Method for Statistical Testing, In Fifteenth IEEE International Symposium on Software Reliability Engineering (ISSRE), pages 25-34, novembre 2004, Saint Malo. P. Dhavachelvan, G.V. Uma. Fuzzy complexity assessment model for resource negotiation and allocation in agent-based software testing framework. Expert Systems with Applications xx (2005) 1 15. 2005 Elsevier Ltd. All rights reserved. Doi: 10.1016/j.eswa.2005.01.008, 2005. 88

[DHA06] [DIE90] [DOD88] [DUR84] [ELA99] P. Dhavachelvan, G.V. Uma, V.S.K. Venkatachalapathy. A new approach in development of distributed framework for automated software testing using agents. Knowledge-Based Systems xxx (2006) xxx xxx. 2006 Elsevier Ltd. All rights reserved. Doi: 10.1016/j.knosys.2005.12.002 R. Dieng. Relations Linking Cooperating Agents. In Proceedings of the 2nd European Workshop MAAMAW'90, p. 185-202, Saint-Quentin en Yvelines France, August 1990. Department of Defense, "Military Standard Defense System Software Development," February 1988. J. Duran, S. Ntafos. An evaluation of random testing. IEEE Trans. Software Engineering, 10(4), pp. 438 444, 1984. M. Elammari and W. Lalonde. An Agent-Oriented Methodology High-Level and Intermediate Models. Proceedings of AOIS-1999. [ENG88] R.S. Engelmore & A. Morgan. "Blackboard systems". Addison Wesley, 1988. [ERC91] J. Erceau et J. Ferber. "L'intelligence artificielle distribuée". La Recherche, vol. 22: pages 750-758, juin 1991. [FAG76] [FAG86] [FER88] [FER89] [FER95] [FRA93] M. Fagan. Design and Code inspections to reduce errors in program development, IBM Systems Journal, Vol. 15, No 3, Page 258-287, 1976. M. Fagan. Advances in inspections, IEEE Trans. Software Engineering, 12(7), pp. 744 751, 1986. J. Ferber, M. Ghallab. "Problématiques des univers mutli-agents intelligents". Actes des Journées Nationales PRC-GRECO Intelligence Artificielle, p. 295-320, Toulouse, mars 1988. J. Ferber Objets et agents : une étude des structures de représentation et de communication en Intelligence Artificielle. Thèse de l Université de Paris VI, juin 1989. J. Ferber. "Les systèmes multi-agents, vers une intelligence collective". InterEditions, 1995. P. Frankl, E. Weyuker. A formal analysis of the fault detecting ability of testing methods, IEEE Trans. Software Engineering, 19(3), pp. 202-213. 1993. [GAU96] M.C. Gaudel, B. Marre, F. Schlienger, G. Bernot. «Précis de Génie Logiciel» Edition Masson, 1996. [GIL93] T. Gilb, D. Graham. Software inspection. Addison Wesley, 1993. [GLA96] N. Glaser. "Contribution to Knowledge Modelling in a Multi-Agent framework (the CoMoMAS Approach)". PhD thesis, Université Henri Poincaré, Nancy I, France, November, 1996. [GOU04] S.D. Gouraud «Utilisation des Structures Combinatoires pour le Test Statistique», thèse de doctorat, Université de Paris-Sud-Orsay, Mention Informatique, juin 2004. 89

[HAN02] [HAT91] [HAY85] [HOA69] Vu Le Hanh : «Test et modèle UML : stratégies de planification des tests». Thèse Présentée devant L université de rennes pour obtenir le grade de docteur, Mention Informatique. Année 2002. J.P. Haton. "Le raisonnement en intelligence artificielle". Inter-editions 1991. Paris. B. Hayes-Roth. A blackboard architecture for control. Artificial Intelligence, 26(3): pages 251-321, July 1985. C. A. R. Hoare. An axiomatic basis for computer programming. Communications of the ACM, 12: 576-580, 1969. [HUE99] G. Huet, G. Kahn, C. Paulin-Mohring. «The Coq Proof Assistant A Tutorial» 1999, Coq project. [HUH87] M. N. Huhns. "Distributed Artificial Intelligence". Pitman Publishing-Morgan Kaufmann, 1987. [IEE90] [IGL98] [JAC03] [JEN00] [JEN98] [KEN96] [KHO 94] [KIN96] [LAB93] IEEE-Standard Glossary of Software Engineering Terminology IEEE-STD610.12-1990 (1990). C.A. Iglesias, M. Garjo, J.C. Gonzàlez. A Survey of Agent-Oriented Methodologies. In Proceedings of the 5th International Workshop on Intelligent Agents V : Agent Theories, Architectures, and Languages (ATAL-98). 1998. I. Jacobson, G. Booch, J. Rumbaugh. Le Processus unifié de développement logiciel. Ed. Eyrolles, 2003. Jennings, N., and Wooldridge, M. (2000) "Agent-Oriented Software Engineering". In Handbook of Agent Technology (ed. J. Bradshaw) AAAI/MIT Press. N. R. Jennings, M. Wooldridge, et K. Sycara. A roadmap of agent research and development. In Journal of Autonomous Agents and Multi-Agent Systems, 1(1): pages 7-38, 1998. E.A. Kendall, M.T. Malgaret, T. Malkoun, et C. Jiang. A Methodology for Developing Agent-based Systems for Enterprise Integration. In D.Luckose and Zhang C., editors, Proceedings of the First Australian Workshop on DAI, Lecture Notes on Artificial Intelligence. Springer-Verlag, 1996. K.Khoualdi. "Filtrage d alarmes pour un système automatisé par une approche multiagents". Thèse de l Université Paris VI. LAFORIA TH94/07, 18 Novembre 1994. D. Kinny, M. Georgeff, and A. Rao. A Methodology and Modeling Technique for Systems of BDI Agents. In W. van der Velde and J. Perram, editors, Agents Breaking Away. Proceedings of the Seventh European Workshop on Modelling Autonmous Agents in a Multi-Agent World MAAMAW 96, (LNAI Volume1038). Springer-Verlag, 1996. S. Labidi et W. Lejouad. "De l Intelligence Artificielle Distribuée aux Sysèmes Multi-Agents". INRIA Sophia Antipolis. Rapport de recherche N 2004, Aout 1993. 90

[LAU89] [LIN01] [MAN02] L. Lauterbach, W. Randall. Experimental evaluation of six test techniques. Proc. COMPASS 89, pp. 36 41, 1989. J. Lind. "Iterative Software Engineering for Multiagent Systems" Volume 1994 of Lecture Notes in Artificial Intelligence, Springer Verlag, Heidelberg, 2001. R. Mandiau, E. Grislin-le strugeon : "Systèmes multiagents". Laboratoire d'automatique et de Mécanique Industrielles et Humaines (LAMIH) UMR CNRS 8530 Université de Valenciennes et du Hainaut-Cambrésis. Techniques de l Ingénieur, Dossier n : S7216, Date de parution : 03/2002. Bases documentaires : Informatique Industrielle, Vol papier n : S1. [MAN99] R. Mandiau, E. Le Strugeon et G. Agimont. Study of the influence of organizational structure on the efficiency of a multi-agent system. Networking and Information Systems Journal, vol. 2, no 2, p. 153-179 (1999). [MAS90] G. Masini. "Les langages à objets: langages de classe, langages de frame, langages d acteurs". Inter-edition 1990. [MAV00] V.K. Mavromichalis, G. Vouros ICAGENT: Balancing between Reactivity and Deliberation. In Workshop on Balancing Reactivity and Social Deliberation in Multi-Agent Systems at the 14th European Conference on Artificial Intelligence (ECAI), Berlin, Germany, Lecture Notes in AI, volume 2103, Springer, pp. 53-75. 2000. [MEL04] Hakima Mellah «Modélisation et organisation des activités coopératives de télémaintenance», thèse de Magister, Institut National de formation en Informatique (INI), 2004. [MIL87] [MIN88] [MOU96] [MYE04] H. Mills, M. Dyer, R. Linger. Cleanroom software engineering, IEEE Software, pp. 19 25, avril 1987. M. Minsky. The Society of Mind. Basic Books, 1986. (la société de l'esprit, Inter Editions, 1988, en français). B. Moulin and M. Brassard. A Scenario-based Design Method and an Environment for the Development of Multiagent Systems. In D. Lukose and C. Zhang, editors, First Australian workshop on Distributed Artificial Intelligence, (LNAI volume 1087), pages 216-231. Springer-Verlag, 1996. G.J. Myers, T. Badgett, T.M. Thomas. The art of software testing seconde edition, Ed.Wiley, 2004. [NEW82] A. Newell. The Knowledge Level. Artificial Intelligence, 18, pages 87-127, 1982. [NIS02] [POS96] [REI90] NIST Report : The Economic Impact of Inadequate Infrastructure for Software Testing, 2002. National Institute of Standards and Technology. R. Poston. Automating specification-based software testing. IEEE Computer Society, 1996. Reichgelt, H. "Different styles of agent architectures". Proceedings of the 1st belief representation and agent architectures workshop, Cambridge, Galliers J.R. (Ed.), p. 29-39 (mai 1990). 91

[RUS95] [SAB01] [SAB02] [SEA83] [SEA90] S. Russel & P. Norvig. "Artificial Intelligence: a Modern Approach" Prentice-Hall. A. Sabas, S. Delisle et M. Badri. "Vers une unification des méthodologies de développement des systèmes multiagents", Actes des Journées francophones pour l'intelligence artificielle distribuée et les systèmes multi-agents, Montréal (Québec, Canada), 12-14 novembre 2001, 327-330. A. Sabas, M. Badri et S. Delisle, "Applying a New Multidimentional Framework to the Evaluation of Multiagent System Methodologies", International Symposium on Information Systems and Engineering (ISE 2002), San Diego (California, USA), 14-18 juillet 2002, Simulation Series, vol. 34, n 2, p 37-44. J. R. Searle. Intentionality: An Essay in the philosophy of mind. Cambridge University Press, New York, 1983. J. R. Searle. Intentions in Communication, chapter 19 : Collective Intentions and Actions, pages 401{415. MIT press, London, 1990 [SOM92] I. Sommerville. Le génie logiciel, Ed. Addison-Wesley, 1992. [SWE04] [THE91] [WEI99] [WHI00] [WHI94] [WOO00] SWEBOK : Guide to the Software Engineering Body of Knowledge (version 2004) IEEE 2004 Version SWEBOK is an official service mark of the IEEE. http://www.swebok.org P. Thévenod-fosse, H. Waeselynck. An investigation of statistical software testing. Journal of Software Testing, Verification and Reliability, 1(2), pp. 5-25, 1991. G. Weiss. Multiagent Systems: A Modern Approach to Distributed Modern Approach to Artificial Intelligence. The MIT Press, Cambridge, Massachusetts, London, England 1999 Massachusetts Institute of Technology. J. Whittaker. "What is Software Testing, and Why is It So Hard". IEEE Software. 17(1), p70-79, 2000. J. Whittaker, M. Thomason. A markov chain model for statistical software testing, IEEE Trans. Software Engineering, 20(10), pp. 812 824, 1994. M. Wooldridge, N. R. Jennings, et D. Kinny. The Gaia "Methodology For Agent- Oriented Analysis and Design", Journal of Autonomous Agents and Multi-Agent Systems 3(3), pages 285-312, 2000. 92