Mode d'emploi
Contents
1. Fig 1 Les deux grands types de test retenus D veloppement de composants testables Le mod le de composant retenu dans le projet est bas sur celui de la m thode KobrA Atki01 lui m me bas sur la d finition de Szyperski Szyp99 A software component is a unit of composition with contractually specified interfaces and context dependencies only A software component can be deployed independently and is subject to composition by third parties Un composant logiciel est donc vu comme une unit de composition poss dant des interfaces contractuelles et un contexte particulier d ex cution Il peut tre d ploy ind pendamment et compos avec d autres composants L approche prise dans Component vise int grer les mod les et techniques propos s comme une extension de l approche classique CBSE Un composant est d fini par un ensemble d interfaces qui permettent d en appr cier les fonctionnalit s Parmi ces interfaces on diff rencie les interfaces fournies provided par lesquelles le client du composant acc de aux services qu il propose et les interfaces requises required qui d finissent les services dont le composant a lui m me besoin pour fonctionner correctement Composants testables Pour mettre en ceuvre la testabilit des composants la notion de composant testable est introduite Un composant testable BIT component comprend les interfaces fonctionnelles du composant plus une ou pl2. crit dans la troisi me section Nous concluons enfin ce chapitre en faisant le point des techniques disponibles et des enjeux restant traiter dans ce domaine Pour faciliter la lecture les termes importants ou en anglais sont mis en italique et les l ments du mod le BIT sont indiqu s dans la police Tahoma 1 Test de composants L activit de test est une activit complexe impliquant entre autres la conception des jeux de test leur ex cution leur interpr tation etc Ce chapitre n a pas pour objectif de traiter de tous ces aspects Nous souhaitons montrer l importance d automatiser le plus possible cette activit et de fournir l ensemble des moyens et supports cette activit cruciale dans le d veloppement d application bas es sur les assemblages de composants Validation et test Ce chapitre tant consacr aux tests de composant il nous faut rappeler la place du test de composant par rapport l activit plus g n rale de validation En effet dans le d veloppement d application classique on oppose parfois validation a priori o par exemple le code est contraint par les outils de d veloppement g n ration automatique outils formels model checking et validation a posteriori o l impl mentation est mise l preuve par rapport la sp cification du syst me d sir preuve formelle si la sp cification l est test du syst me en situation Dans le cas particulier du C
3. de la plate forme Java Swing est une architecture portable qui peut s ex cuter sur n importe quel syst me poss dant une machine virtuelle Java JVM Ainsi les d veloppeurs utilisant notre logiciel ne sont pas contraints un syst me particulier Un autre L exemple choisi est la Stack de Java revue via un composant appel BIT_stack 11 avantage de ce choix r side dans le m canisme de r flexion de Java Le m canisme de r flexion offre aux programmes Java une facult d introspection qui permet d analyser dynamiquement le code compil de composants Java classe pr d finie de la librairie Java Class Dans le g n rateur de code nous avons donc utilis la r flexion Java pour analyser le composant traiter et cr er sur mesure le composant BIT correspondant ainsi que son testeur JMX Un exemple pas pas B A 4 B COMPOSANT D SERVEUR COMPOSANT JMX PARTIE BIT Figure 6 Cr ation d un composant BIT et de son testeur La Figure 6 illustre le processus de g n ration du composant testable et du testeur graphique distribu associ que nous avons pr sent dans la section pr c dente Le processus de mise en uvre de la technologie BIT se d roule globalement en quatre tapes Nous illustrons ces tapes par la construction d une version BIT du composant Stack de Java Le composant Stack est
4. n ral son utilisation et donc son test assez tard dans le cycle de d veloppement Ce composant peut m me tre acquis par l application au moment de l ex cution e g plates formes logicielles de type CORBA cf chapitre 11 Dans ce type de d veloppement les phases d assemblage et de validation sont primordiales La distinction entre le d veloppement de composants et le d veloppement d applications utilisant des composants a un impact au niveau des besoins de tests MeNi98 HaLS99 En effet le d veloppeur de composants r alise les tests propres au d veloppement du composant c est a dire le test unitaire du composant et son test au sein de son environnement de d veloppement Le client en revanche ne teste g n ralement pas le composant lui m me D une part il est suppos valid par le fournisseur et d autre part le code source est g n ralement indisponible rendant les techniques de test traditionnelles caduques Il est en revanche indispensable de tester son int gration dans l architecture d velopp e communication avec les autres composants ad quation des interfaces etc En effet contrairement au monde de l lectronique par exemple la seule condition pour qu un composant valid on parle plut t de certification pour les composants logiciels cesse soudainement de bien se comporter vient d une modification de son environnement L exp rience montre que quelque soit le niveau de certificatio
5. BSE m me les composants les plus s rs n cessitent d tre test s dans leur environnement d ex cution car seul cet environnement final g n ralement indisponible aux concepteurs des composants poss de les caract ristiques susceptibles de g n rer des erreurs au niveau des composants eux m mes comme de leur assemblage De plus cette activit de test doit tre disponible tout moment vu le caract re dynamique et changeant des environnements actuels e g distribution caract re temps r el Dans ce chapitre nous ne pr sentons que les aspects test de l approche d velopp e dans notre quipe Nous travaillons activement en parall le sur les aspects g n rations de code s r et formalisation des assemblages de composants BaBB03 Ces aspects sont en effet indispensables un v ritable environnement de d veloppement CBSE Citons par exemple une des conclusions du rapport Logiciels et syst mes haute confiance du bureau am ricain de coordination sur la recherche et le d veloppement en technologie de l information HCSSO1 For example automated validation technology is needed that can consider correct by construction techniques As one example methods might be explored that are analogous to proof carrying code for certifying software Tests unitaires d int gration d interop rabilit de conformit Le test des logiciels a beaucoup volu ces derni res ann es cause du c
6. E gt Location zchnology name BIT_stack_tester action current_state action current_state w T void int_search_Object Description of boolvan empty void nootean empty current_state Successful Description of Object perk void Object peer Description of Object pop The operation current_state was successfully invoked for the MBean BIT J technology name BIT_stack_tester x7 a I SR ar men WW A CE ON OA es Ye MN AH oh Cm ooo li EU Vers of BL teeren nas The operation returned with the value BIT stack Not empty Back to MBean View Back to Agent View Mp 7172 20 20 178 8082 ViewObjeciResBIT J lechnology name BIT_stack tester MBean Name BIT J technology nameeBIT_stack tester MBean Java Gass _OIT_examples _ NT_stack BIT_stack_tester MBean description informadon on the managemert interface of me MBean List of MBean attributes y sont connect s Notre impl mentation utilise le protocole HTTP et repr sente les donn es au format HTML ce qui permet de tester le composant partir d un simple navigateur Web cf Figure 5 MBean View of BIT J technology name BIT_stack_tester Konqueror Location Edit View Go Bookmarks Tools Settings Window Help 449 GO XRBG GRAAF E gt Location A 2 20 20 175 8082 ViewObjectRes BIT J technology name BIT_stack_tester x a java lang String expected_state Description o
7. Partie 8 Test de composants logiciels Jean Michel Bruel Franck Barbier Nicolas Belloir et Fabien Rom o 1 Introduction 2 Test de composants a Validation et test b Tests unitaires d int gration d interop rabilit de conformit c Test des assemblages de composants 3 Built In Test une technique d int gration de test 4 Une technologie disponible sous Java la librairie BIT J 5 Conclusion et challenges 6 Bibliographie R sum Nous traitons dans ce chapitre du test de composant en situation Contrairement au monde de l lectronique par exemple la seule condition pour qu un composant valid cesse soudainement de bien se comporter vient d une modification de son environnement Nous traitons donc du test d int gration et d taillons une approche concr te visant doter un composant d un certain nombre de fonctionnalit s internes dont la personnalisation et l usage aident au moment du d ploiement valuer le composant voire le re configurer dynamiquement Nous discutons en particulier de test int gr et illustrons cette id e via la mise en uvre d une librairie Java pour les composants sur tag re notamment COTS components Introduction Le d veloppement d applications bas es composants CBSE Component Based Software Engineering implique une modification importante du cycle de d veloppement du logiciel cf chapitre 4 Int grer un composant dans une application entra ne en g
8. act ristique principale d un composant COTS est l impossibilit pour son utilisateur de le modifier d une quelconque mani re Ceci exclut par exemple l ensemble des activit s classiques de test bas es sur l exploration du code et pose le probl me de la v rification du comportement du composant par rapport aux sp cifications du client Nous croyons que l avenir des composants COTS tient dans leur capacit tre configur et test en situation par leur client C est pourquoi nous avons concentr nos efforts sur l application de l approche BIT ce type de composants L id al serait que chaque composant COTS livr par un vendeur dispose d une palette de fonctionnalit s de test Ce type de composants COTS pourrait alors tre consid r de la m me mani re que les composants testables en g n ral et s int grerait parfaitement dans l approche BIT Malheureusement il n en est rien ou du moins pas encore Un composant COTS qui ne dispose que d interfaces fonctionnelles est un pi tre l ment observable et encore moins contr lable en comparaison d un composant BIT Nous nous sommes donc attach s montrer qu il tait possible dans une certaine mesure de fournir ces fonctionnalit s de test un composant COTS qui en serait d nu Faire un composant BIT d un composant COTS implique naturellement que ce composant puisse tre un minimum manipul gr ce par exemple des capacit s d in
9. aract re de communication et de distribution de plus en plus g n ralis des applications Par exemple l automatisation de la g n ration de tests partir d une description formelle d un syst me a atteint une certaine maturit JEDLO1 Cependant l avancement de ces techniques concerne le plus souvent les m thodes de test classiques Quand ces m thodes sont appliqu es aux tests de composants imbriqu s dans un syst me complexe elles se r v lent alors inadapt es ainsi que les architectures propos es pour effectuer les tests En effet contrairement aux approches de test traditionnelles les m thodes de test de composants sont bas es sur le fait que la plupart du temps le composant doit tre trait comme une bo te noire accessible seulement partir d un nombre limit de services dont le fonctionnement comportement n est pas toujours clairement formellement d fini De plus le test de composants doit viter de tester des parties du syst me consid r es comme libres d erreurs en se concentrant sur les interactions entre composants et les ventuelles nouvelles erreurs qu elles g n rent De nouvelles approches de nouvelles strat gies voire de nouvelles architectures de test qui tiennent compte de ces sp cificit s sont donc n cessaires Ce sont notamment ces raisons qui ont conduit des projets europ ens comme Component Comp01 d di cette probl matique et dont les r sultats seront pr sen
10. cture sp cifie un certain nombre d interfaces particuli res et bien d finies que doivent fournir les impl mentations des l ments architecturaux BIT components testers handlers et system constructors L approche BIT n impose aucune architecture de composant particuli re cf chapitre 9 C est pourquoi seules les interfaces et les types de donn es ainsi que certaines constantes sont d finies de mani re pr cise La documentation r sultante du projet Component fournit tous les d tails sur ces l ments Le lecteur est renvoy ces documents notamment le Vade Mecum v ritable mode d emploi didactique VM03 pour plus de d tails Application sp cifique aux composants COTS Nous examinons dans cette partie le cas particulier des composants COTS D une part il s agit de la partie du projet dont notre quipe a eu la responsabilit et de plus c est lorsque ces composants sont utilis s dans une approche CBSE que le besoin de fonctionnalit s de test est le plus critique Mais commen ons tout d abord par rappeler la d finition d un composant COTS MeOb01 Ja COTS component is A product that is Sold leased or licensed to the general public Offered by a vendor trying to profit it Supported and evolved by the vendor which retains the intellectual property rights Available in multiple identical copies Used without internal modification by a consumer Retenons que la car
11. distribu dans le SDK de Java sous sa forme compil e sans son code source Nous consid rons donc le composant Stack comme un composant sur tag re 12 BIT code generator v 0 2 File Help A Component name gt gt HN b Generate test code for Relationship between Component and BIT componenit j inherited methods private methog inheritance embedding fK standard state based ER G Figure 7 Interface graphique du g n rateur La premi re tape consiste lancer le g n rateur et le configurer en lui sp cifiant le composant traiter Figure 7 A et les options de g n ration Figure 7 D E F Trois options peuvent tre s lectionn es La premi re D concerne le choix du mod le BIT standard ou bas tat Le mod le BIT standard est l approche la plus simple interface de test minimale Le mod le BIT bas tat est le mod le impl mentant l interface permettant de d crire le comportement du composant l int rieur du composant BIT et de le tester La seconde option E concerne le type de relation entre le composant et sa version BIT Deux types de relation sont possibles le composant BIT peut h riter du composant ou l encapsuler comme un attribut classique La troisi me option F concerne la possibilit de prendre en compte ou non les op rations h rit es du composant initial afin de les tester cas o une op ration fournie par l interface
12. es de composants De nombreux travaux ont pour objet de trouver des outils capables de tester v rifier et certifier les composants logiciels Citons titre d exemple le programme RNTL Cote impliquant l INRIA le LSR Imag Softeam France T l com R amp D et Gemplus Le but tait de fournir aux d veloppeurs de composants des techniques de test automatique de composants applicables aux technologies couramment employ es dans le domaine Nous nous int ressons plus particuli rement dans ce chapitre aux d veloppeurs d applications bas es composants plus qu aux d veloppeurs de composants Nous ne traitons donc pas par exemple de la g n ration de test ou des probl mes de couverture des jeux de tests L objectif de la technique pr sent e dans la section suivante est de fournir aux assembleurs l ensemble des outils permettant de mettre en uvre leur activit de test Pour une tude compl mentaire des diff rentes approches de test de composants existantes nous renvoyons le lecteur Bhor01 mais pour conclure cette section sur le test de composants nous mentionnerons les trois questions principales que doivent se poser les concepteurs de composants testables propos es par Gao Gao00 The first question is how to design and define the common architecture and test interfaces for testable components The next question is how to generate testable components in a systematic way The final question is how to control and min
13. es propri t s du composant lui m me Component Dans la Figure 3 une d pendance UML est utilis e dans le but de laisser le choix d un m canisme de programmation ad quat par exemple l h ritage est souvent utilis L interface IBITQuery regroupe l ensemble des op rations qui sont syst matiquement utilis es dans un cas de test BIT BIT test case lui m me syst matiquement utilis par un testeur BIT BIT tester Cette interface est fondamentale et minimale car c est travers elle qu un composant COTS se transforme en composant testable Nous avons introduit dans notre librairie une version tendue de cette interface State based IBITQuery qui en r utilisant une librairie existante impl mentant les Statecharts Harel permet l expression du comportement du composant A partir d une repr sentation du comportement du composant sous forme d un automate tats un statechart de pr f rence pour b n ficier pleinement des capacit s de la librairie il est en effet possible de tester et de configurer le composant selon les besoins Bien que de telles sp cifications soient communes dans les syst mes en temps r el par exemple on ne peut pas toujours en fournir Ainsi un travail de r ing nierie est parfois n cessaire pour extraire des sp cifications comportementales partir d un composant existant BIT test case est une classe Java qui a fig des protocoles de test dont le r le est de initiali
14. est h rit e Dans notre exemple du composant Stack nous avons s lectionn le mod le BIT bas tat l option d encapsulation du composant et nous n acc dons pas aux op rations h rit es par le composant Figure 8 BIT code generator v 0 2 iix File Help Component name ljava util Stack Directory for generation Generate test code for Relationship between Component and BIT component BIT model C inherited methods private methods inheritance embedding standard state based Clear Figure 8 Configuration du g n rateur pour le composant Stack 13 La seconde tape consiste en la g n ration elle m me Une fois le composant cible et le r pertoire de destination des fichiers g n r s Figure 7 B d finis le bouton Generate Figure 7 G devient activable Le r sultat du processus de g n ration et les fichiers g n r s apparaissent dans la zone de texte Figure 7 C En appuyant sur ce bouton la g n ration est ex cut e et quatre fichiers sont cr s BIT_stack java le composant BIT BIT_stack_tester java le testeur JMX BIT_stack_ tester MX_agent java l agent JMX n cessaire pour utiliser le testeur BIT_stack tester MBean java l interface JMX sp cifiant les op rations qui peuvent tre test es Lors de la troisi me tape le d veloppeur modifie et compl te les fichiers g n r s Figure 7 C Dans le cas d un mod le BIT bas ta
15. f java lang 3fting 9 xX MS SAAS Description of result java lang String result JOMKS 1901 Description of expected_result Reload Period in seconds P 0 Retoad Unregister java lang String expected_result Nannainsinn nf imnmun ntinn Java Dynamic Management View of current_state invocation Konqueror Figure 5 Ex cution d une op ration de test via un navigateur Web Un g n rateur automatique de code Afin de faciliter l utilisation de la librairie nous avons r alis un g n rateur automatique de code A partir d un composant dont on veut accro tre la testabilit il g n re le squelette du composant BIT correspondant et le testeur graphique distribu associ que nous avons pr sent dans la section pr c dente Il laisse seulement l criture la charge du d veloppeur de ce que l on veut tester mais pas le protocole de test lui m me pr d fini La librairie est ainsi plus efficace utiliser ce qui est important dans le cadre des d veloppements rapides propres au CBSE Tout comme la librairie ce logiciel a t impl ment en Java Le choix de ce langage rev t plusieurs avantages Tout d abord l interface graphique du g n rateur utilise l architecture d interface utilisateur graphique Swing
16. i re phase appel e Contract Testing dans le projet le test est bas sur le Pour de plus amples d tails consulter http www component plus org concept de contrat entre entit au sens de Meyer Meye97 et pour la deuxi me phase appel e QoS Testing dans le projet le test est bas sur une approche de supervision monitoring proche des m canismes d administration des syst mes distribu s Nous focalisons sur la premi re phase La Figure 1 illustre la place de ces deux types de test Le troisi me type de test d di aux composants sur tag re traite du probl me particulier de ce type de composants Nous y reviendrons longuement La technologie d velopp e au sein du projet a t mise en uvre sur quatre tudes de cas et neuf projets pilotes industriels repr sentants une large palette de domaines d application Les r sultats de ces tudes ont t tr s positifs montrant une am lioration significative de la qualit des composants d velopp s et bien s r de leur testabilit Les efforts d int gration ont ainsi t consid rablement diminu s environ 50 Apr s avoir dans ce qui suit examin les deux grandes activit s de test d finies dans le projet nous d taillons le d veloppement de composants testables et enfin nous traitons du cas particulier des composants COTS Tests bas s Contrat versus test bas s Qualit de Service QoS Le contract testing permet de v rifier si un composa
17. imize program overheads and resources for supporting tests of testable components La technique que nous pr sentons dans ce chapitre tente de r pondre pr cis ment ces trois questions 2 Built In Test int gration de fonctionnalit s de test L approche pr sent e ici est issue du projet europ en Component IST 1999 20162 Ce projet a d velopp une nouvelle technique permettant d int grer des fonctionnalit s de test Built In Test ou plus simplement BIT dans la suite de ce document des composants logiciels Une architecture utilisant ces fonctionnalit s a t d finie Elle permet le d veloppement et le test de composants testables Dans le projet trois types de tests ont t identifi s Contract testing concernant le niveau assemblage et bas tat quand la description des composants se fait par des machines tats Quality of service testing concernant aussi le niveau assemblage mais traitant plus particuli rement des aspects comme la r sistance aux pannes la ma trise des temps de latence ou encore la trace des ex cutions COTS based product testing concernant le niveau acquisition et traitant plus particuli rement des composants sur tag re En effet comme nous l avons dit pr c demment les deux phases dans la construction d applications bas es composants n cessitant de nouvelles m thodes de test sont la phase d int gration et celle de validation Pour la prem
18. n suppos d un composant il est indispensable de le tester dans son nouvel environnement De plus certains composants logiciels intervenant dans des applications critiques temps r el n cessitent parfois de pouvoir tre v rifi s en situation d ex cution Il est donc primordial pour un utilisateur de composants de disposer de moyens d appr hender cette activit de validation Nous traitons dans ce chapitre du test du comportement d un composant en situation d ploiement et d taillons une approche concr te visant doter un composant d un certain nombre de fonctionnalit s internes dont la personnalisation et l usage aident au moment du d ploiement valuer le composant voire le re configurer dynamiquement Nous discutons en particulier de tests int gr s Built In Test BIT Comp01 et illustrons cette id e par la mise en uvre d un outil Java plus particuli rement d di aux composants sur tag re COTS components Ce chapitre est organis de la fa on suivante nous traitons rapidement dans une premi re section du test de composants en g n ral principalement pour le comparer avec le test d applications classiques Dans la deuxi me section nous d taillons une approche industrielle concr te permettant d int grer les fonctionnalit s de test dans des composants Cette approche g n rale est illustr e et mise en uvre au travers d un outil Java que nous avons d velopp et qui est d
19. nt d ploy dans un nouvel environnement est capable de fournir les services qu il est suppos d livrer c est dire s il remplit son contrat vis vis des composants qui utilisent ses services Cette approche bas e sur la notion de contrat d finit par Meyer Meye97 repose essentiellement sur la mise en accessibilit au client de moyens de test permettant la d finition de contrats mais galement un acc s aux tats du composant Cela permet au client de placer le composant dans un tat sp cifique d invoquer un ou plusieurs des services qu il propose et de v rifier la pertinence du r sultat notamment au niveau de l tat final dans lequel se trouve le composant il faut que ce soit celui sp cifi Ces contrats de tests sont typiquement ceux r alis s lorsqu un syst me est configur pour la premi re fois ou lorsqu une reconfiguration est r alis e par exemple remplacement d un composant par un autre Le Quality of Service testing pour sa part est un processus continue de v rification du comportement d un assemblage de composants qui coop rent dans un syst me donn Cette activit de test est men e au niveau syst me et recouvre des aspects comme les temps d ex cution les charges de processeurs les inter blocages etc La Figure 1 synth tise le positionnement de ces deux types de test l un par rapport l autre Test bas Contrat I I Composant A lt i gt Composant B Syst me
20. nt la n cessit pour les composants logiciels de disposer de fonctionnalit s de test Notre approche peut paraitre limit e par le fait qu elle ne s applique qu a des composants poss dant des capacit s d introspection m canisme de r flexion pour la librairie BIT J par exemple Il faut noter que d une part c est un minimum pour pouvoir manipuler un l ment boite noire qui de plus est ext rieur et que d autre part l introspection est maintenant un m canisme disponible dans de plus en plus de langages Java Python C ou d infrastructures EJB CCM NET Les intergiciels r flexifs ont t d ailleurs r cemment d finis comme une priorit du 6 programme cadre europ en sur les syst mes distribu s De plus comme nous l avons illustr par l existence d un g n rateur automatique cette approche assure que les protocoles de test sont crits une fois pour toute et que les propri t s des composants sont accessibles dynamiquement en ex cution Le processus de test est lanc l aide d objets cas de test permettant l utilisation des interfaces de contrats de testabilit qui sont impl ment s par les composants BIT Pour ce qui est des le ons retenir de l utilisation du Built In test les exp riences men es sur des projets industriels pilotes d montrent l efficacit de l approche pour la phase d int gration o 50 environ d effort est conomis La technologie est un
21. peu trop r cente pour faire des bilans encore plus grande chelle Il y a en fait deux mani res de consid rer le BIT soit les fournisseurs de composants adh rent notre technique de conception de composant soit les utilisateurs doivent tablir des composants BIT partir des composants ordinaires Dans le premier cas les fournisseurs ajoutent de la valeur ajout e leurs composants COTS en les dotant de fonctionnalit s de test param trables C est le cas id al mais le moins r aliste pour l instant Nous avons travaill fournir des solutions au deuxi me cas en permettant de g n rer automatiquement des composants testables pour notre librairie BIT J partir de composants ordinaires mais supportant l introspection Pour r sumer les probl mes restant traiter en la mati re et qui restent donc des challenges pour nos recherches futures dans le domaine nous retiendrons la substitutabilit des composants ou comment automatiser les processus de choix et de remplacement d faillance inad quation Plus g n ralement l administration de composants devient une activit d ing nierie logicielle de plus en plus importante La technologie BIT est ind niablement un outil s inscrivant dans cette volution g n rale l valuation distante de composants en environnements h t rog nes dont notamment les applications bas es sur la technologie sans fil L encore l instabilit d applica
22. r doit ensuite finaliser le composant BIT en fonction de sa politique de test Nous pr sentons dans la sous section suivante la librairie elle m me avant de pr senter outil de g n ration de code BIT dans la sous section suivante La librairie BIT J Nous consid rons un composant comme un agr gat de sous composants qui sont les impl mentations des op rations qu il fournit En Java un tel composant est r alis la plupart du temps via une classe qui poss de des champs dont les types sont de ceux de ses sous composants et ce r cursivement La Figure 3 d crit la micro architecture dans laquelle un composant anonyme est connect avec les classes pr d finies de l approche BIT Legend all figures CC realize inherit from Statechart lt BIT state oO gt refer to g Y ii gt gt depend upon Statechart iL BIT state monitor lt a BIT component gt Component monitor l V lt interface gt State based IBIT Query check contract Boolean lt lt State based BIT State based BIT i 7 test case tester in state String Boolean l to state String Statecharts lt interface gt IBIT Query execution condition Boolean is testable Boolean BIT tester initialize test finalize test Fig 3 Version tendue bas e tat de la librairie Un composant BIT BIT component est construit de telle sorte qu il acquiert toutes l
23. rie BIT J Un testeur graphique distribu En compl ment de l impl mentation proprement dite des concepts BIT notre librairie fournit galement la possibilit de prendre en compte la phase de test dans un environnement distribu Cette fonctionnalit nous a en effet paru essentielle car les composants sont souvent d ploy s sur des syst mes distants En utilisant la technologie JMX de Sun nous avons r alis une extension du testeur de la librairie pour le test distance cf Figure 4 interface BIT component tester MBean A Agent JMX BIT component tester Figure 4 Testeur distribu Cette technologie supporte le concept de Managed Bean MBean qui est un composant capable d tre administr distance monitoring prise de contr le du composant Nous avons donc tendu le testeur BIT sous la forme d un MBean Nous fournissons galement l agent JMX n cessaire la communication entre les machines distantes L agent d ploy sur le m me syst me que le composant agit comme un serveur qui transmet une vue du testeur aux diff rents clients qui 10 ogy D Location Edit View Go Bookmarks Tools Settings Window Help teed MBean View Back to Agent View Mo Attributes Location Edit View Go Bookmarks Tools Settings Window Help r A ST 2 List of MBean operations A amp gt A G 3 z amp AS eh Description of int seerch_ Object
24. rold Donglin Liang Saurabh Sinha An Approach To Analyzing and Testing Component Based Software Proceedings of the First International ICSE Workshop on Testing Distributed Component Based Systems Los Angeles CA May 1999 HCSS01 National Coordination Office for Information Technology Research and Development January 2001 High Confidence Software and Systems Research Needs available from http www ccic gov iwg hcss html JEDLO1 Jean Marc J z quel Daniel Deveaux and Yves Le Traon Reliable Objects Lightweight Testing for OO Languages IEEE Software July august 2001 MeNi98 Theo Dirk Meijler and Oscar Nierstrasz Beyond Objects Components pp 49 78 in Michael P Papazoglou and Gunter Schlageter eds Cooperative Information Systems Trends and Directions Academic Press 1998 Mey97 Meyer B Object oriented Software Construction Prentice Hall 1997 MeOb01 Meyers and Oberndorf Managing Software Acquistion Open Systems and COTS Products Addison Wesley 2001 SUNO2 Sun Java Management Extensions JMX 1 2 Available at http java sun com products JavaManagement 2002 Szyp99 Szyperski C Component Software Beyond Object Oriented Programming Addison Wesley 1999 VMO3 Built in test Vade Mecum Component Internal Report 2003 Available at http www component plus org pdf reports 17
25. ser le test tablir les condition d ex cution r cup rer les r sultats et ou les checs et finaliser le test Chaque composant BIT doit personnaliser surcharger ces actions basiques en tenant compte opportun ment des valeurs propres de Component Le BIT tester permet de d velopper des sc narios de test s quences r sultats attendus politique de s quencement Par rapport l architecture pr c demment d crite la librairie BIT J n impl mente pas la notion d Handler L interpr tation des r sultats de test est une activit tr s d pendante de l application et assez peu d l ments de cette activit sont g n ralisables Un grand b n fice de cette approche est que la majeure partie du processus des tests ne d pend pas de la sp cificit du composant valu Par exemple les composants COTS achet s afin de r pondre des besoins sp cifiques peuvent tre compar s sur la base du m me cadre de test Un inconv nient de notre approche est que les sous composants sont des entit s enti rement encapsul es et comme telles il est difficile d analyser et de d terminer des diagnostics un niveau profond d agr gation Nous ne traitons pas par exemple de la composition des parties BIT de sous composants testables Mais ceci n est pas g nant tant donn que nous consid rons surtout des COTS et donc des composants bo te noire Barb03 L outillage de la librai
26. t tre trouv dans BeBB04 Conclusion et enjeux Nous avons abord dans ce chapitre le test de composants logiciels Nous avons soulign l importance de doter les composants de capacit s de test Les comportements individuels des composants sont souvent inclus dans leur partie cach e Une sp cification si possible formelle des comportements est donc primordiale pour rendre effectif le test de composant Celle ci n est pas toujours disponible et est le plus souvent insuffisante si le composant ne fournit pas d outil sp cifique son valuation en situation Le Built In Test que nous avons longuement d taill dans ce chapitre est une technique pour aider cr er la confiance n cessaire au plein essor du CBSE Les vendeurs peuvent quiper leurs composants avec cette technologie afin de les tester directement sp cialement lorsque leur environnement de d ploiement est inconnu ou changeant Cette approche am liore la puissante id e de la conception par contrat de Meyer en permettant la description d assertions pr conditions post conditions et invariants bas es sur les tats complexes parall les et parfois concurrents du composant qui s articulent largement sur les sous composants Nous avons illustr plus particuli rement dans ce chapitre l application que nous faisons de la technologie BIT aux composants sur tag res les composants COTS La sp cificit 15 des composants COTS justifie pleineme
27. t s dans la section 2 Mais avant de d tailler les aspects de test des composants explicitons quelques termes sont li s cette activit On distingue g n ralement quatre types de tests en fonction des phases de d veloppement auxquelles ils sont li s Les premiers tests appel s tests unitaires concernent les composants l mentaires de l application tester La phase suivante concerne les tests d int gration correspondant au moment o les composants l mentaires sont assembl s On teste ensuite les l ments fonctionnels de l application en examinant comment les diff rents composants collaborent on parle ainsi de test d interop rabilit On teste enfin l application compl te dans son environnement d ex cution On parle alors parfois de tests syst me mais comme ils consistent v rifier l absence de fautes ou de comportements incorrects de l impl mentation par rapport la sp cification du syst me attendu on parle le plus souvent de fests de conformit En g n ral ce genre de test consiste envoyer des entr es au syst me donn e ou signal en attendant de sa part une sortie particuli re On parle alors de tests actifs le testeur ma trisant compl tement les v nements envoy s l impl mentation On peut galement pratiquer un fest passif on parle alors plut t de monitoring consistant laisser s ex cuter le syst me tout en observant et en analysant son comportement Test des assemblag
28. t comme dans notre exemple de la Stack le d veloppeur doit d crire l automate d tats du composant BIT dans le squelette g n r Figure 9 java util Stack a 7 Not empty push item ous pop size 2 pop size lt gt 2 Me puch item 2 Figure 9 Automate d tats du composant Stack Pour le composant Stack quatre tats sont d finis Empty Only one More than one et Not empty Ces tats doivent tre d clar s dans la m thode initialisant le comportement du composant init_behavior protected void init_behavior throws Statechart_exception state defitions and formal relationships here _Empty new BIT_state Empty _Only_one new BIT_state Only one _More_than_one new BIT_state More than one _Not_empty BIT state _Only _one xor _More_than_one name Not empty _BIT_stack new BIT_state_monitor _Empty xor _Not_empty BIT stack _Empty inputState 14 Not empty est un tat compos des tats Only one et More than one Le composant Stack ne doit jamais tre dans l tat Not empty et dans l tat Empty simultan ment Le moniteur d tats state monitor _BIT_stack est d clar pour v rifier cette propri t Enfin le composant est initialis dans l tat Empty inputState L interface de test est g n r e automatiquement elle ne n cessite aucune modification La troisi me partie du squelet
29. te du composant BIT est compos d op rations correspondant aux op rations du composant original Chaque op ration g n r e comprend un appel l op ration d origine Dans le cas bas tat le d veloppeur doit coder les transitions sp cifi es par l automate du composant Par exemple pour l op ration push du composant Stack on d finit trois transitions Empty vers Only one Only one vers More than one et More than one Vers More than one public java lang Object push java lang Object 01 throws Statechart_exception java lang Object result _stack push ol state transitions here _BIT_stack fires fromState toState _BIT_stack fires _Empty _Only one _BIT_stack fires _ Only one More than one _BIT_stack fires _ More than _ one More _than_one _BIT_stack run_to_completion cycle d interpr tation ininterruptible return result Dans cette phase le d veloppeur peut galement ajouter des op rations de test sp cifiques Enfin il d crit quelles op rations seront manipulables via l interface JMX fichier BIT_stack_testerMBean java pour la Stack La quatri me tape Figure 7 D est l tape d ex cution des tests Pour ce faire le d veloppeur lance le serveur JMX et se connecte au composant BIT via un simple navigateur Web Il peut le faire localement ou depuis une machine distante applications embarqu es ou distribu es Un exemple plus complet de mise en uvre peu
30. tions hautement distribu es demande l int gration de composants tr s haute confiance et adaptatifs aux situations L encore la technologie BIT est un outil incontournable Les auteurs tiennent remercier leur coll gues du projet Component pour leur contribution ces travaux Bibliographie Atki01 Atkinson C et al Component Based Product Line Engineering with UML Addison Wesley London 2001 BaBB03 Barbier F Belloir N Bruel J M Incorporation of Test Functionality in Software Components 2nd Intl Conference on COTS Based Software Systems Ottawa Canada 10 12 February 2003 Barb03 Franck Barbier Built in test vade mecum part V Built in Test for COTS based Products Component Internal Report 2003 Available at http www component plus org pdf reports bitvm_pv pdf 16 BeBB04 Nicolas Belloir Jean Michel Bruel and Franck Barbier Int gration du test dans les composants logiciels Num ro sp cial de la revue L Objet X 1 89 102 2004 Bohr01 Adrita Bhor Software Component Testing Strategies 2001 Available at http www netra ics uci edu abhor ics22 1 comp_test htm Comp01 Component Project Technical Report Built in Testing for Component based Development http www component plus org Gao00 Jerry Gao Component Testability and Component Testing Challenges 2000 Available at http www sei cmu edu cbs cbse2000 papers 18 18 html HaLS99 Mary Jean Har
31. trospection du langage de programmation utilis ou bien encore par la pr sence de m ta information c est dire que le composant soit porteur d information sur lui m me et accessibles l utilisateur Les langages modernes comme Java Python ou C disposent de m canismes d introspection qui permettent partir du code ex cutable d obtenir par exemple la liste des m thodes fournies Consid r s par certains comme une violation du principe d encapsulation ces m canismes n en sont pas moins fort utiles pour notre probl matique Ce sont les m canismes de r flexion de Java qui nous ont notamment permis de d velopper un g n rateur automatique de BIT code pour composant COTS d taill dans la section suivante 3 Une technologie disponible en Java la librairie BIT J Introduction Nous sommes actuellement en phase de finalisation de la librairie BIT J Nous avons d velopp un outil de g n ration automatique qui partir d un composant Java g n re une partie importante du code des fonctionnalit s de test ainsi qu une interface de test permettant de manipuler le composant distance l aide de la technologie JMX SUNO21 L utilisation du g n rateur est d taill la fin de cette section cf Figure 6 Le g n rateur produit quatre fichiers le composant BIT le testeur et deux fichiers n cessaires JMX pour le fonctionnement du test distance l interface JMX et l agent JMX L utilisateu
32. usieurs interfaces de test cf Figure 2 Le concepteur du composant fournit ces interfaces aux utilisateurs BIT component Functional Interface Functional Code Test interface Test Code Figure 2 Concept de composant testable BIT component Parmi les erreurs qui peuvent se produire dans un syst me bas composant il y a celles propres un composant donn et qui peuvent tre d tect es directement par des tests int gr s au composant e g coh rence des donn es et celles d un niveau syst me e g inter blocages qui n cessitent des entit s de test externes au composant lui m me Une v ritable architecture de test est donc propos e Architecture de test L architecture BIT est bas e sur les l ments suivants BlT components des composants testables au sens de ceux d finis pr c demment Testers des composants utilisant les services des BIT components pour d tecter des erreurs de niveau syst me Handlers des composants qui traitent les erreurs d tect es au niveau du BIT component ou au niveau du Tester System constructor un l ment conceptuel responsable de l instanciation des diff rents l ments architecturaux ainsi que de leur interconnexion Au niveau BIT component les erreurs internes au composant testable sont d tect es Au niveau tester les erreurs externes syst me provenant d une mauvaise interaction entre composants sont d tect es L archite
Download Pdf Manuals
Related Search