Les Tests : L état de l Art

Transcription

1 Les Tests : L état de l Art Tests et Validatin du lgiciel CNAM 2008 / CENTRE REGIONAL DE LILLE NFE209 AUDIT ET GOUVERNANCE DES SYSTEMES D INFORMATION

2 AUDITEURS AUDITEUR NUMERO D AUDITEUR Stéphane CALIMET NPC Philippe FIRMIN NPC Eric LELEU NPC HISTORIQUE DES MODIFICATIONS DATE AUTEUR DESCRIPTION VERSION 08/01/2009 S. CALIMET, Ph. FIRMIN, E. LELEU Créatin V_1.0 26/01/2009 E. LELEU Intrductin, Les tests et le cycle de vie 15/04/2009 S. CALIMET, E. LELEU Avantages incnvénients des cycles V_2.0 V_3.0 30/04/2009 S. CALIMET, E. LELEU Tests d intégratin V_4.0 19/05/2009 S. CALIMET, E. LELEU Tests de charge V_5.0 21/05/2009 S. CALIMET, E. LELEU Tests Validatin (Fnctinnel) V_6.0 28/05/2009 S. CALIMET, E. LELEU Test Validatin (Structurel) V_7.0 03/06/2009 S. CALIMET, E. LELEU Glssaire V_8.0 05/06/2009 P. FIRMIN Test Qualité, utils de test V_9.0 27/06/2009 P. FIRMIN, E. LELEU «Cnfrmiq Test Generatr» V_10.0 1

3 LES TESTS : L ETAT DE L ART TESTS ET VALIDATION DU LOGICIEL SOMMAIRE PREAMBULE : NECESSITE DES TESTS... 5 I - INTRODUCTION AUX TESTS LOGICIELS QUELQUES EXEMPLES DE BUGS LES DEFINITIONS DES TESTS LES CLASSES DE DEFAUT DIFFICULTES LIEES AUX TESTS LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS LE MODE D EXECUTION LES MODALITES DE TEST LES METHODES DE TEST LES NIVEAUX DE TEST LES CARACTERISTIQUES DE TEST EXEMPLE DE CLASSEMENT SELON 3 AXES QUELQUES PRINCIPES UTILES II LA STRATEGIE DE TESTS GENERALITES L ACTIVITE TEST III TYPES DE TESTS DANS LE PROJET LES TESTS ET LE CYCLE DE VIE LES TESTS UNITAIRES LES TESTS D INTEGRATION LES TESTS DE CHARGE LES TESTS DE VALIDATION

4 PREAMBULE LES PRINCIPALES TECHNIQUES DE VALIDATION IV LES TESTS ET LA QUALITE LES CONSEQUENCES DE CET ETAT DE FAIT LES EDITEURS LES SOCIETES DE SERVICES EXEMPLE: INDICATEURS QUALITE V LES OUTILS DE TEST LES OUTILS D AIDE A LA REALISATION DES TESTS MERCURY WINRUNNER ET QUICKTEST PRO DE MERCURY QUALITY CENTER QARUN DE MICRO FOCUS ABBOT (OPEN SOURCE) RATIONAL ROBOT DE IBM IRISE STUDIO DE IRISE LES OUTILS DE CAMPAGNE DE TEST TESTDIRECTOR DE MERCURY QUALITY CENTER - HP SALOMÉ TMF (OPEN SOURCE) TEST MANAGER DE SOFT EDITION.NET QADIRECTOR DE MICRO FOCUS LES OUTILS DE TESTS FONCTIONNELS LEIRIOS TEST GENERATOR DE LEIROS CONFORMIQ TEST GENERATOR DE CONFORMIQ SOFTWARE MERCURY FUNCTIONAL TESTING ET MERCURY SERVICE TEST DE MERCURY QUALITY CENTER. 72 AUTRES OUTILS DE TESTS FONCTIONNELS LES OUTILS DE TESTS STRUCTURELS C++TEST,.TEST, JTEST, SOATEST ET INSURE++ DE PARASOFT RATIONAL TEST REALTIME DE IBM XUNIT : JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC LES OUTILS DE TESTS DE PERFORMANCE WAPT DE SOFTLOGICA MERCURY LOADRUNNER DE MERCURY QUALITY CENTER HP

5 SIEGE (OPEN SOURCE) JMETER (OPEN SOURCE) DU GROUPE APACHE QALOAD DE MICRO FOCUS PERFORMANCE CENTER DE EMBARCADERO WEB PERFORMANCE LOAD TESTER DE WEB PERFORMANCE, INC VI - BILAN ET PERSPECTIVES VII CONCLUSION REFERENCES : BIBLIOGRAPHIE / «WEBOGRAPHIE» GLOSSAIRE

6 PREAMBULE : NECESSITE DES TESTS Les tests existent depuis lngtemps. Après avir été délaissés par manque d intérêts de la part des dévelppeurs, il semblerait que se sit aujurd hui les directins infrmatiques qui prennent cnscience de leur véritable utilité. Ils permettent de rassurer et de palier aux erreurs humaines. Avec l imprtance crissante des prjets infrmatiques, les risques de dysfnctinnement, de retards u de pertes financières augmentent. La réussite et la rentabilité d un prjet passent par un suivi rigureux, tut au lng du prcessus, de la qualité de la réalisatin. Il ne fait aucun dute que la plitique de tests est aujurd hui une dimensin incnturnable de la gestin de prjet. Des frmatins sur la qualité des lgiciels, les tests applicatifs vient le jur, preuve que les tests n nt jamais été si au cœur de tus les prjets. Le chix de ntre sujet a été guidé par ce sudain enguement de la part des directins infrmatiques pur les tests. Cependant, il est à préciser que chacun de nus dispse d une visin et d un intérêt différent vis-à-vis de ce vaste sujet : - Eric a été amené dans un premier temps à mettre en place une équipe de tests au sein de sa sciété pur un prjet d envergure. Frt de cette réussite, il a eu l ccasin ensuite de déplyer en clientèle les utils et méthdes dévelppés. Il juge que cette activité est à frt ptentiel. - Philippe a une raisn différente : Il est amené dans le cadre de sn activité prfessinnelle à assurer un plan d'assurance qualité, ce qui induit de psséder une vue d'ensemble sur les tests lgiciels. Le plan mis en place dans sa sciété ne cuvrant que la partie dévelppement, le fait s rienter tut naturellement vers les utils de gestin de tests. - Stéphane désire traiter ce sujet car n évluant pas prfessinnellement dans le mnde du dévelppement, les tests snt pur lui une terre incnnue. Il apprtera un regard neuf quant à la façn d appréhender ce thème. Tutefis, nus avns tus les tris un pint cmmun : nus smmes tus intervenus dans la mise en prductin d un prjet. Vus aurez l ccasin dans ce dssier de cnstater tut d abrd qu il est difficile de définir précisément le test applicatif. La diversité des tests puvant être menés lrs d un même prjet, nus amènera à traiter le test sus divers angles : thérique et pratique (utilisatin d utils de tests). 5

7 I - INTRODUCTION AUX TESTS LOGICIELS 1 QUELQUES EXEMPLES DE BUGS Les ambulances de Lndres snt mal rientées par le lgiciel. Des pertes humaines snt à déplrer Explsin de la fusée Ariane 5 au but de 30 secndes de vl suite à une erreur de cnversin de dnnées numériques Défaillance du système d'alarme d'une centrale qui prduisit une cupure d'électricité aux Etats-Unis et au Canada Deux grandes banques françaises exécutent un duble débit pur plus de transactins. 2 LES DEFINITIONS DES TESTS Avant de nus lancer dans la définitin des tests, il est imprtant de définir la différence entre une erreur, un défaut et une anmalie. «On cnstate une ANOMALIE due à un DEFAUT du lgiciel lui même du a une ERREUR de prgrammeur.» Il n'existe pas de définitin unique des tests. Nus vus en prpsns quatre permettant d'appréhender les tests sus différents angles. Seln l AFNOR : «Phase du prjet dans laquelle le client et le furnisseur testent la crrespndance entre ce qui a été cmmandé et ce qui est effectivement prduit.» Seln Glendfrd.J Myers dans «The art f sftware testing» : «Un test réussi n'est pas un test qui n'a pas truvé de défauts, mais un test qui a effectivement truvé un défaut.» Seln Bill Hetzel : «Le test est une activité destinée à déterminer si l'évaluatin d'une caractéristique u d'une aptitude d'un prgramme u d'un système dnne les résultats requis.» 6

8 Seln l'ieee (Institute f Electrical and Electrnics Engineers): «Le test est l'exécutin u l'évaluatin d'un système u d'un cmpsant, par des myens autmatiques u manuels, pur vérifier qu'il répnd à ses spécificatins u identifier les différences entre les résultats attendus et les résultats btenus.» 7

9 3 LES CLASSES DE DEFAUT Les erreurs peuvent être de divers rdres. Il peut s'agir d'erreurs : de calcul de lgique d'entrée / srtie de traitement des dnnées (dépassement de tableau) d'interface (cmmunicatin entre les prgrammes) de définitin des dnnées Ces erreurs représentent 90% des cas décelés. 4 DIFFICULTES LIEES AUX TESTS Même si les tests fnt l'bjet de méthdes, de planning... tel un véritable prjet infrmatique, il n'en reste pas mins que certains paramètres viennent perturber leurs exécutins : Il est impssible de réaliser un test exhaustif (le prduit cartésien de certaines variables prendrait trp de temps à tester). La qualité des tests dépend des dnnées utilisées (dnnées de test). Il est impssible de supprimer l'erreur humaine. Il existe naturellement une perte d'infrmatins entre la cllecte du besin client, la perceptin de ce même besin par le chef de prjet et le besin mdélisé par le dévelppeur. Surce : Curs CNAM Génie Lgiciel Il existe des difficultés d'rdre psychlgique u culturel. Il existe un manque d'intérêt pur les tests car les prgrammeurs nt l'impressin que l'n ne pinte du digt que leurs erreurs. Il existe des difficultés dites frmelles : il n'existe à ce jur aucun algrithme capable de pruver l'exactitude ttale d'un prgramme. 8

10 Il existe bien évidemment de nmbreux autres paramètres venant perturber l'activité tests : - la taille et la cmplexité des prgrammes, - la différence entre l envirnnement de dévelppement et de prductin... 9

11 5 LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS Il existe différentes façns de classifier les tests. Il n existe pas de classificatin fficielle : Chaque uvrage, auteur, site, définit à sa manière les différentes techniques de tests. Il est cependant pssible de les regruper seln leur mde d exécutin, leurs mdalités, leurs méthdes, leurs niveaux et leurs caractéristiques. LE MODE D EXECUTION Le test Manuel : Les tests snt exécutés par le testeur. Il saisie les dnnées en entrée, vérifie les traitements et cmpare les résultats btenus avec ceux attendus. Ces tests snt fastidieux et ffrent une plus grande pssibilité d erreurs humaines. Ces tests snt très vite ingérables dans le cas d applicatins de grandes tailles. Le test Autmatique : Le testeur est en partie déchargé des tests dans la mesure ù les tests snt réalisés par des utils (JUnit par exemple dans le mnde Java). LES MODALITES DE TEST Il s agit de tests : Statiques : Les tests snt réalisés «par l'humain» (testeur), sans machine, par lecture du cde dans le but de truver des erreurs. Il peut s agir : de l inspectin u d une revue de cde; d un travail de cllabratin lrs d une réunin (le prgrammeur, le cncepteur, un prgrammeur expérimenté, un testeur expérimenté, un mdérateur ) Dynamiques : On exécute le système de manière à tester l ensemble des caractéristiques. Chaque résultat est cmparé aux résultats attendus. 10

12 LES METHODES DE TEST Il s agit de tests : Structurels (Bîte blanche) : Les tests structurels repsent sur des analyses du cde surce. Il est pssible d analyser la structure du prgramme. Fnctinnels (Bîte nire) : Les tests fnctinnels repsent sur une spécificatin (frmelle u infrmelle) du prgramme. Le cde surce du prgramme n est pas utilisé. Les tests fnctinnels permettent d écrire les tests bien avant le «cdage». Il est parfis utile de cmbiner ces deux méthdes. LES NIVEAUX DE TEST Il s agit de tests réalisés tut au lng de la vie du lgiciel (cycle de vie). Unitaires : s'assurer que les cmpsants lgiciels pris individuellement snt cnfrmes à leurs spécificatins et prêts à être regrupés. D intégratin : s'assurer que les interfaces des cmpsants snt chérentes entre elles et que le résultat de leur intégratin permet de réaliser les fnctinnalités prévues. Système : s'assurer que le système cmplet, matériel et lgiciel, crrespnd bien à la définitin des besins tels qu'ils avaient été exprimés. On parle de validatin u de recette. De nn régressin : vérifier que la crrectin des erreurs n'a pas affecté les parties déjà dévelppées et testées. Cela cnsiste à systématiquement rejuer les tests déjà exécutés. LES CARACTERISTIQUES DE TEST Il s agit entre autre de tests : De Rbustesse : permet d'analyser le système dans le cas ù ses ressurces snt saturées u bien d'analyser les répnses du système aux sllicitatins prche u hrs des limites des dmaines de définitin des entrées. Suvent ces tests ne snt effectués que pur des lgiciels critiques, nécessitant une grande fiabilité. De perfrmance : permet d'évaluer la capacité du prgramme à fnctinner crrectement vis-à-vis des critères de flux de dnnées et de temps d'exécutin. Ces tests divent être précédés tut au lng du cycle de dévelppement du lgiciel d'une analyse de perfrmance, ce qui signifie que les prblèmes de perfrmances divent être pris en cmpte dès les spécificatins. 11

13 6 EXEMPLE DE CLASSEMENT SELON 3 AXES Surce : 7 QUELQUES PRINCIPES UTILES Si pssible faire tester par un autre dévelppeur que celui qui a cdé. Ne jamais partir du principe qu'un test ne truvera pas d'erreurs. Examiner et mémriser les rapprts de tests. A la mindre mdificatin ne pas hésiter à refaire les tests (test de nn régressin). 12

14 II LA STRATEGIE DE TESTS 1 GENERALITES Cmme nus l avns vu précédemment, les tests snt primrdiaux. Il en va de même de la stratégie de tests. Une technique de tests adaptée et puissante restera sans effet si elle ne fait pas partie d une stratégie de tests. Ce que nus ne nus dutns pas, c est qu une stratégie de tests peut représenter plus de 50% de la charge ttale d un prjet. Il est dnc pprtun que cette stratégie sit pensée et définie de façn rigureuse et qu elle sit intégrée dans le prcessus de dévelppement du lgiciel. Les tests divent être cnçus avant que le lgiciel sit réalisé : l activité tests cmmence dès la phase de spécificatin d un lgiciel et se dérule durant tutes les phases du cycle de dévelppement. C est ainsi que la cnceptin du lgiciel va faciliter les tests (testabilité). La stratégie de test dépend : - De la criticité du prduit à réaliser - Du cût de dévelppement Une stratégie cnsiste à définir : - Les ressurces mises en œuvre (équipes, testeurs, utils ) - Les mécanismes du prcessus de test (gestin de la cnfiguratin, évaluatin du prcessus de test ) Finalement, la stratégie de tests tient cmpte : - Des méthdes de spécificatin, de cnceptin (pur rappel, les tests snt cnçus avant le dévelppement) - Du langage de prgrammatin utilisé - Du type d applicatin (temps réel, base de dnnées ) - L expérience des prgrammeurs - 13

15 L activité tests est un PROJET à part entière. C est la raisn pur laquelle nus retruvns l ensemble des caractéristiques d un prjet : Organisatin des équipes Planificatin et cntrôle (planificatin, estimatin des charges, définitin des métriques, définitin des envirnnements matériels et lgiciels, définitin de la campagne, du plan et des livrables) Analyse et cnceptin (rganisatin du référentiel, identificatin des cnditins de tests, traçabilité, cas de tests, dnnées de tests, prcédures de tests, scénaris) Implémentatin, suivi et exécutin Gestin des cnfiguratins (Elle assiste les tests) Evaluatin des risques (Décrire les risques cmme un prblème prbable qui peut cmprmettre l atteinte des bjectifs des tests) Gestin des incidents Evaluatin et «reprting» Clôture (recette u arrêt des tests) Bilan prjet Améliratin des prcessus et mutualisatin 14

16 2 L ACTIVITE TEST Stratégie de tests L ensemble de la stratégie de tests est détaillé dans le Plan Qualité Prjet (PQP). Le plan qualité prjet est très imprtant. Il va ntamment : Définir l rganisatin à mettre en place (équipe de tests). Une stratégie de tests est (u devrait être) une rganisatin à part entière. Les tests snt généralement réalisés pas des dévelppeurs (autres que ceux qui nt dévelppés le prduit). Le Chef de prjet quant à lui, suit les activités, calcul le reste à faire, enregistre et analyse les métriques et les incidents, élabre les tableaux de brd Définir les respnsabilités et relatins entre les différents intervenants. Définir les types et les bjectifs de tests pur chacun des niveaux (tests unitaires, tests d intégratin, tests de validatin). Définir les utils qui sernt utilisés. Définir les myens et les délais à investir dans l activité de tests. La stratégie de tests vise à rendre l effrt de test efficace en : Maximisant les chances de détecter les erreurs. Tentant de truver le plus d erreurs pssibles, le plus rapidement pssible. Facilitant le diagnstique. Plan de tests Le plan de tests est la cntinuité lgique au plan qualité prjet. L ensemble des pints évqués de manière générale vnt y être détaillés. C est ainsi qu il existe autant de plan de tests que de phases de qualificatin du prduit. Au dssier de SPECIFICATION crrespnd le plan de tests de VALIDATION. Au dssier de CONCEPTION GENERALE crrespnd le plan de tests d INTEGRATION. Au dssier de CONCEPTION DETAILLEE crrespnd le plan de tests UNITAIRES. De manière générale, les tests se dérulent du général au particulier (détail). L bjectif de chaque plan de tests est de furnir un prgramme pur vérifier que le lgiciel prduit satisfait les spécificatins et la cnceptin du lgiciel. 15

17 Un plan de test dit : Définir les éléments à tester et l rdre dans lequel ils divent être testés (planifier les tests). Décrire l envirnnement de tests. Définir la façn dnt les tests vnt être menés (prcédures) : prcessus exacts à mener, l histrisatin, la traçabilité, le reprting, le suivi, le cntrôle Il s agit de la prcédure de tests. Il est imprtant que cette prcédure sit répétable. Décrire et cnstituer les fiches de tests (définir les actins à réaliser, les jeux de dnnées à utiliser, les valeurs et les cmprtements attendus). L ensemble des fiches de tests cnstitue le dssier de tests. Il est imprtant de cncevir le dssier de test de manière «POSITIF» et «NEGATIF». Fixer les critères d arrêt des tests : seln la cuverture définie, seln le nmbre d erreurs truvés, seln le temps imparti (Appliquer la stratégie de tests aux tests). Rapprt de test Pur chaque phase de test (unitaires, d intégratin, de validatin), l équipe dédiée aux tests dit élabrer un rapprt de tests. Ce rapprt est la synthèse des actins menées suivantes : Exécutin des fiches de tests (effectuer les actins décrites). Analyser les résultats btenus : cmparer les résultats attendus avec les résultats btenus. Les éléments de mesure snt très imprtants! Emettre des fiches de nn-cnfrmité si nécessaire (ces fiches snt aussi appelées fiches d anmalie, fiches de bug). Il s agit de cupler intelligemment la gestin des tests et la gestin des crrectins (incidents). NB : Cncernant les fiches d anmalie, il est cnseillé de réaliser une fiche par prblème décelé afin de faciliter le suivi de celles-ci. Cnsigner tus les résultats d exécutin de tests. Rédiger des cmptes rendus de tests. La smme de ces cmptes rendus cnstituera le rapprt de tests. Qualificatin, Validatin La qualificatin est essentielle. Elle permet de cnclure et d émettre un avis sur le prduit dévelppé et sa mise en prductin : adéquatin entre prduit et spécificatins fnctinnelles et techniques. 16

18 III TYPES DE TESTS DANS LE PROJET 1 LES TESTS ET LE CYCLE DE VIE Il existe principalement 3 cycles de vie principaux: en Cascade, en V, en Spirale. Pur rappel, vici ci après la définitin et le schéma de chaque cycle. 1 Cycle en Cascade Il définit des phases séquentielles à l'issue de chacune desquelles des dcuments snt prduits pur en vérifier la cnfrmité avant de passer à la suivante. Dans le cas cntraire, un «Feed Back» (Retur arrière) est péré. Analyse des besins Spécificatin Cnceptin Réalisatin Validatin Surce : Curs CNAM Génie Lgiciel Maintenance 17

19 Avantages : La qualité des livrables (Un livrable réalisé à chaque fin de phase). Un calendrier plus facile à élabrer (Le planning crrespnd aux phases. La fin de chaque phase crrespnd à un jaln). Le prjet se passe dans le bn sens (Les phases se dérulent les unes après les autres Un seul fil directeur). Incnvénients : Difficulté de revenir en arrière en cas d insatisfactin client. Les mdificatins en amnt nt un impact majeur sur les cûts (Plus le prjet est avancé, plus un impact engendra un cût élevé cût expnentiel). Le temps de réactin est beaucup plus lng (Il est plus difficile de se rendre cmpte d une erreur Tests tardifs dans le prjet) Risque d effet tunnel (Les jalns permettent de scinder le prjet en phases clairement identifiées, évitant ainsi d'avir une fin de prjet à trp lngue échéance. On parle généralement d'«effet tunnel» pur désigner un prjet de lngue durée sans échéance intermédiaire.) 18

20 2 Cycle en V Le mdèle du cycle en V est un mdèle cnceptuel de gestin de prjet imaginé suite au prblème de réactivité du mdèle en cascade. Il permet, en cas d'anmalie, de limiter un retur aux étapes précédentes. Les phases de la partie mntante divent renvyer de l'infrmatin sur les phases en vis-à-vis lrsque des défauts snt détectés, afin d'amélirer le lgiciel. Le mdèle de cycle de vie en V part du principe que les prcédures de vérificatin de la cnfrmité du lgiciel aux spécificatins divent être élabrées dès les phases de cnceptin. Ce cycle est utilisé lrsque l envirnnement est stable et que le client cnnait sn besin dans le détail. Le cycle en V est devenu un standard de l'industrie lgicielle depuis les années Expressin des besins et faisabilité Recette Spécificatin Fnctinnelle et technique Qualificatin Cnceptin glbale Intégratin Cnceptin détaillée Tests unitaires Dévelppement Surce : adaptée de 19

21 Avantages : Temps de réactin meilleur grâce à la transversalité (Grâce aux phases de tests transversales, les imperfectins snt décuvertes plus rapidement) Anticipatin des étapes suivantes (Dans chaque phase, il faut prévir le dérulement de la suivante) En cas de prblème dans le prjet, il permet de limiter le retur aux étapes précédentes. Incnvénients : La phase de cnceptin est frtement liée à la phase de réalisatin. Le travail en équipe est OBLIGATOIRE. Mins adapté au dévelppement lgiciel (C est le temps qui nus le dit par cmparaisn au cycle itératif actuellement utilisé) Risque d effet tunnel (Les jalns permettent de scinder le prjet en phases clairement identifiées, évitant ainsi d'avir une fin de prjet à trp lngue échéance. On parle généralement d'«effet tunnel» pur désigner un prjet de lngue durée sans échéance intermédiaire.) 20

22 3 Cycle en spiral (Behm 1988) Le cycle en spirale est basé sur une apprche et une évaluatin des risques. A chaque risque identifié n lui affecte une pririté et dnc un rdre de traitement. Il s'agit ensuite de dévelpper par prttype successif. Chaque prttype ayant sn prpre cycle de vie (Analyse, cnceptin, réalisatin, intégratin, validatin...) Il emprunte au prttypage incrémental mais lui adjint une dimensin relevant de la prise de décisin managériale et nn purement technique. Il cuvre l'ensemble du cycle de dévelppement d'un prduit tut en mettant l'accent sur l'activité d'analyse des risques. Chaque cycle de la spirale cmprenant 6 phases : analyse du risque (1), dévelppement d'un prttype (2), tests du prttype (3), déterminatin des besins (4), validatin des besins (5), planificatin du prchain cycle (6). Ce cycle est utilisé dans le cas d un envirnnement instable et dans lequel le client ne cnnait pas suffisamment sn besin. Planificatin du prchain cycle Analyse du risque Validatin des besins 5 Dévelppement d'un prttype Déterminatin des besins 4 Tests du prttype Surce : adaptée de

23 Avantages : Cahier des charges respecté au pied de la lettre (Cahier des charges réalisé au fur et à mesure) Validité des besins (A chaque cycle les besins snt validés Mins de risque d erreurs) Incnvénients : Calendrier et budget suvent irréalistes (Chaque cycle fnt habituellement l bjet de dépassements - On ne sait chiffrer qu un seul cycle à la fis) Prblème pur les cmpsants externes (Difficulté d anticiper les cmpsants nécessaires dans les cycles ultérieurs) Sa mise en œuvre demande de grandes cmpétences et devrait être limitée aux prjets innvants à cause de l'imprtance qu'il accrde à l'analyse des risques. 22

24 4 - Cnclusin Quelque sit le cycle de vie du lgiciel retenu, n peut nter que les grandes phases du prjet snt tujurs présentes : Phase d'analyse Phase de cnceptin Phase d'intégratin Phase de validatin Par sucis de présentatin et de cmpréhensin, nus présentns ci dessus le cycle de vie en V dans lequel snt intégrés les tests. A l'expressin du besin crrespnd les tests de recette. Aux spécificatins crrespndent les tests systèmes. A la cnceptin glbale crrespnd les tests d'intégratin. A la cnceptin détaillée et au dévelppement crrespndent les tests unitaires. Expressin des besins et faisabilité Tests de recette Spécificatin Fnctinnelle, technique Tests de charge, tests de validatin Cnceptin glbale Tests d Intégratin Cnceptin détaillée Tests unitaires Dévelppement Surce : 23

25 2 LES TESTS UNITAIRES Définitin Le nm de test unitaire vient du fait qu'une partie de cde est appelé «unit». Ils snt aussi appelés test de cmpsants. Ce type de test va dnc vérifier un mdule du cde et ainsi s'assurer qu'il fnctinne de manière indépendante du reste du prgramme. Il va aussi vérifier que ce mdule respecte les spécificatins fnctinnelles et techniques du prduit. Les tests unitaires snt habituellement à la charge de l'équipe de dévelppement. Les tests unitaires peuvent être manuels (dans la plupart des cas) et/u autmatisés par des slutins lgicielles (permet de s'assurer d une nn régressin). Frmalisme des tests unitaires : la fiche de test Les tests unitaires snt frmalisés par une fiche que l n appel la fiche de test unitaire. Cette fiche est une liste (u aide mémire) qui dit permettre de rappeler les grandes actins d une phase de tests. Elle permet également de préparer les tests en l enrichissant tut au lng des dévelppements. Elle permet de stipuler que tus les pints à cntrôler nt été testés (tels que les tests d instructins, de cnditins, tests aux limites ). Dés le démarrage d un dévelppement u affectatin d une nuvelle tâche, le chef de prjet u l'analyste initialise une fiche destinée au dévelppeur. Au fur et à mesure des dévelppements celle-ci peut être enrichie par des descriptins de cntrôles u de tests spécifiques. Lrs de la réalisatin des tests unitaires, il s agira de déruler cette liste d'actins, de réaliser les actins et de les valider (OK u nn OK). Un "nn OK" (suvent nté KO) dit tujurs être justifié. Chaque analyste u chef de prjet respnsable d'une phase de recette se dit de réclamer l'ensemble des fiches de tests d'un prjet afin de cibler au mieux la phase de recette. C est ainsi que les fiches de test assurent un passage en recette dans les meilleures cnditins. Ces fiches s'inscrivent dans un bjectif de qualité. Elles divent être cnsidérées cmme un util et nn cmme une cntrainte. 24

26 Vici un exemple de frmalisme : Entête : Facturatin) Nm de l entité u des entités : nm du prgramme (u mdule) à tester (Ex : factures) Libellé : Résumé en une phrase ce que fait l bjet du prgramme (ex : éditin des Nm u cde du prjet : nm u cde du prjet à laquelle le cycle est rattaché Nm cllabrateur : Nm de la persnne qui test le prgramme Date : date à la quelle nt eu lieu les tests Crps de la fiche de test : Nm de l bjet Evénement Dérulement du test Résultats attendus OK/KO FAC001 Cnsultatin Rechercher la facture XXX Impressin facture OK facture Appuyer sur le butn XXX «Imprimer» Bas de page : Remarques :... 25

27 Les dnnées Afin de réaliser des tests unitaires, il est nécessaire d'élabrer au préalable des jeux de tests. Ces jeux de tests peuvent être : Les ressurces des dnnées fictives imaginées par le dévelppeur pur valider un ensemble de cas de tests, des dnnées de prductin : il s'agit de dnnées réelles (extraites de la prductin), des anciens jeux de tests. Les ressurces nus permettent de réaliser les tests. On peut s'inspirer : des dcuments de spécificatins, des spécificatins de tests (Scénaris, jeux de tests ), de la fiche de test initialisée par le chef de prjet, des tests précédents (suite à crrectin, test de nn régressin). La démarche Analyse statique La ntin d'analyse statique de prgrammes cuvre une variété de méthdes utilisées (nmbre «Cyclmatique», mesure de cmplexité Mc Cabe, mesure de Halstead, taux de cmmentaires...) pur btenir des infrmatins sur le cmprtement d'un prgramme lrs de sn exécutin sans réellement l'exécuter. C'est cette dernière restrictin qui distingue l'analyse statique des analyses dynamiques. Analyse dynamique Structurelle L'analyse dynamique structurelle cnsiste à vérifier la structure du cde ainsi que les variables. La vérificatin de la structure du cde crrespnd à une stratégie axée sur les flts de cntrôles qui cnsistent à parcurir tus les nœuds, tus les arcs et tus les chemins du cde. C'est de cette manière que l'n peut décuvrir qu'un test de type SI NON ALORS (IF..THEN..ELSE) n'est pas utilisé. La vérificatin des variables cnsiste à cntrôler leur affectatin, leur utilisatin dans des cnditins et dans les traitements (calculs...). 26

28 Analyse dynamique Fnctinnelle L'analyse dynamique fnctinnelle cnsiste à vérifier le service rendu et nn la façn dnt il est rendu. En d'autres termes, il s'agit ici de valider les règles de gestins énncées dans le cahier des charges. La difficulté de ce type de test réside dans le chix des dnnées de tests afin d'btenir les résultats attendus. Bîte nire Le test de la bîte nire est utilisé pur tester un prgramme en vérifiant que les srties btenues snt bien celles prévues pur des entrées dnnées. Ce fnctinnement interne est sit inaccessible (cas le plus fréquent), sit mis délibérément (c'est alrs un util thérique qui permet de chisir d'étudier exclusivement les échanges d entrée / srtie). Ce type de test est curamment utilisé dans les tests de nn régressin, les tests de rbustesse (fnctinnement en situatin extrême : débranchement d'un équipement...) et les tests de charge. Bîte blanche Le test de la bîte blanche permet de tester le cde. Le but est de valider qu il n y a pas de plantage. On ne teste plus le fnctinnel. Le but est de tester tus les chemins, tutes les branches et tutes les instructins cntenues dans le cde. 27

29 3 LES TESTS D INTEGRATION Définitin Après que les dévelppeurs (u chacune des équipes) aient validés leurs dévelppements, ils regrupent les différentes parties de prgramme à assembler. Ce regrupement, u intégratin, permet d'établir une nuvelle versin du prduit, suvent destinée à une livraisn. Les tests d'intégratin nt dnc pur but de valider le fait que tutes les parties dévelppées séparément fnctinnement ensemble, tant d'un pint de vue du fnctinnement que des aspects techniques de l'assemblage. La phase d'intégratin intervient après les tests unitaires des mdules. Les bjectifs Les bjectifs vnt dépendre de la phase du prjet. Le prjet est presque terminé : Le test d'intégratin aura pur but de vérifier la versin finale du prduit : vérifier que le lgiciel crrespnd aux attentes du client et répnd au cahier des charges. Il s agit d une Intégratin GLOBALE. Le prjet est en curs de dévelppement : Il s'agit de déplyer une nuvelle versin du lgiciel en y intégrant les crrectins, les nuvelles fnctinnalités Il s agit d une Intégratin INCREMENTALE. Dans les deux cas, il sera pprtun de valider les interfaçages de cmpsants et l'interactin matérielle. Les périmètres cuverts et exclus Le périmètre exclus : Cmme précisé précédemment, aucune vérificatin liée au fnctinnelle ne sera effectuée. Le périmètre cuvert : Livraisn des différents mdules u cmpsants. Vérificatin du fnctinnement des cmpsants. Vérificatin du dialgue entre les mdules (cmpatibilité, appel, passage de paramètres ). Prévisin et anticipatin d un retur à une versin antérieur en cas d incident. 28

30 Les méthdes Big Bang L intégratin «Big Bang» est aussi appelé nn-incrémentale (glbale). Le principe est d'intégrer tus les cmpsants en une seule étape. L'intégratin est certes rapide mais ne peux être envisagée que pur les petits prjets. Dans le cas de prjets imprtants, il y a trp de risques à implémenter un nmbre imprtant de cmpsants (détectin tardives des anmalies). De haut en bas (Tp dwn) Descendante L'apprche en Tp-dwn vient du fait que l'n dérule le prgramme de haut en bas : les mdules viennent s'empiler les uns aux autres. Des buchns snt utilisés pur simuler les traitements. Les buchns divent être vus cmme des prgrammes renvyant une u plusieurs valeurs. Les différents mdules divent être les plus petits pssible afin de cmprendre aisément leur rôle. Avantages : Détectin précce des défauts d'architecture. Facilité de cmpréhensin. Incnvénients : La créatin des buchns est cnsmmatrice de temps. L'effrt de simulatin des cmpsants absents cnstituent une surce d'erreurs. Tests tardifs des cuches basses. Unité testée Buchn de test Dépendance Simulée Dépendance Testée Surce : Réalisé par Eric LELEU pur illustratin 29

31 De Bas en Haut (Bttm up) Ascendante A l'inverse de l apprche tp-dwn, l'apprche bttm-up part du bas vers le haut : Nn pas que l'n démarre de la fin du prgramme mais plutôt des fnctinnalités qui snt cnsidérées cmme fndamentales. Elle nécessite dnc le fait de bien décmpser les fnctinnalités du prgramme et ainsi de définir celles qui sernt indispensables et priritaires aux autres. Le dévelppeur crée et utilise des buchns pur simuler des cmpsants nn dévelppés. Dans l apprche ascendante, les cmpsants de bas niveaux snt réalisés et dnc testés en premier. Avantages : Faible effrt de simulatin. Définitin des jeux d'essais plus facile. Les fnctinnalités basses snt plus suvent testées. Incnvénients : Détectin tardive des erreurs majeures. Unité testée Buchn de test Dépendance simulée Dépendance testée Surce : Réalisé par Eric LELEU pur illustratin 30

32 Mixte L'apprche mixte est une cmbinaisn des apprches ascendantes et descendantes. Il est parfis vu dans la littérature le cncept de bîtes grises. Avantages : Incnvénients : Le planning de dévelppement est géré de façn à intégrer les cmpsants dans l'rdre de créatin (cmparable à la méthde FiF First In / First Out). Prise en cmpte de la criticité des cmpsants : les cmpsants les plus critiques snt intégrés les premiers. Difficulté d'intégratin du à la mixité des méthdes (Cncilier les méthdes ascendantes et descendantes). Par paquet Cette apprche repse sur une décmpsitin du prgramme en fnctinnalités et/u par criticité (dépend de la taille du prgramme). Il est évident que l'n ne peut prcéder à ce type d'apprche qu'en présence de lgiciel permettant le décupage en mdules. 31

33 4 LES TESTS DE CHARGE Définitin du test de charge Les tests de charge cnsistent à expser une applicatin à des cnditins d'explitatin et d'utilisatin les plus prches de la réalité afin de valider le cmprtement du système. Les tests fnctinnels ne suffisent pas : l applicatin dit fnctinnellement répndre aux besins mais dit aussi être perfrmante (Temps de répnse ). Objectifs des tests de charge Les tests de charge permettent d'analyser tris aspects fndamentaux de la qualité de service d'une applicatin : La perfrmance (au travers essentiellement des temps de répnse) La mntée en charge (Maintient des fnctinnalités sus la charge, ) La fiabilité (Détectin des maillns faibles qu il s agisse de matériel u de lgiciel, valider les platefrmes, identifier les cntentins de base de dnnées u de réseau ) Types de tests de charge Il existe plusieurs types de tests de charges permettant d atteindre les bjectifs cités précédemment : Test de perfrmance : il s'agit d'un test au curs duquel n va mesurer les perfrmances de l'applicatin sumise à une charge d'utilisateurs. Les infrmatins recueillies cncernent les temps de répnse utilisateurs, les temps de répnse réseau et les temps de traitement d une requête sur le(s) serveur(s). Test de Dégradatins des Transactins : il s'agit d'un test technique primrdial au curs duquel n ne va simuler que l'activité transactinnelle d'un seul scénari fnctinnel parmi tus les scénarii du périmètre des tests, de manière à déterminer quelle charge limite simultanée le système est capable de supprter pur chaque scénari fnctinnel et d'isler éventuellement les transactins qui dégradent le plus l'ensemble du système. Test de stress : il s'agit d'un test au curs duquel n va simuler l'activité maximale attendue tus scénaris fnctinnels cnfndus en heures de pinte de l'applicatin, pur vir cmment le système réagit au maximum de l'activité attendue des utilisateurs. 32

34 Test d endurance, de rbustesse, de fiabilité : il s'agit de tests au curs duquel n va simuler une charge imprtante d'utilisateurs sur une durée relativement lngue, pur vir si le système testé est capable de supprter une activité intense sur une lngue péride sans dégradatins des perfrmances et des ressurces applicatives u système. Test de capacité, de mntée en charge : il s'agit d'un test au curs duquel n va simuler un nmbre d'utilisateurs sans cesse crissant de manière à déterminer quelle charge limite le système est capable de supprter. Il existe d'autres types de tests (test de tlérance aux pannes, tests de vlumétrie ), plus ciblés et fnctin des bjectifs à atteindre dans la campagne de tests. Étant entendu qu'en principe un type de test crrespnd à un type d'bjectif. La démarche (u la stratégie de cnduite des tests de charge) La démarche cnsiste à : Préparer les tests (dssier de test, étude de faisabilité technique) Créer les scripts (QUOI) Créer les scénaris (COMMENT) Exécuter les scénaris Analyser les résultats Amélirer le système (Tuning système) Rédiger un rapprt (précnisatins) La préparatin des tests crrespnd à la phase primrdiale. Elle cnsiste tut d abrd à réaliser un dssier de tests cmprenant : La descriptin de l applicatin Le descriptif des transactins QUOI Le descriptif des scripts Les scénaris Le planning COMMENT Le plan de charge Les bjectifs à atteindre POURQUOI La cnfiguratin Les jeux de dnnées. AVEC QUOI 33

35 La préparatin des tests a aussi pur but de réaliser une étude de faisabilité technique sur les utils et leur envirnnement : Tests manuels : nt cmme prblème majeur leur rganisatin qui est une pératin généralement inefficace en matière d'utilisatin du temps, des budgets et des ressurces. En utre les tests manuels ne permettent pas de générer des résultats prductibles, ne furnissent aucun niveau quantifiable de stress des applicatins et ne peuvent pas être crdnnés dans des cnditins satisfaisantes. Leur prcessus nn extensible ne permet pas d'intégrer des utils de lcalisatins de la cause surce d'un prblème de perfrmance. Applicatins dévelppées en interne : permettent de répndre au budget trp serré qui ne permet pas de recurir à une slutin extérieure trp cûteuse. Les prblèmes snt d'rdres différents : par exemple la cuverture applicative qui est suvent testé par des scripts très spécifiques à l'applicatin. Lrsqu'ils snt crrectement dévelppés, ces scripts permettent de tester la capacité de l'applicatin à gérer une actin dnnée mais pas de mesurer sa capacité à traiter un ensemble cmpsite de transactins. L'btentin de résultats explitables est quasiment impssible. Un autre suci avec ce type de tests est dnc la spécificité des utils. Ils ne peuvent pas être utilisés pur d'autres applicatins au prix de changement du script : le prcessus de crrectin des scripts initiaux pur répndre à un nuveau besin peut suvent s'avérer tut aussi lng que d'en dévelpper un nuveau en partant de zér. La dernière difficulté rencntrée est que ce type de scripts (suvent dévelppé par une seule persnne) snt assez peu explitables et cmpréhensibles par d'autres intervenants si le script n'est pas assez dcumenté (u pire si l'auteur quitte la sciété en milieu de prjet). Outils Open Surce : permettent de réaliser des tests élémentaires d'applicatins Web simples, des fnctinnalités essentielles leur fnt encre défaut pur tester des applicatins critiques. Pur tester des applicatins critiques, l'absence de supprt des technlgies autres que Web/HTTP rend leur utilisatin impssible. En effet, beaucup de ces utils snt incapables de mener des tests anticipés de mntée en charge des cmpsants des implémentatins de middleware u de base de dnnées. De plus en raisn de l'absence d'api de haut niveau, les scripts nt tendance à devenir extrêmement lngs et d'autant plus difficiles à maintenir. La plus part des utils Open surces snt basés sur la technlgie JAVA. Ces limitatins nt suvent pur cnséquence de multiplier les cûts matériels/ressurces requis pur maintenir plusieurs machines de test de charge. Les utils Open Surce snt généralement des slutins pnctuelles et ne prpsant aucune intégratin avec d'autres utils gérant les tests fnctinnels et de régressin. Framewrk de tests intégrés aux EDI : snt des utils nés d'une nuvelle tendance de l'industrie du dévelppement lgiciel. Ces utils cnsistent à cncevir des EDI très imprtants intégrant également des fnctins de test. Par exemple Micrsft Visual Studi Team System pur l'univers.net est le plus révélateur. L'avantage de ce type de slutin est de prmuvir un dévelppement rienté sur les tests, n'exigeant pas de maitriser plusieurs utils et permettant de tester l'applicatin dans un envirnnement familier. Cet avantage majeur est aussi le plus grs incnvénient puisqu'il prpse une vue entièrement turnée sur le dévelppement, suppsant que les dévelppeurs réalisent tutes les activités (c'est à dire le cdage, les tests unitaires, les tests de charge et de prductin). Ces utils ne prennent en charge que leur prpre envirnnement, ils ne prpsent que des fnctins très rudimentaires pur tester la charge des applicatins Web et ne supprtent pas d'autres envirnnements de 34

36 dévelppement. Elles se révèlent efficaces aux petits prjets mais insuffisantes pur tester des applicatins stratégiques cmplexes. De plus, aucun de ces Framewrks ne cuvre tus les aspects des tests fnctinnels aux tests de perfrmance. Outils dédiés au Web : utilisent tus la même apprche qui est de pilter Internet Explrer pur lui faire réaliser des scripts de tests en tant qu'utilisateur virtuel. Ces utils snt précis u extensibles mais pas les deux à la fis en raisn de leurs limitatins techniques. Ce n'est dnc pas la slutin idéale pur cnstruire des tests de charges. Pur prgresser en extensibilité, il est nécessaire de réduire la cnsmmatin de ressurces par utilisateurs virtuel. Cependant la précisin d'une telle apprche est discutable dans la mesure ù elle blige tus les utilisateurs virtuels à partager des pls cmmuns de ressurces, ce qui n'est pas une représentatin réaliste d'un cntexte de prductin. Les utils dédiés aux tests de charge Web fnctinnent exclusivement avec internet Explrer et les autres navigateurs ne snt abslument pas pris en charge. L'un des principaux incnvénients de ce type d'util réside dans les limites des fnctinnalités de leur langage de script. Ils ignrent les principes élémentaires de tut langage de prgrammatin. La réalisatin de scripts pur d'autres prjets est dnc très difficile vir impssible. Service de tests hébergés : snt généralement réalisés depuis un service Internet distant. Cette apprche ne nécessite aucun matériel, lgiciel ni expertise du cté client et peut présenter des avantages pur décuvrir les premiers bénéfices de tests de mntées en charges. Le seul incnvénient est que les tests divent être réalisés de façn régulière tut au lng du cycle de dévelppement (aussi bien de façn méthdes que dans sa glbalité). Certains cmpsants applicatifs ne snt pas accessibles sur les réseaux publics et leur test avec une slutin hébergée devient difficile. Le cmprtement d'internet étant largement imprévisible, ces tests hébergés ne snt pas reprductibles. Ils snt dnc utiles pur tester un cncept et divent être réalisés suffisamment tôt. Platefrmes d'entreprise : snt les seules qui répndent à l'intégralité des besins de test de charge. Ces slutins snt suffisamment extensibles pur tester des envirnnements applicatifs hétérgènes pur un cût raisnnable. En assurant également les tests de stress des cmpsants, elles permettent de détecter les enjeux de perfrmance en amnt du cycle. Leur capacité à cntrôler intégralement les flux d'activité des utilisateurs virtuels et un langage de script avancé et flexible permettent de facilement réutiliser les scripts dans différents scénaris d'utilisatin. Des API de haut niveau pur les envirnnements applicatifs supprtés simplifient grandement la maintenance des scripts de tests. Des utils de «reprting» permettent également d'analyser rapidement les résultats des tests de charge à travers des utils de diagnstic lcalisant la cause surce des éventuels prblèmes pur en accélérer la réslutin. La prblématique qualité est traitée dans une apprche glbale. Des éditeurs prpsent généralement des prestatins de supprt, de frmatins pur garantir une implémentatin ptimisée et réussie. Il existe bien entendue de ntables différences entre les différentes ffres du marché mais elles snt dans tus les cas bien plus perfrmantes que les différentes alternatives que nus avns vu précédemment évquées. 35

37 Quand mener les tests de charge Plus les tests de charge débutent tôt dans le prcessus de dévelppement, plus ils permettent de mettre rapidement en évidence les pssibles défauts du lgiciel u de sn infrastructure sus-jacente. Si l'n sait que le cût des crrectins des défauts nn décuverts prgresse expnentiellement à chaque phase suivante du cycle de dévelppement, il n'en est que plus essentiel de débuter les tests de mntée en charge le plus tôt pssible. Cmpte tenu de la structure multi-niveau des applicatins existantes, les différentes phases du prcessus de dévelppement nt été synthétisées dans la figure ci dessus avec les tests crrespndants à chaque phase. Phases au curs desquelles des activités de test de charge peuvent être intégrés Surce : Livre Blanc «Chisir une stratégie de test de mntée en charge» de Brland Pur les tests de cmpsants, n prcède à des tests de stress qui permettent de lcaliser simplement et écnmiquement les prblèmes ptentiels tels que les situatins d'inter-blcage (deadlck), les prblèmes de synchrnisatin, des fuites mémires, des enjeux de perfrmance... Le diagnstic de ces prblèmes immédiatement avant le dépliement avec une slutin classique de test de «but en but» est généralement trp cmplexe, et dans tus les cas, leur réslutin est infiniment plus cûteuse que s'ils avaient été détectés en amnt. Cette phase de test est unique dans la mesure ù elle est généralement réalisée avant qu'il n'existe de véritables clients permettant d'enregistrer un script de test; ces derniers divent dnc être réutilisés (en tests unitaires) u dévelppés manuellement. 36

38 Pur les tests de charge de l'infrastructure (u benchmark), les décisins cncernant celle ci snt généralement prise assez tôt. Cependant, l'infrastructure retenue peut intégrer un système d'équilibrage de charge, des serveurs d'applicatins, des serveurs web..., juera un rôle clé dans la perfrmance de l'applicatin. Les résultats fficiels aux benchmarks standard ne snt généralement pas d'une grande aide et ne peuvent pas prendre en cmpte l'architecture cmplète de l'applicatin. Une bnne cmpréhensin des effets des différents paramètres de cnfiguratin système permet de dispser suffisamment tôt de dnnées utiles pur l'ptimisatin ultérieure des perfrmances. La cnnaissance des indicateurs clés de perfrmance furnit un benchmark significatif pur les tests ultérieurs de mntée en charge de but en but et de mnitring applicatif. En réalisant assez tôt les tests de charge de l'infrastructure, il est pssible de vérifier que les cmpsants résidant dans les différentes cuches cllabrent cmme prévu. L'utilisatin d'un prttype «tus niveaux» incluant un sus ensemble de la fnctinnalité cmplète tuchant tus les niveaux de l'architecture permet de réaliser les tests suffisamment tôt dans le prcessus de dévelppement pur détecter rapidement les ptentiels défauts de cnceptin. Il est également pssible d'évaluer différentes alternatives de cnceptin cmme la distributin et la réplicatin des cuches de présentatin/métier/dnnées. Les tests de charge de but en but permettent d'analyser le fnctinnement de l'ensemble de l'applicatin dans différents scénaris réalistes d'utilisatin et de charge. Ils peuvent durer quelques heures u plusieurs jurs. Ces tests snt généralement cnduits dans un envirnnement tempraire de pré prductin et leurs résultats permettent de répndre aux questins suivantes : Des erreurs se prduisent-elles dans des cnditins particulières de charge? Quelle est la capacité système requise pur les cuches de l'applicatin? L'applicatin purra-t-elle satisfaire les niveaux de services requis? L'applicatin est elle ptimisée pur ffrir les meilleurs perfrmances? Les activités de réslutin des erreurs, d'ptimisatin et de réglage u l'intrductin de nuvelles fnctinnalités nt elles eu des effets négatifs sur les perfrmances? L'applicatin est elle prête pur un dépliement intégral? 37

39 5 LES TESTS DE VALIDATION PREAMBULE Les tests de validatin nt pur bjectif de vérifier que tutes les exigences du cahier des charges sient respectées. Ces tests snt effectués immédiatement après les tests d'intégratin. Il existe deux stratégies u apprches pur les tests de validatin : - La première cnsiste à identifier tutes les fnctins du lgiciel et de les tester de façn séquentielle. - La deuxième apprche est de tester les caractéristiques du lgiciel (interface, ergnmie, perfrmance ). Dans la pratique, les deux snt utilisés. Les tests de validatin fnt partie de la stratégie de tests (Stratégie de tests). A ce titre, l'rganisatin de la recette dit respecter les cnsignes décrites dans le dssier de stratégie de tests, à savir : - Vérificatin et respect du périmètre défini. - Validatin de tutes les fnctinnalités inventriées. - Utilisatin des jeux de tests définis (idéalement, le jeu d'essai dit être le plus prche pssible de la réalité. Dans la plupart des cas, n prendra des dnnées réelles) et de la platefrme de recette assciée. La platefrme de test dit être la plus prche pssible de celle ù sera déplyé le lgiciel. - Exécutin de l'ensemble des scénaris élabrés. - Suivi et synthèse des fiches de recettes

40 LES PRINCIPALES TECHNIQUES DE VALIDATION APPROCHE FONCTIONNELLE (BOITE NOIRE) Les tests fnctinnels ne permettent pas d'accéder au cde surce. Il est dnc plus difficile par ces techniques de détecter des défauts du lgiciel. APPROCHE FONCTIONNELLE CLASSIQUE L'apprche fnctinnelle classique a pur bjectif de tester que le lgiciel fait effectivement ce qu'il est censé faire. Cette apprche teste chacune des fnctins que le cmpsant accmplie (Règles de gestin précisée dans la dcumentatin de spécificatins u le cahier des charges) sans se sucier de la structure interne du prgramme. Cette apprche se fait dnc en «bîte nire». C'est l'apprche privilégiée à ce jur. ANALYSE PARTITIONNELLE L'analyse partitinnelle se base sur le dmaine de variatin des dnnées en entrée du cmpsant lgiciel. Dans la pratique, n segmente les cas fnctinnels (réalisatin de partitins) en suppsant que tus les cas d'un segment se cmprtent cmme les autres. Ainsi, si un test est validé pur un cas «A» appartenant à un ensemble, il sera valable pur tutes les classes de dnnées équivalentes du même ensemble. On chisira une dnnée de test égale au mins à un chix quelcnque d'un représentant de chaque classe. Cmprtement 1 1 Valeur Cmprtement 1 Cmprtement 2 Ensemble de tutes les valeurs pssibles Surce : Réalisé par Eric LELEU pur illustratin 1 Valeur limite 1 Valeur Cmprtement 2 39

41 Exemple : Sit la fnctin qui calcule les frais de prt : frais de 10 si mntant d achat inférieur à 100 (n suppse qu un mntant d achat ne peut pas être négatif). Il existe 2 cmprtements : le mntant d achat peut être inférieur u supérieur à 100. Il est incncevable de tester tutes les valeurs pssibles. Il cnvient de chisir une valeur dans chacun des deux dmaines de cmprtement : par exemple 15 et 110 d achat. Ne pas ublier de tester les valeurs limites : 100 dans ntre cas! TESTS AUX LIMITES L'expérience pruve que les erreurs se situent très suvent à la frntière de cmprtements différents («les bugs se cachent dans les cins»). Ces tests aux limites snt suvent utilisés avec la technique de partitinnement : les valeurs aux limites peuvent être des valeurs aux frntières des partitins. Exemple de bugs aux limites : - L'indice de tableau est dépassé. - Une cmparaisn stricte au lieu d'une avec égalité. - Oublie de traitement du premier u du dernier recrd d'un fichier. Exemple : En général, pur un paramètre appartenant à un intervalle, il y a génératin de 6 dnnées de test. Pur tester si P est cmpris entre [0,100], nus sélectinnerns six valeurs (dnnées de test) de manière à tester chacune des brnes (limites) : -1, 0, 1, 99, 100,

42 TESTS COMBINATOIRES (PAIRWISE) L'apprche Pairwise fait que l'n sélectinne les dnnées de test pur cuvrir tutes les paires de valeurs. Ceci sur la cnstatatin qu'un seul test cuvre plusieurs paires et qu'il y a beaucup plus de cmbinaisns que de paires. Le défaut de cette technique est qu'il n'y a aucune chance de détecter les erreurs demandant des cmbinaisns de deux valeurs et plus. Exemple 1 : imaginns une bîte de dialgue cmpsée de 4 listes avec 3 valeurs pssibles. Il existe dnc 81 cmbinaisns pssibles (3 4 ). En réalité, dans l'apprche PairWise seul 9 cas (u paires) sernt testés : Chacune des valeurs de la première liste cmbinée avec une seule valeur de chacune des autres listes. Exemple 2 : imaginns 3 variables bléennes A, B, C. Le nmbre de cmbinaisns de valeurs / tests : 2 3 = 8. Le Nmbre de paires de valeurs : 12. (A=1, B=1), (A=1, B=0), (A=1, C=1), (A=1, C=0) (A=0, B=1), (A=0, B=0), (A=0, C=1), (A=0, C=0) (B=1, C=1), (B=1, C=0) (B=0, C=1), (B=0, C=0) La dnnée de test (A=1, B=1, C=1) cuvre 3 paires : (A=1,B=1),(A=1,C=1),(B=1,C=1) La dnnée de test (A=0, B=0, C=0) cuvre 3 paires : (A=0,B=0),(A=0,C=0),(B=0,C=0) La dnnée de test (A=1, B=0, C=0) cuvre 2 paires : (A=1,B=0),(A=1,C=0) La dnnée de test (A=0, B=1, C=1) cuvre 2 paires : (A=0,B=1),(A=0,C=1) Reste deux cas dispnibles (B=1, C=0) et (B=0,C=1). Ici 6 tests snt nécessaires pur cuvrir l ensemble des cas. 41

43 TESTS SYNTAXIQUES Cette technique de test est peu utilisée. Elle peut cependant se révéler utile pur des applicatins qui nécessitent des dnnées d'entrée respectant une syntaxe rigide et bien définie. C'est le cas des applicatins qui autrisent un lancement direct par ligne de cmmande (Exemple : l utilitaire d archivage Winzip). Afin de réaliser les tests, il cnvient : - De définir la grammaire (la syntaxe de la ligne de cmmande). - De cnstruire un arbre répertriant l'ensemble des cas pssibles. - De cnstruire les jeux de tests nécessaires à partir de cet arbre. Le but est de cuvrir tus les nœuds (qu'ils sient terminaux u nn). Lgiciel Archivage Créer une archive Ajuter fichier(s) à une archive existante 1 Fichier Plusieurs Fichiers 1 Fichier Plusieurs Fichiers Surce : Réalisé par Eric LELEU pur illustratin 42

44 TESTS ALEATOIRES Les tests aléatires se différencient des autres tests par leur apprche prbabiliste. En effet, les jeux de tests snt réalisés de manière autmatique et aléatire par un prduit lgiciel. L'avantage est que l'n atteint rapidement 50% de l'bjectif des tests. Cependant, ces tests nt tendance à plafnner ensuite car il est impssible de générer un ensemble de dnnées aléatires ttalement chérent. Satisfactin Test Déterministe Test Aléatire Effrt Surce : Réalisé par Eric LELEU pur illustratin 43

45 COUVERTURE GRAPHE FONCTIONNEL La cuverture du graphe fnctinnel est cmme sn nm l'indique le parcurs cmplet de tus les nœuds, de tus les arcs, de tus les chemins. Tus les éléments de l'arbrescence du prgramme divent être exécutés au mins une fis. C'est une technique qui est très utile pur les tests IHM (Interface Hmme Machine) mais sa mdélisatin est très vite cmplexe. Surce : Curs Test et validatin CNAM 44

46 GRAPHES CAUSE-EFFET Cette méthde, cncept élabré par G.J. Myers, relie les effets d'un prgramme (les srties) aux causes (entrées). Les causes snt des entrées pssibles (variables d'entrée, actins utilisateurs etc.) et les effets snt les srties du système (variable de retur, mdificatin de la base de dnnées etc.). Il faut dnc identifier les causes et les effets du système à partir des spécificatins puis élabrer un graphe de cause à effet. L'élabratin de ce graphe est l'étape la plus difficile : une mauvaise interprétatin aurait des cnséquences directes sur les cas à tester. On cherchera si pssible à réduire u à simplifier ce graphe de cause à effet. On purra ainsi générer les dnnées de tests pur le cuvrir. Exemple de représentatin : A1 A2 B1 A3 B2 C1 B3 Surce : Réalisé par Eric LELEU pur illustratin «C1» dépend de «B2», de «B3» mais aussi de «A1», «A2» et «A3». Le nmbre de dnnées de test augmente très rapidement (il est utile d utiliser un tableau de vérité pur représenter et tenter de simplifier les cas à tester)! 45

47 APPROCHE STRUCTURELLE (BOITE BLANCHE) Les tests «bite blanche» snt utilisés lrsque les jeux d'essais dépendent de l'analyse du cde surce. Pur chacun de ces types de tests, n aura deux apprches : - L'apprche statique. - L'apprche dynamique. L'apprche statique ne prévit pas d exécutin de cde. On passe en revue le cde, n estime la cmplexité de celui-ci. L'exécutin reste symblique et l'interprétatin abstraite : On s attarde sur la structure du prgramme. L'apprche dynamique est de prduire un jeu de dnnées de tests en fnctin du cde surce. Ces dnnées exécuternt un ensemble de cmprtements et de résultats qui sernt cmparés avec ceux du cahier des charges. Cette apprche est limitée par l'exécutin partielle du prgramme et de sn cmprtement. L apprche structurelle permet la détectin d'erreurs indépendantes de l'applicatin et d avir une vue glbales des algrithmes. Les tests structurels fnt une utilisatin imprtante de la thérie des graphes. Elle reste cependant limitée du fait de la nn exécutin réelle du prgramme et dnc le fait que l'n ne test pas les fnctinnalités. LES TESTS STRUCTURELS STATIQUES - Revue de cdes Une revue de cde cnsiste en un examen détaillé d une spécificatin, d une cnceptin par une persnne u un grupe de persnnes, afin de déceler des fautes, des vilatins de nrmes de dévelppement u d autres prblèmes. Il s agit d une TECHNIQUE DE CONTROLE plutôt que de test. Exemple de cntrôle : Taux de cmmentaires Intérêt des cmmentaires Variables nn initialisées Gestin des indices de tableau Cnversin de types Divisin par zér Terminaisn des bucles Srtie d une prcédure u fnctin 46

48 - Estimatin de la cmplexité Statistiquement, la cmplexité d un prgramme est crrélée avec le nmbre de ses défauts : en d autres termes, plus un prgramme cmprte de lignes, plus il a de purcentage d erreurs. Il existe plusieurs façns d appréhender cette ntin de cmplexité. Les métriques d HALSTEAD Les métriques d HALSTEAD évaluent la cmplexité liée à la distributin des variables et des instructins. La base des mesures est furnie par le vcabulaire utilisé : les pérateurs et les pérandes. Frmulatin : n1 = nmbre d pérateurs uniques n2 = nmbre d pérandes uniques (termes, cnstantes, variables) N1 = nmbre ttal d apparitin des pérateurs N2 = nmbre ttal d apparitin des pérandes l = n1 + n2 L = N1 + N2 Taille estimée du prgramme = n1(lg2 n1) + n2(lg2 n2) Vlume du prgramme = L Lg2 (n1 + n2) Difficulté du prgramme = (n1/2) (N2/2) Nmbre d erreurs = Vlume du prgramme / 3000 Les métriques de Mc CABE Mac CABE étudie le lgiciel en analysant le graphe de cntrôle du prgramme et calcule la cmplexité structurelle u nmbre cyclmatique de ce graphe. Le nmbre cyclmatique dnne une évaluatin du nmbre de chemins indépendants dans le graphe et dnc une indicatin sur le nmbre de tests nécessaires. Cette mesure indique la brne supérieure du nmbre de tests à effectuer pur que tus les arcs sient cuverts au mins une fis. Dans la pratique, n admet que la limite supérieure du nmbre cyclmatique sit de 30. Cette valeur est définie cmme un critère de qualité dans le plan qualité (PAQ). 47

49 Frmulatin : n = nmbre de nœuds (blcs d instructins séquentielles) e = nmbre d arcs (branches suivies par le prgramme) v = nmbre cyclmatique Dans le cas d une entrée et d une srtie v = e-n+2 Dans le cas de «i» pints d entrée et de «s» pints de srtie v = e-n+i+s Exemple : Vici un exemple simplifié d un graphe de flt de cntrôle. A B C D E F Surce : Réalisé par Eric LELEU pur illustratin En thérie, il existe 4 cas pur tester l ensemble des slutins : ABCDF, ABCEF, ACDF et ACEF. Or seln Mc CABE, il existe 3 chemins : V=7 arcs 6 nœuds + 2 = 3 En effet, un seul des 2 cas sera utile parmi ACDF et ACEF (AC, CDF et/u CEF ayant déjà été parcurus). 48

50 LES TESTS STRUCTURELS DYNAMIQUES Les tests structurels snt basés sur le graphe de flt de cntrôle (cuverture de tutes les nœuds-instructins, de tutes les branches, de tus les chemins). L bjectif est de prduire les dnnées de test qui exécuternt un certain ensemble de cmprtements du prgramme (chemin dans le graphe de cntrôle). Exemple : Vici un exemple simplifié d un graphe de flt de cntrôle. A B C D E F Surce : Réalisé par Eric LELEU pur illustratin En thérie, il existe 4 cas pur tester l ensemble des slutins : ABCDF, ABCEF, ACDF et ACEF. 49

51 IV LES TESTS ET LA QUALITE Le cût des tests est évalué lrs de l estimatin du prjet glbal et est suvent sus estimé par rapprt à l rganisatin mis en place sur le prjet. En cnséquence les prjets dépassent le budget en ce qui cncerne les cûts et la durée (les deux étant plus u mins liés). Des enquêtes nt été effectuées et révèlent une tendance par rapprt aux différentes phases d un prjet. En exemple aux USA en 1986 une étude menée auprès de 55 entreprises révèle que 53% du budget ttal d'un lgiciel est affecté à la maintenance. Ce cût est réparti cmme suit : 34% maintenance évlutive : mdificatin des spécificatins initiales ; 10% maintenance adaptative : nuvel envirnnement, nuveaux utilisateurs ; 17% maintenance crrective : crrectin des bgues ; 16% maintenance perfective : amélirer les perfrmances sans changer les spécificatins ; 6% assistance aux utilisateurs ; 6% cntrôle qualité ; 7% rganisatin/suivi ; 4% divers. On s aperçit que le cût des crrectins de bug se situe en secnd psitin après la maintenance évlutive et quel représente une part nn négligeable du budget d un lgiciel. Pur faciliter et fiabiliser l estimatin des prjets des méthdlgies nt été dévelppés pur évaluer la cmplexité de l envirnnement et du lgiciel. C est le cas du mdèle COCOMO pur COnstructive COst Mdel estime qu un prjet est réparti cmme suit : 15 à 20% prgrammatin 40% spécificatin et cnceptin 40% validatin et vérificatin Ce n est pas cmme il est suvent cnstaté la prgrammatin qui requière le plus d énergie mais bien la définitin du prduit et sn cntrôle. Cette méthde définit des métriques et des règles afin d évaluer de manière plus fiable le cût d un lgiciel. Nus cnstatns que l estimatin d un lgiciel et tut aussi difficile que celle de le tester et nécessite tut cmme les tests des méthdes et des utils lgiciels permettant d aider à la décisin finale. Ceci s'explique par l'augmentatin de la cmplexité des lgiciels avec la mntée en puissance des perfrmances du matériel. 50

52 LES CONSEQUENCES DE CET ETAT DE FAIT Face au bug le client a un chix restreint d actin seln la prvenance du bug : matériel, lgiciel, perfrmance Il peut faire appel à sn service infrmatique u à la sciété éditrice de lgiciel u la sciété de service. Dans le cas d un cntrat, une questin se pse immédiatement qui va supprter le cût de crrectin de l anmalie? La législatin est peu dévelppée sur le sujet. C est le cntenu du cntrat qui fait frce le li. LES EDITEURS Les éditeurs furnissent des lgiciels dnt ils nt définies les fnctinnalités au préalable qui s avèrent figés dans le temps jusqu à la versin suivante. L achat dit dnc se faire en cnnaissant les limites du prduit tant fnctinnel qu au niveau fiabilité. Le furnisseur délivre dans ce cas une licence qui dnne le drit d utiliser le prduit en l état. Il se décharge de tutes respnsabilités liées à l utilisatin de sn prduit et de ces cnséquences. L éditeur n ayant pas cnnaissant du cntexte de dépliement de sn prduit. Exemple de garanties et respnsabilité des éditeurs : «Le lgiciel» et la dcumentatin qui l accmpagne snt furnis dans l état ù ils se truvent et sans aucune garantie. En cas de supprt défectueux, un autre exemplaire sera délivré par «la sciété» sur demande. «La sciété» décline tute respnsabilité déculant d un dmmage direct u indirect en relatin avec l utilisatin u l impssibilité d utilisatin de «le lgiciel», y cmpris les dmmages entraînés par la perte de bénéfices, l interruptin des activités, la perte d infrmatins et autres, et ce même si «la sciété» a été infrmé de la survenance u de l éventualité de tels dmmages. Cmme l acheteur n achète pas le lgiciel, mais une licence d utilisatin, l éditeur retire sa respnsabilité sur sn explitatin. 51

53 LES SOCIETES DE SERVICES Le cas d une sciété de service d ingénierie infrmatique est différent puisqu elle ffre un service à sn client de type clé en main. Elle est pur des raisns marketing, stratégique et écnmique dans le devir de furnir une prestatin qui répnd aux besins du client. Elle a cnnaissance du cntexte de dépliement du prduit puisque c est l une des cntraintes incnturnables pur répndre au mieux à la définitin des besins élabrés par le client. Elle ne peut dnc pas, cmme l éditeur, se décharger de sa respnsabilité de qualité du prduit mais aussi de qualité de la répnse dnnée au cahier des charges émis par sn client. Elle va dnc émettre un cntrat allant dans ce sens et définissant les actes auxquels elle s engage ainsi que les limites de sa prestatin. Elle va dnc par ce cntrat se prtéger face aux exigences évlutives du client mais aussi permettre au client d exiger la prestatin et la qualité qu elle met en avant. Le client va dnc s appuyer sur une nrme u des méthdlgies, nus prendrns pur exemple la nrme ISO9000. Le but de cette nrme est de dnner au client une garantie sur le prduit u le service ffert par sn furnisseur et d avir un recurs en cas de litige. Elle définit tus les états du prcessus de cnceptin mais aussi l assurance que l entreprise répnd à une plitique qualité en ce qui cncerne sn rganisatin. Deux parties snt dnc définies : le prduit fabriqué. l'rganisatin et le management. Cette nrme définie une qualité de travail, une méthde, une traçabilité ainsi que des métriques permettant de mesurer la qualité de la prestatin fferte et les actins a mener au niveau des deux partenaires pur atteindre le niveau de satisfactin prpsé à la signature du cntrat. Le client purra également s appuyer sur un autre le PAQ : Plan d Assurance Qualité furni par le prestataire. Ce PAQ définit précisément le périmètre d interventin du furnisseur et leurs délais mais aussi les bligatins et les devirs de chaque partenaire et les limites de l interventin de l une u l autre des parties. Et permet dnc de justifier les surcûts u les actins à mener pur les éviter. La sciété de service peut par exemple furnir une prestatin supplémentaire d accmpagnement à l élabratin d une plate-frme de tests client u au dépliement et frmatin des utilisateurs du client dans les cas les plus cmplexe u si le client ne l a pas insérer dans sn cntrat. Certains PAQ définissent des métriques sur la base des quels le client peut exiger en accrd avec sn furnisseur de définir des pénalités en cas de dépassement de seuils préalablement définis. 52

54 EXEMPLE: INDICATEURS QUALITE Indicateur RDL RESPECT DES DELAIS DE LIVRAISON DES LIVRABLES Objectif Respecter les délais de livraisn des livrables (dcumentaires, lgiciels). Mde de calcul RDL Ecart dates réelles / prévues dit être inférieur u égal à 5j Actin Analyse des causes et actins crrectives Pénalité Indicateur RCM RESPECT DES CONTRAINTES ET DES METHODES Objectif Respecter les méthdes et utils de gestin de prjet du lgiciel de dévelppement utilisé et les cntraintes du prduit Mde de calcul RCM - Pur chaque thème, respect O/N Actin Prise en cmpte des remarques par les Prestataires, avec crrectin sus un délai de 5 jurs Pénalité Indicateur RDC RESPECT DES DELAIS DE CORRECTION Objectif Respecter les délais de crrectin des anmalies lgicielles Mde de calcul Actin Pénalité RDC - Anmalie blquante crrigée sus 24h, les autres types d anmalies sus 48h Analyse des causes et actins crrectives 53

55 La négciatin et la mise au pint du cntrat est, cmme n vient de le vir, primrdiale et nécessite de passer un temps imprtant pur le bn dérulement du prjet. Dans cette exemple la mise en œuvre des pénalités applicables par le maître d œuvre dans le cas de nn respect des facteurs qualité, dans le cas ù le Prestataire est seul respnsable, reste à préciser par rapprt au cntrat négcié. L ensemble des 5 critères suivant dnne l assurance qualité : la cnfiance du client, répndre exactement à ses besins et attentes, amélirer la perfrmance, btentin d une meilleure rentabilité de l'entreprise Amélirer l'accès au marché. La nrme ISO définit la qualité cmme étant les exigences du client en terme de service et de nrmes de prduit. Elle incite dnc les entreprises à répndre aux exigences du client pur btenir cette certificatin. Elle représente un gage de qualité bligatire et une méthdlgie de l rganisatin auquel tendent tutes les sciétés cmmerciales et industrielles. Cette certificatin ISO 9000 est btenue, par une entreprise, si elle répnd aux 20 cnditins suivantes : Respnsabilité de la directin Système Qualité Revue de cntrat Maîtrise de la cnceptin Maîtrise des dcuments Achats Maîtrise du prduit furni par le client Identificatin et traçabilité Maîtrise du prcessus Cntrôle et essais Maîtrise des équipements de cntrôle, de mesure et d'essai Etat des cntrôles et essais Maîtrise du prduit nn cnfrme Actins crrectives et préventives Manutentin, stckage,... Enregistrements relatifs à: la qualité Audits qualité internes Frmatin Prestatins assciées Techniques statistiques Ces 20 cnditins mntrent l impact psychlgique et la qualité du travail qu est en drit d attendre le client. Il démntre le degré d rganisatin d une entreprise certifié. D autres méthdlgies snt aujurd hui utilisées pur atteindre le zér défaut : CMMI, ITIL. 54

56 Le but de ce dssier n est pas de décrire ces différentes méthdes u nrmes. Ce paragraphe mntre l imprtance des tests et des utils qui les accmpagnes face aux exigences du client qui utilise ces méthdes u ces nrmes pur btenir ce qui lui est dû. La nrme ISO9000 et les méthdes CMMI u ITIL snt les mteurs de la qualité et incitent à cntrôler, à tester. L envirnnement de plus en plus cmplexe du système d infrmatin cntribue à chercher des slutins pur augmenter la qualité, la fiabilité et la rbustesse du système d infrmatin. Elles nt dnc cntribuées aux dévelppements des utils de tests. 55

57 V LES OUTILS DE TEST Les utils de tests que l n truve sur le marché peuvent être classés en cinq grupes : Le premier cncerne les utils d aide à la réalisatin des tests. Capture et ré exécutin des scripts réalisés via une IHM. Sauvegarde des tests et des résultats assciés. Génératin de scripts de tests en fnctin des langages et des platefrmes Le secnd grupe cncerne les utils de campagne de tests. Les utils de gestin des plans et campagnes de test servent à définir, rganiser et cnduire les campagnes de tests. Ils divent dnc s'interfacer avec tus les utils qui interviennent dans les tests. Le trisième grupe cncerne les tests fnctinnels (bite nire). Les tests cncernent l'analyse des spécificatins du lgiciel, sans tenir cmpte du cde surce. Le périmètre des cntrôles englbe les interfaces utilisateurs, les API, la gestin des bases de dnnées, la sécurité et le réseau. Il vérifie la cnfrmité du fnctinnement d un système vis-à-vis des exigences de l utilisateur (se réfère au cahier des charges). Le quatrième grupe cncerne les tests structurels (bite blanche). Ces utils permettent de valider ce que fait le lgiciel testé. Ils snt dnc cmplémentaires aux utils de tests fnctinnels qui vérifient, eux, ce que dit faire le lgiciel. Ces purqui des éditeurs nt créé des suites cmprenant ces deux types de tests. Le cinquième grupe cncerne la perfrmance des lgiciels dévelppés, quelque sit l envirnnement : applicatins Web, intranet u des Web services. LES OUTILS D AIDE A LA REALISATION DES TESTS Appelés "autmates de tests", ces utils présentent des fnctinnalités cmmunes : Capture et ré exécutin des scripts réalisés via une IHM (=Interface hmme machine). Sauvegarde des tests et des résultats assciés. Génératin de scripts de tests en fnctin des langages et des platefrmes. 56

58 MERCURY WINRUNNER ET QUICKTEST PRO DE MERCURY QUALITY CENTER Mercury Quality Center furnit un ensemble d'utils Web permettant de gérer et d'autmatiser les tests de qualité lgicielle dans un large éventail d'envirnnements applicatifs. Mercury Quality Center cmprend des prduits leaders tels que Mercury TestDirectr, Mercury QuickTest Prfessinal et Mercury WinRunner. WinRunner et QuickTest Prfessinal snt des autmates de nuvelle génératin. Cette suite permet de créer un ensemble de tests, de le gérer en testant l'applicatin tut au lng du cycle de dévelppement et de crdnner les résultats. Pur définir un test, Mercury WinRunner enregistre simplement les actins de l'utilisateur sur l'interface du prgramme à traiter (prcessus métier type : cmmande d'un article saisi d'un client...). Les scripts générés peuvent être mdifiés pur répndre aux besins de tests les plus cmplexes. Ensuite, les testeurs peuvent ajuter des pints de cntrôle, qui cmparent les résultats attendus et réels btenus lrs de l'exécutin du test. Il est même pssible de vérifier les valeurs des bases de dnnées afin de garantir la précisin des transactins et l'intégrité des bases de dnnées, en mettant en évidence les enregistrements qui nt été mis à jur, mdifiés, supprimés et insérés. Lrs de l'exécutin des tests, Mercury WinRunner fait fnctinner l'applicatin autmatiquement, simulant un utilisateur réel exécutant chaque étape du prcessus métier. Cet util fnctinne exclusivement sur platefrme Micrsft Windws. Purqui deux versins d'un même type d'util chez le même editeur? WinRunner existe depuis La premiere versin de QuickTest Pr date de Ce dernier a été réalisé cmme la suite lgique du premier englbant ses fnctinnalités et rajutant les siennes. A la base QuickTest Pr avait été crée parce que WinRunner gérait les envirnnements Web. WinRunner a fndamentalement été supplanté par QuickTest Pr. WinRunner est plus cmplexe à mettre en euvre, sn langage de script (TSL) est prpriétaire. QuickTest Pr utilise le même langage (par suci de cmpatibilité) mais aussi VBScript largement plus répandu. L'interface de QuickTest Pr est plus ergnmique à utiliser, facilement manipulable par «pint and click» et dnc ainsi plus accessible à un nvice. 57

59 Mercury Interactive a été racheté en juillet 2006 par HP afin de cnslider sn ffre de lgiciels. HP espère ainsi cncurrencer IBM et Cmputer Assciates (CA). HP acquière ainsi les utils de tests, de gestin de prjets et de gestin du cycle de vie et de la perfrmance des applicatins de Mercury Interactive. HP atteint ainsi sn bjectif de cnstruire une ffre intégrée de lgiciels de gestin des infrastructures infrmatique et réseaux. Cette acquisitin lui permet de rivaliser, en termes d'ffre prduits, avec des acteurs cmme Cmputer Assciates (CA) u IBM. Le chiffre d affaire du lgiciel chez HP atteint 2 milliards de dllars par cet achat. HP réalise tutefis la majeure partie de sn chiffre d affaire dans la vente de matériel avec 87 milliards de dllars en Mercury Interactive représente un chiffre d affaire de 686 millins de dllars pur 3000 salariés. HP a débursé 4,5 milliards de dllars pur cette acquisitin. QARUN DE MICRO FOCUS Issu de la gamme QACenter. Du mainframe au Web, en passant par le client/serveur, de la gestin des tests à la validatin, du test fnctinnel au test de charge, les utils de la gamme QACenter permettent aux entreprises de réaliser des tests de perfrmances chérents et fiables. Grâce à QARun, les prgrammeurs btiennent les fnctinnalités d'autmatisatin dnt ils nt besin pur créer et exécuter des scripts de tests rapidement et de façn prductive ainsi que pur vérifier les tests et analyser les résultats. Cmpuware s est séparé de la partie slutin de qualité que gére Micr Fcus. L accrd de désinvestissement cmprend certains prduits de qualité et d essai distribués, y cmpris : Tests fnctinnels (QARun, TestPartner, QADirectr) Gestin des exigences (Recncile, Optimal Trace) Suivi de défauts (TrackRecrd) Test de perfrmance (QALad) Qualité de cde (Gamme de prduits DevPartner) 58

60 ABBOT (OPEN SOURCE) Spécifique aux IHM réalisés en Java (Abbt signifie "A Better Bt"), cette applicatin permet d'enregistrer des actins via une interface (Cstell) sur l'applicatin testée. Ces scenaris de tests peuvent ensuite être rejués à vlnté. Une API Java est dispnible pur autmatiser ces tests avec Junit. 59

61 RATIONAL ROBOT DE IBM &S_CMP=nne&synkey=K108274U58759I63 Cmme les précédents, il permet d'autmatiser les tests de fnctinnalité et de régressin des applicatins.net, Java, Web tutes les cmmandes VS.NET (VB.NET, J#, C# et Managed C++) et autres applicatins graphiques. Outil de test de fnctinnalités, de régressin et de cnfiguratin plyvalent adapté aux envirnnements ù les applicatins snt dévelppées dans plusieurs envirnnements intégrés et/u langages de prgrammatin. Autmatisatin aisée des tests manuels : La réalisatin de tests de régressin avec IBM Ratinal Rbt cnstitue une bnne intrductin à l'autmatisatin, car l'util est simple à utiliser et permet aux testeurs de décuvrir les prcessus d'autmatisatin à mesure qu'ils évluent dans leur travail. Détectin d'un plus grand nmbre d'erreurs : Les ingénieurs spécialisés dans l'autmatisatin des tests peuvent détecter un plus grand nmbre d'erreurs en ajutant à leurs scripts de test des pérateurs lgiques cnditinnels pur cuvrir davantage l'applicatin et définir des scénaris de test pur appeler des fichiers exécutables u des biblithèques DLL externes. Mise à dispsitin de scénaris de test adaptés aux bjets cmmuns (menus, listes et images bitmap) et de scénaris de test spécialisés adaptés aux bjets spécifiques à l'envirnnement de dévelppement. Intégratin d'un util de gestin des tests et cmpatibilité avec les utils de la platefrme IBM Ratinal Team Unifying Platfrm dédiés au suivi des erreurs, à la gestin des mdificatins et à la traçabilité des exigences. Prise en charge de plusieurs technlgies variées. IRISE STUDIO DE IRISE Platefrme permettant la définitin, les tests et la validatin des fnctinnalités de slutins Web avant tut dévelppement. irise prpse une apprche différente de la phase de test : n simule avant de livrer le prduit ce qui permet de mieux cller au résultat attendu. 60

62 LES OUTILS DE CAMPAGNE DE TEST Les principales fnctinnalités de ce type d utils snt : La définitin de campagnes de test. L histrisatin des résultats. La gestin des tests de nn-régressin. Les utils de gestin des plans et campagnes de test servent à définir, rganiser et cnduire les campagnes de tests. Ils divent dnc s'interfacer avec tus les utils qui interviennent dans les tests. Les utils de gestin des tests ne snt dnc pas des autmates de test. Certains éditeurs de lgiciels nt srti des suites intégrées cmprenant util de gestin de test et autmates afin d éviter l interfaçage entre des utils d éditeurs différents. TESTDIRECTOR DE MERCURY QUALITY CENTER - HP - Cet util, cmplet cmme ceux de la famille Mercury, prend en charge via une seule applicatin Web l'intégralité de la prcédure de test : gestin des besins, planificatin, élabratin, rganisatin et exécutin des tests, gestin des anmalies, analyse de l'état du prjet Dans cette suite, TestDirectr est un util de gestin intégré qui rganise et gère les prcessus de tests. TestDirectr devient le pint central de l'rganisatin, de la dcumentatin et la structure dans chaque prjet de test. TestDirectr peut rganiser une cmbinaisn de tests manuels et autmatiques, de régressin, de charge, dans le même plan hiérarchique et visuel, ce qui permet de bien analyser la prtée de tus les tests. 61

63 Une fis le planning fait, TestDirectr peut exécuter les tests manuels et autmatiques, séparément u grupés. Il rganise lui-même des petites cmbinaisns de tests qui permettent plus de spécificité dans le test. L'interface de TestDirectr s'adapte aussi à l'utilisatin des autres utils de test cmme LadRunner (test de charge et de perfrmance) u WinRunner (test fnctinnel). Les tests réalisés, les résultats (succès u échec) snt stckés dans la base de dnnées de Testdirectr, afin d'être étudiés et utilisés. Très évlué, TestDirectr permet la gestin des défauts de l'applicatin : l'analyse des défauts est ce qui aide essentiellement les intégrateurs à prendre la décisin de "g/n-g" au sujet du dépliement de l'applicatin. Le gestinnaire de défaut de TestDirectr (Defect Management) supprte le cycle de vie entier d'un bug de cnceptin de la détectin initiale du prblème à la crrectin. Ceci assure qu'aucun défaut n'est négligé u n'est clôturé avant qu'il n'ait été crrigé et validé. La frce de TestDirectr est aussi qu'avant qu'un nuveau défaut sit sumis, une fnctin examine la base de dnnées pur déceler les défauts semblables u les défauts dubles réduisants au minimum le besin de cntrôle et l'éliminatin manuelle. 62

64 SALOMÉ TMF (OPEN SOURCE) Salmé-TMF est un des rares utils libres de gestin de tests. Les principales fnctinnalités de Salmé-TMF snt : Organisatin du plan de tests sus frme d'arbre hiérarchique. Organisatin des tests en campagnes, pur l'exécutin. Pssibilité d'intégrer et d'exécuter des tests autmatiques (JUnit, Abbt, Beanshell). Gestin des anmalies via Bugzilla u Mantis. Prductin de dcuments au frmat HTML. Architecture puvant inclure des plugins (cnnexin à Junit, planificatin des tests-crnexec-...). Sn systeme de plugins ffre un certain avantage pur peu d'avir des cnnaissances en Java. C'est aussi, grâce à Java, un lgiciel multi-platefrmes. 63

65 TEST MANAGER DE SOFT EDITION.NET Sus frme d'une applicatin intranet Test Manager a pur but d aider les managers respnsables d équipes de tests à créer, planifier et rganiser leurs différentes sessins. C est aussi une gestin dcumentaire et un apprt méthdlgique pur les équipes de tests. Liste des fnctins de Test Manager : 1. Aide à la créatin et à l rganisatin des dcumentatins de test 2. Aide à la créatin des plans et stratégies de tests 3. Dimensinne, rganise et créez les campagnes de tests 4. Délivre des rapprts précis au Tp Management pur le suivi 5. Suivi de la prductin, des campagnes et de la cuverture fnctinnelle 6. Etablit le lien entre les dcuments de tests et les spécificatins 7. Dnne un statut précis et en temps réel pur tutes les campagnes de tests 8. Pint d intégratin avec les demandes de fnctinnalités 9. Pint d intégratin avec les anmalies Pur résumer, Test Manager aide les gestinnaires de prjets de tests à planifier et à assurer le suivi de leurs sessins de tests. Test Manager, au sein d une gestin dcumentaire, aide aussi les équipes de tests à créer rapidement et efficacement tus les dcuments de tests dnt elles nt besin. Test Manager permet de mieux tester le lgiciel et accélérera de ce fait la mise en prductin. Qualité et accrissement de la prductivité des équipes snt les deux principaux atuts. Test Manager est un prduit cncurrent de Test Directr de Mercury, mais se distingue par sn prix. Le prix de Test Directr est envirn 24 fis supérieur. Ceci est dû en partie business mdel (tut se fait via le Web : Supprt, renseignements cmmerciaux, etc.). 64

66 QADIRECTOR DE MICRO FOCUS Cmme les autres utils de cette catégrie, QADirectr vus dnne un envirnnement de travail pur gérer le prcessus de test dans sa glbalité, de la cnceptin à l'exécutin et l'analyse. QADirectr est une slutin de gestin des tests efficace et extensible pur des tests cmplets du cycle de vie des applicatins distribuées étendues. D'un seul pint de cntrôle : Planificatin des tests Exécutin des tests Variatin des envirnnements de test Analyse dynamique de l'applicatin testée Analyse des résultats des tests Sumettre les prblèmes Une architecture uverte intègre un large éventail d'utils de dévelppement et de test autmatisés requis pur tester cmplètement les applicatins tut en préservant les investissements existants. QADirectr permet aux testeurs, aux dévelppeurs et aux managers de tester cmplètement une applicatin avec une réutilisatin des tests, un partage des infrmatins et une facilité d utilisatin amélirée. 65

67 LES OUTILS DE TESTS FONCTIONNELS L bjectif des utils de génératin de tests fnctinnels est de vérifier la cnfrmité du fnctinnement d un système vis-à-vis des exigences de l utilisateur (plus glbalement du cahier des charges). Ces utils évitent la créatin "manuelle" de scripts de tests, qui prend du temps et qui n est pas frcément parfaite. Les éditeurs prpsent dnc des utils les plus cmplets pssibles, en ffrant un maximum de fnctinnalités autmatiques (génératin de scripts de tests, de rapprts des résultats attendus et atteints u nn, etc.) et d indicateurs graphiques pur une utilisatin cnviviale, aisée et rapide. Les utils de génératin autmatique de tests nécessitent une mdélisatin fnctinnelle (ntatin B, Statecharts Statemate et/u UML seln l util). Dans le cas d UML il s agit de diagrammes de classe, d activité et d états / transitins avec expressins OCL. A partir de là, le mdèle est analysé et, grâce à un mteur algrithmique prpre à chaque éditeur, des scripts de tests snt générés, pur une cuverture maximale des cas pssibles. Ces scripts scénaris snt exécutés dans un envirnnement dédiés et les résultats analysés avec tableaux de résultats, etc. Ces scénaris peuvent être sauvegardés, mdifiés et rejuer à vlnté. Les utils de génératin autmatique de tests snt dnc véritablement une valeur ajutée pur les prjets de grande taille ù la cmplexité des fnctinnalités grèverait le capital financier et temps de la partie relative aux tests. LEIRIOS TEST GENERATOR DE LEIROS Créé en 2003, Leiris est un éditeur de lgiciels de génératin autmatique de tests. Prix de la meilleure innvatin technlgique de Capital-IT 2007 et Prix de l Entreprise d Avenir 2006 pur la Régin Est, Leiris est un essaimage du Labratire Infrmatique (CNRS/INRIA) de l Université de Franche-Cmté. Leiris Smart Testing est aujurd hui utilisée par des grands industriels de la carte à puce u de la mnétique cmme Austria Card, Gemalt, Giesecke & Devrient, Ingenic, Parken u Sagem (SESAM VITALE 2) Leiris, sutenu par OSEO/ANVAR, emplie 30 persnnes entre Paris, Munich et Besançn, ù snt implantés sn siège scial et sa R&D. LEIRIOS fait également partie des deux pôles de cmpétitivité TES (Transactins Electrniques Sécurisées) à Caen et Micrtechniques à Besançn. Leiris dévelppe des slutins permettant d'autmatiser la cnceptin des tests pur les applicatins et systèmes lgiciels. Ce prduit marque une rupture technlgique par rapprt à la pratique de test actuelle, qui est principalement empirique et manuelle. Il permet de ratinaliser et d'amélirer frtement les prcessus de validatin de systèmes. 66

68 La sciété Leiris répnd aux besins de validatin des systèmes lgiciels par une ffre en génératin autmatique de tests. Au ceur des activités de validatin figure la cnceptin des tests fnctinnels. Ces tests permettent de garantir la cnfrmité d'une applicatin, d'un système lgiciel par rapprt à ses spécificatins initiales. Les pratiques actuelles, essentiellement manuelles et empiriques, cnstituent un facteur de nn-qualité imprtant pur les systèmes lgiciels. Les slutins Leiris Test Generatr intègrent cette technlgie Smart Testing, technlgie mise en œuvre depuis 1999 pur Schlumberger (dans les départements cartes à puces et terminaux urbains) et pur PSA Peuget Citrën sur plusieurs prjets d'envergure. Un transfert de prpriété exclusif et cmplet de la technlgie a été réalisé début 2003 entre l'université de Franche-Cmté et Leiris Technlgies. Leiris Test Generatr permet une réductin de plus de 30% de l'effrt de cnceptin des tests fnctinnels, avec une cuverture des tests 2 à 5 fis supérieure. Les slutins de Leiris en génératin autmatique de tests permettent ainsi une meilleure maîtrise de la fiabilité des systèmes lgiciels, une réductin des cûts de validatin et une accélératin du "time t market" des prduits. Vici une présentatin de l utilisatin de Leiris Test Generatr (LTG) : 1. Une mdélisatin fnctinnelle est effectuée à partir des Spécificatins Techniques de Besins par l utilisateur. 2. Le mdèle fnctinnel résultant (B, Statecharts u UML) est utilisé par le "générateur de tests LTG" pur créer les cas de tests. L utilisateur paramètre simplement ses critères de cuverture. 3. Le "générateur de scripts LTG" cmpse alrs les scénaris de tests. 4. Les scripts ainsi créés snt exécutés dans l envirnnement dédié (banc de test). 67

69 Exemples d applicatins : GSM gestin puce SIM Java Card JCVM mécanisme de transactin Gestin des clés, des identités et de la sécurité Fnctins visibilité générique essuyage, dégivrage, lavage Cntrôleur de climatisatin Algrithme de validatin tickets Metr/RER Validatin terminal de paiement (CB 5.2) Grupement des Cartes Bancaires Authentificatin du prteur 68

70 CONFORMIQ TEST GENERATOR DE CONFORMIQ SOFTWARE Cnfrmiq Test Generatr est un prduit inventé par la sciété Finlandaise Cnfrmiq Sftware Ltd créée en Il est distribué en France depuis un an envirn par Verifysft Technlgy (entreprise allemande). Cnfrmiq Test Generatr fnctinne avec tus les langages de prgrammatin. Champs d'applicatin : Cnfrmiq Test Generatr peut être utilisé dans les champs d'applicatin suivants : Test de fnctin, de système et d'acceptance Test de régressin (tests qutidiens autmatiques des structures) Test d'intégratin (simulatin de parties du système) Interface de test (JPOS, COM, J2EE, HTTP, SQL, OPC) Test de prtcle / plate-frme (TCP/IP, IPSec, GSM, Symbian) Supprts QML (UML + Java / C # syntaxe cmpatible) pur la mdélisatin Supprt pur les mdèles systèmes Supprt pur les dnnées structurelles de mdèles de systèmes Supprt simultané dans des mdèles de systèmes Supprt pur les cmmunicatins temps réel script de test par le biais d interfaces «plug-in» Livré avec la génératin d exemple de scripts «backends» Cnstructin de mdèle d'analyse statique et débgueur Supprt de la traçabilité et de la cartgraphie à des exigences élevées Supprt des scénaris de tests et de cas d'utilisatin de mdèles pur d'autres mdèles de cnceptin axée sur la génératin de tests Supprt d analyse de la valeur limite Cuverture générale des heuristiques de cnceptin de tests Transitin UML au niveau de cuverture et de l'état de cnceptin de tests heuristiques Facilement paramétrable et extensible pur la plate-frme de cnceptin de tests heuristiques Outil interactif d'rientatin et d'aide Livré avec manuel électrnique, par exemple des mdèles, des plug-ins et des testables systèmes 69

71 Avantages de Cnfrmiq Test Generatr Cnfrmiq Test Generatr est le seul util qui permet d'effectuer des tests qui snt nrmalement très difficiles à tester, cmme par exemple les prblèmes de synchrnisatin. Cnfrmiq Test Generatr garantit une meilleure efficacité de test, une baisse de la durée de phase de test et une plus grande cuverture de test. Supprime le risque d erreur dans la cnceptin des tests. Supprt de dévelppement pur l'ensemble des phases du prjet et, en utre, pur tus les cycles de vie du lgiciel. Créatin d'une plate-frme cmmune pur les cncepteurs et testeurs. Large cuverture de test : un grand nmbre de cmbinaisns de test pertinent est cuvert par les tests autmatiques. Maintenance simple de l'envirnnement de test - mdèles de test graphiques snt plus simples et plus rapides à entretenir et à réutiliser que les scripts de test. Applique les exigences de la qualité de la dcumentatin. Résultats des tests et des cuvertures de tests autmatisés : les dnnées frmulées clairement facilitent la gestin des erreurs et aident à la crrectin des erreurs. En plus de l'exécutin des tests en ligne, Cnfrmiq Test Generatr peut également générer des scripts de test hrs ligne qui purrnt être utilisés plus tard. Cnfrmiq Test Generatr peut être intégré dans des utils de planificatin et de gestin de test (cmme par exemple l'util de gestin de test Mercury). Dispnible pur les plates-frmes suivantes : Micrsft Windws NT, 2000 et XP Linux 70

72 71

73 MERCURY FUNCTIONAL TESTING ET MERCURY SERVICE TEST DE MERCURY QUALITY CENTER Mercury Functinal Testing ffre la slutin la plus cmplète du marché en matière d'autmatisatin des tests fnctinnels, d'interface utilisateur graphique et de nnrégressin. Il prend en charge pratiquement tutes les applicatins et tus les envirnnements lgiciels. Tirer parti à la fis de Mercury WinRunner et de Mercury QuickTest Prfessinal. Mercury Functinal Testing vus permet de prfiter des ressurces de test ffertes par les scripts WinRunner et QuickTest Prfessinal. Les ingénieurs qualité peuvent utiliser Mercury Functinal Testing pur créer des "scripts cmpsés" qui cmprtent des tests élabrés dans WinRunner et QuickTest Prfessinal. Mercury Functinal Testing tire en effet prfit de l'interpérabilité de WinRunner et de QuickTest Prfessinal : chaque prduit peut appeler les scripts de l'autre prduit et les résultats des tests apparaissent dans une interface cmmune. La SOA est le mteur des résultats métier. La SOA augmente la cmplexité infrmatique et elle peut cmprmettre l'activité si elle n'est pas crrectement mise en œuvre. Les décideurs infrmatiques prévyants adptent une nuvelle apprche du test des services SOA et Web repsant sur Mercury Service Test. Mercury Service Test permet aux équipes infrmatiques de mener des tests fnctinnels et de perfrmances pur les services. S'appuyant sur la technlgie leader du marché Mercury LadRunner, cette slutin réduit cnsidérablement les durées de test et permet de s'assurer que les services répndrnt aux exigences de fnctinnement et de perfrmances de l'entreprise avant de les déplyer en prductin. Grâce à Mercury Service Test, vus puvez : Réduire la durée des cycles d'assurance qualité en autmatisant les tests fnctinnels, de nn-régressin et de perfrmance des services qui ne snt pas dtés d'une interface graphique utilisateur. Simuler des envirnnements client J2EE, AXIS et.net pur évaluer l'interpérabilité des services. Simuler des envirnnements de prductin via la simulatin des suches serveur et les tests asynchrnes. Tester différences interfaces SOA. Créer et suivre les appels serveur pur garantir la réussite des tests de perfrmances asynchrnes. Offrir des fnctinnalités d'émulatin des services permettant aux testeurs de cmmencer très tôt, avant même la cnstructin effective des services. 72

74 HP est devenu un cncurrent sérieux pur IBM avec l util Functinal testing en cmparaisn avec Ratinal. Vici le résultat d une étude de cmparaisn entre les deux utils : S.NO Criteria 1 Generatin f Scripts Ratinal Functinal Tester Mercury Quick Test Prfessinal Reasn ***** *** The Ratinal Functinal tester is capable f generating VB scripts and Java scripts (Java statements). It is Eclipse based. The Mercury Quick Test Prfessinal generates nly VB Scripts. 2 Scripts ** ***** Mercury Quick Test Prfessinal is GUI based. Aut dcumentatin is created fr each step perfrmed by the user (in the table) in the keywrd view and a nvice tester finds the tl easy t wrk with. The Ratinal Functinal Tester requires sme prgramming experience. 3 Playback f the scripts 4 Feature t generate different test cases * ***** User actins perfrmed during recrding are replayed during playback. Multiple values selected using the shift keys did nt wrk with the Ratinal Functinal Tester. Hwever, multiple select capabilities wrked with Mercury Quick Test Prfessinal. *** ***** The Ratinal Functinal Tester has data driven cmmands t generate different test cases. The Mercury Quick Test Prfessinal uses parameterizing the tests t generate test cases. Hwever, the utput values have t be manually entered with the Ratinal Functinal Tester. With Mercury Quick Test Prfessinal the utput values are generated autmatically. 5 Cst ***** ** Ratinal Functinal Tester is cheaper than Mercury Quick Test Prfessinal. 6 Accmmdatin f new versins f ***** *** The tw tls have features that allw ne script t call anther script and identical activities are nt repeated. This prcess is applicatins easily accmplished with the Ratinal Functinal Tester cmpared t the Mercury Quick Test Prfessinal which requires technical expertise. 7 Script Reuse ***** ***** The tls have smart recgnitin features which permit reuse f the script n a new build. 8 Test Results *** ***** The test results are displayed in the html/text lg fr the Ratinal Functinal Tester. But the Mercury Quick Test Prfessinal displayed the results in the frm f a tree in the test result windw. When the target bject was selected, the tl gives a visual representatin f the snapsht (captured during recrding) in the screen recrder. 73

75 Cette étude a été menée par l université de l Arizna Plytechnique. (Divisin f Cmputing Studies Arizna State University, Plytechnic [email protected]) Les envirnnements utilisés pur l étude de cmparaisn entre les deux utils snt : - IBM Ratinal Sftware, Essentials f IBM Ratinal Functinal Tester, Java Scripting, v.6.1, IBM Crpratin, Jan Hewlett Packard Develpment Cmpany, L.P. Mercury QuickTestPrfessinal. (2007) (11 Mar.2007). - Marty hall and Mary Brwn, Cre Servlets and Java Server pages, Sun Micrsystems Press/Prentice Hall PTR - IBM Crpratin. Ratinal Functinal Tester. /tester/functinal/index.html (25 Jan.2007). 74

76 AUTRES OUTILS DE TESTS FONCTIONNELS Test Vectr Generatin de T-VEC T-VEC Technlgies est un grand furnisseur mndial de slutins permettant d autmatiser la génératin de vecteurs de test à partir d utils de dévelppement basés sur un mdèle guidé par les exigences et la cnceptin. Les slutins T-VEC permettent aux rganisatins de faire crrespndre les cycles de vie des prduits, des systèmes et du dévelppement de lgiciels aux bjectifs cmmerciaux et aux besins des clients afin d amélirer de manière cnsidérable la qualité et la prévisibilité, tut en réduisant de manière imprtante les délais de cmmercialisatin et les cûts généraux. T-VEC a sn siège scial à Herndn, en Virginie (USA), et cmpte des clients dans des dmaines variés tels que l électrnique aérnautique, l aérspatial, l autmbile, la médecine et d autres industries utilisant des prduits intégrés. Test Driver Generatin permet d étendre à d autre langage : C, C++, Java, SQL/ODBC/JDBC, XML, SAVON WinRunner, JCL, Perl, pythn, ADA, base et VB, cutume (graphiques), assembleur, cquille, langages de cmmande, émulateurs, classe des prpriétaires, plus. Reactis de Reactive Systems - Il s agit d un util américain. 75

77 76

78 AutTester ONE de AutTester Offre des tests fnctinnels, de régressin et d'integratin pur envirnnements Windws, applicatins client/server u Web. Cmpatible Windws 3.x, 95/98, NT, 2000, XP. QACenter Enterprise Editin de Cmpuware Supprte les envirnnements client/serveur, L4G, Java et Web. Ratinal Rbt d'ibm Autmatisatin de tests de régressin, de tests fnctinnels et de tests de cnfiguratin pur applicatins e-cmmerce, client/serveur et ERP. irise Applicatin Simulatr de irise Plate-frme permettant la définitin, les tests et la validatin des fnctinnalités de slutins Web avant tut dévelppement. Mercury Business Prcess Testing de Mercury Interactive Permet aux spécialistes "métier" et aux équipes "assurance qualité" de valider les prcessus métier autmatisés. TestView, WebFT de Radview Slutin permettant de définir des plans de tests autmatisés d'applicatins Web tut en centralisant les scripts de ces tests. Seapine SQA de Seapine Suite lgicielle cmpsée de tris utils permettant d'autmatiser les tests fnctinnels, de gérer les défauts et les changements de cnfiguratins. SilkTest de Segue Tests fnctinnels et de régressin autmatisés. Supprt des applicatins Web, Java, client/server d'entreprise. Visual WebTester de Sftbees - Outil de tests autmatisés : tests fnctinnels, de régressin et d'usabilité pur applicatins Web. evalid de Sftware Research Vérifie la cnfrmité aux spécificatins fnctinnelles des sites Web. Multiples mdes de synchrnizatin pssibles. HTTP/HTTPS, JavaScript, XML, Applets Java, Flash, ASP, JSP et ActiveX supprtés. Quality Frge de TestSmith Autmatisatin de tests fnctinnels et de régressin pur Windws. Les tests cncernent les sites et des applicatins Web. Les langages supprtés snt Java et C++. 77

79 Certify de Wrksft Plate-frme permettant l'autmatisatin de tests fnctinnels pur applicatins Web, client/server et mainframe. 78

80 LES OUTILS DE TESTS STRUCTURELS Ces utils permettent de valider ce que fait le lgiciel testé. Ils snt dnc cmplémentaires aux utils de tests fnctinnels qui vérifient, eux, ce que dit faire le lgiciel. C est purqui des éditeurs nt créé des suites cmprenant ces deux types de tests. C++TEST,.TEST, JTEST, SOATEST ET INSURE++ DE PARASOFT Sciété à capitaux privés fndée en 1987 par de jeunes diplômés de CALTECH (Institut de Technlgie de Califrnie) ParaSft Crpratin a sn siège en Califrnie avec des bureaux de distributin en Australie, en Inde, en Israël, en Chine, à Hng Kng, à Taiwan, au Brésil et au Japn. ParaSft Eurpe, dnt le siège scial est en France, pssède également des bureaux au Ryaume-Uni et en Allemagne. Parmi les clients de ParaSft, se retruvent Nkia, Thmsn, IBM, Ericssn, Alcatel, Philips, Cap Gémini et Being. ParaSft dévelppe et cmmercialise des utils de dévelppement qui apprte une aide à la détectin des erreurs dans les lgiciels. En renfrçant les standards de prgrammatin et en autmatisant le test unitaire, les technlgies ParaSft, uniques et très suvent primées, aident les utilisateurs à amélirer la qualité de leur lgiciel, à accélérer la mise sur le marché et réduit cnsidérablement les dépenses de dévelppement. Depuis ses débuts, la sciété a été largement recnnue pur dévelpper des technlgies innvatrices en matière de lgiciels et d'utils de prgrammatin de haute prductivité. ParaSft a dévelppé plusieurs prduits liés au dévelppement rienté bjet et web. Les technlgies d autmatisatin des tests de ParaSft snt le résultat de 20 ans de R&D sur les erreurs lgicielles et pruvent qu amélirer la qualité permet de réduire les dépenses tut en augmentant la prductivité. 79 Basées sur la méthdlgie AEP (Autmated Errr Preventin), les utils ParaSft mettent en œuvre une démarche de préventin, d une part pur éliminer des erreurs avant qu elles ne se manifestent dans les applicatins en prductin, et d autre part pur éviter que les erreurs identifiées et crrigées suite à un dysfnctinnement ne se reprduisent. En pistant et simulant les chemins d exécutin autmatiquement, la technlgie Bug Detective révèle les bugs à l exécutin qui seraient difficilement détectables lrs de tests u inspectins de cde manuels. Les utilisateurs peuvent ainsi truver, diagnstiquer et

81 crriger les catégries d erreurs lgicielles qui échappent à l analyse basée sur les standards de cdage et aux tests unitaires. RATIONAL TEST REALTIME DE IBM Slutin multiplatefrme permettant de tester les cmpsants et d'analyser l'exécutin du cde C, C++, Java et Ada. Prduit particulièrement adapté aux individus, qui écrivent du cde pur les applicatins embarquées u les autres types de prduits infrmatiques nmades. Prise en charge des applicatins critiques et cnfidentielles embarquées. Practivité extrême pur débguer, détecter et crriger les erreurs avant qu'elles n'affectent le cde de prductin. Ttalement cmpatible avec les autres slutins IBM Ratinal (dévelppement pilté par mdèles, gestin des tests et des cnfiguratins lgicielles). Ttalement cmpatible avec les utils tiers nvateurs (Mathwrks Simulink, Micrsft Visual Studi et TI Cde Cmpser Studi). XUNIT : JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC. JUnit Prpulsé sur le devant de la scène par le succès de l'extreme Prgramming (XP), le dévelppement pilté par les tests (Test-Driven Develppement u TDD) est devenu une évidence implacable : n ne peut être certain du bn fnctinnement d'un mrceau de cde, qu'à partir de mment ù l'n en a testé tutes les pssibilités d'erreur. Le principe du TDD est dnc, avant même d'écrire le cde d'une fnctinnalité, d'écrire le test pur ce futur cde. Une fis le test écrit, le cde de la fnctinnalité devra tujurs passer crrectement le test avant de puvir valider celle-ci. Chaque fnctinnalité peut dnc se retruver avec plusieurs tests sur le ds, chacun vérifiant d'une manière différente le bn fnctinnement d'une petite partie de l'applicatin. Parce qu'une applicatin cmplète peut dispser de plusieurs milliers de tests, l'autmatisatin devient nécessaire. C'est ici qu'entre en jeu l'architecture de test JUnit, destinée à tester le cde Java. Plus largement, tus les langages activement utilisés dispsent de leur équivalent xunit : PHPUnit pur PHP, nunit pur les langages.net, u AS2Unit pur ActinScript 2.0. Tus dérivent de SUnit pur Smalltalk, cnçu par Kent Beck, par ailleurs l'un des instigateurs du muvement Extreme Prgramming. Beck a ensuite prté SUnit vers Java avec l'aide d'erich Gamma, l'un des auteurs du livre fndateur sur les design patterns, et l'un des meneurs du prjet Eclipse. 80

82 La mise en place d'un test sur une méthde Java est assez simple avec JUnit. Chaque classe dispse de sn jeu de tests, chaque test injectant par exemple une erreur ptentielle que le cde dit prévir, u vérifiant le bn résultat d'un traitement. Les méthdes de test snt tutes précédées du ce qui permet à JUnit de les recnnaître et de les exécuter autmatiquement. Chaque classe de test dit imprter les paquetages rg.junit.test et rg.junit.test, JUnit étant installé et cnfiguré pur le système u l'util de dévelppement. JUnit 4.0 teste le cde au myen d'assertins, simulant diverses situatins pssibles. Ces assertins snt placées au cœur même des méthdes de la classe, aux côtés du cde de l'applicatin. Chaque assert*** placée crrespnd à un test effectif. Exemple avec assertequals : public static vid assertequals(blean expected,blean actual) Asserts that tw bleans are equal. 81

83 LES OUTILS DE TESTS DE PERFORMANCE Les utils de test de perfrmance prpsent suvent : Le test de mntée en charge. La simulatin d'un envirnnement spécifique. L évlutin agressive de l'accès aux ressurces. Les tests de perfrmances d'une applicatin snt suvent menés pur des sites Web u Intranet. En effet, lrs du dévelppement de sites Web il y a suvent des exigences quant aux perfrmances d accès au site (afin d éviter des temps d accès trp lngs). WAPT DE SOFTLOGICA WAPT est un util de test de charge pur applicatins Web et intranet. Il enregistre des scénaris de tests puis permet de les rejuer à vlnté en faisant varier : le nmbre d'utilisateurs, l'intervalle entre chaque test, etc. WAPT emplie plusieurs techniques avancées pur simuler de vraies cnditins de charge. Cette apprche est beaucup plus efficace que d'envyer simplement beaucup de demandes identiques au serveur en rafale. En fait WAPT simule un grand nmbre d'utilisateurs différents venant d adresses IP hétérclites ; chacune avec ses prpres paramètres : ckies, dnnées d'entrée pur différentes pages, nm et mt de passe, vitesse de cnnexin et sn prpre "chemin" dans l'applicatin. WAPT peut même simuler un temps aléatire entre les "clics d'utilisateurs" afin de rendre les actins de ces "utilisateurs virtuels" aussi réalistes que pssible, prches de celles de véritables utilisateurs. Si vus vulez simuler des milliers d'utilisateurs, vus n'avez pas besin d'indiquer le cmprtement séparé pur chacun d'eux. La pratique pruve qu'habituellement les visiteurs d'un site peuvent être divisés en plusieurs catégries cette apprche est emplyée par WAPT. Il suffit d indiquer le cmprtement pur chaque type d'utilisateurs désiré, et vus ajutez dans la campagne de tests autant de ces types d'utilisateurs dnt vus avez besin. Par exemple, des utilisateurs d'un magasin en ligne peuvent être divisés entre ceux qui passent en revue le catalgue, et ceux cnnectés à une certaine page, ajutant une charge spécifique. Pur chaque type vus créez un prfil séparé u tutes ses dnnées peuvent être indiquées. A chaque test vus puvez emplyer autant d'utilisateurs virtuels de chaque type que vus avez besin. Les demandes HTTP peuvent inclure des paramètres spécifiques à chaque utilisateur. Les valeurs de tels paramètres peuvent même être différentes pur chaque utilisateur du même type et peuvent changer dans tute la sessin. Par exemple, le serveur peut 82

84 envyer une variable de sessin en répnse à la première demande d'un nuvel utilisateur. Cette variable est ajutée aux demandes suivantes de cet utilisateur afin de les identifier. Vus puvez indiquer cmment emplyer ces paramètres changeants via une interface graphique. Vus puvez chisir le niveau cnstant de charge pendant tut le temps du test u augmenter la charge par intervalle. Vus puvez indiquer la péride glbale du test et le nmbre d'utilisateurs virtuels pur chaque prfil. La charge glbale dépend également des types d'utilisateurs, ainsi les prfils cnnectés peuvent varier au cur du test. Les résultats du test snt visualisés sus frme de rapprts et de graphiques descriptifs. Ils snt dispnibles à chaud pendant le dérulement du test. Ainsi vus puvez surveiller les paramètres principaux de l'exécutin des enchaînements en marches et suivre la répnse de vtre site face au vlume crissant de la charge. MERCURY LOADRUNNER DE MERCURY QUALITY CENTER HP LadRunner est le prduit de Mercury chargé des tests de stress et de mntée en charge. L'avantage de LadRunner par rapprt a ses cncurrents réside dans la multitude de types d'applicatins gérées. De plus, grâce à la précisin des dnnées btenues, chaque test de charge furnit au dévelppeur des résultats puvant dnner lieu à une actin. Exemple : lrs d'une transactin lente au niveau de l'utilisateur final, le dévelppeur peut accéder à la méthde u à l'instructin SQL présentant un gulet d'étranglement qui prvque le ralentissement. LadRunner évite les prblèmes de perfrmances cûteux rencntrés en prductin en détectant les gulets d'étranglement avant le dépliement d'un nuveau système u d'une mise à niveau. Vus puvez vus assurer que des applicatins nuvelles u mises à niveau furnirnt les résultats métier recherchés avant le dépliement, et ainsi éviter des dépenses excessives sur le matériel et l'infrastructure. Véritable référence du secteur en matière de prévisin du cmprtement et des perfrmances du système, ce prduit cnstitue la seule slutin intégrée de tests de charge, d'ptimisatin et de diagnstic prpsée aujurd'hui sur le marché. Avec Ladrunner, vus puvez évaluer les perfrmances, les applicatins de diagnstic et les gulets d'étranglement sur le système du début à la fin et les régler pur btenir une meilleure perfrmance ; tut cela à partir d'un seul pint de cntrôle. Il prend en charge de nmbreux envirnnements d'entreprise, ntamment Web Services, J2EE et.net. 83 Avec LadRunner, vus puvez : Obtenir un tableau précis des perfrmances système de but en but. Vérifier que les applicatins nuvelles u mises à niveau répndent aux besins de perfrmances spécifiés. Identifier et éliminer les gulets d'étranglement des perfrmances pendant le cycle de vie du dévelppement.

85 LadRunner cmprend désrmais une technlgie avec changement des jeux qui réduit le prcessus de créatin de scripts à quelques clics de suris. Web (Click and Script) fr LadRunner vus permet d'enregistrer des scripts sur une cuche de présentatin plus élevée. Il identifie autmatiquement les meilleurs scripts et crée des scripts autexplicatifs curts et intuitifs qui réduisent de 80 % la maintenance et le temps de créatin des scripts. Ces scripts snt également beaucup plus simples à gérer puisque tut le mnde a accès au script et peut rapidement en visualiser l'évlutin à chaque message. Web (Click and Script) fr LadRunner diminue en plus les qualificatins techniques nécessaires à l'élabratin de tests de charge. SIEGE (OPEN SOURCE) Un util Open Surce permettant de simuler nmbre de cnnexins sur un site web. Le désavantage par rapprt a un util cmme WAPT réside dans le fait qu'il ne dispse pas d'une interface utilisateur. Il peut juer un scénari en lisant une liste d'url à partir d'un fichier u stresser une seule URL avec un nmbre défini d'utilisateur. Ces URL peuvent être capturées et mdifiées en fnctin des besins et pur faire varier les prfils de test en utilisant Sprxy, un utilitaire de capture de trafic du même auteur. Srtie le 11 mai 2009 de la versin Siege 2.69 JMETER (OPEN SOURCE) DU GROUPE APACHE JMeter est un util de test de perfrmance pur ressurces statiques u dynamiques, créé le 15 décembre 1998 par Stefan Mazzcchi. Il est hébergé sur le site du Prjet Jakarta. JMeter peut simuler de lurdes mntées en charge sur une applicatin serveur u sur un réseau. Cdé 100% en Java, interface graphique en Swing. JMeter permet de mesurer les perfrmances de : Sites Internet Serveurs FTP Bases de dnnées (via les drivers JDBC) Scripts Perl Objets JAVA (applets) 84

86 QALOAD DE MICRO FOCUS Outil de mnter en charge de la suite QACenter. PERFORMANCE CENTER DE EMBARCADERO C est un prtail de qualité industrielle de suivi et de reprting des perfrmances de bases de dnnées. En prpsant une détectin autmatique des prblèmes qui menacent la dispnibilité et perfrmance des bases supervisées par cet util, l'administrateur de la base est infrmé de prblèmes ptentiels et peut ainsi agir d'une façn practive afin d'épargner aux utilisateurs des lenteurs et/u dysfnctinnement. 85

87 WEB PERFORMANCE LOAD TESTER DE WEB PERFORMANCE, INC Web perfrmance est un util de test de charge permettant de cnfigurer des tests de charge sur des applicatins web cmplexe. Les tests peuvent être effectués avec des utilisateurs virtuels en nmbre imprtant (plusieurs milliers) afin de mettre en évidence la capacité de charge du site web testé. Les caractéristiques : Caractéristique Descriptin Free Pr Capturez des pages Web cmplexes lrs de la navigatin, en visualisant les Enregistrement & temps de répnse et les tailles pur tutes les pages Web et leur cntenu. Oui Oui Analyse des pages Tus les aspects des pages Web peuvent être examinés, dnt les en-têtes de requête et de répnse, les ckies, les erreurs et le cntenu. Les pages peuvent également être visualisées dans un navigateur intégré à Web Perfrmance Analyzer. Détectin des pages Web lentes Spécifiez vs critères de perfrmance et Web Perfrmance Analyzer marquera alrs les pages trp lentes. Oui Oui La plupart des erreurs dans le cde HTML u JavaScript ne snt pas Détectin des erreurs détectées par les navigateurs, et purtant elles snt une cause de mauvais Oui Oui d'enregistrement fnctinnement des applicatins Web. Déterminez exactement ù vs pages Web snt cassées avant que cela ne devienne un véritable prblème pur vs visiteurs. Les Cas-Tests peuvent être persnnalisés pur permettre à chaque rejeu Persnnalisatin de Cas- d'effectuer une variatin de l'enregistrement riginal. Des valeurs de Tests remplacement peuvent être substituées pur les champs de frmulaire, ce qui permet, par exemple, à chaque Rejeu successif de mesurer les perfrmances d'un terme de recherche différent. Oui Oui Les transactins individuelles peuvent être éditées pur persnnaliser le cmprtement du Cas-Test. Chaque en-tête et chaque partie de l'url peuvent être édités. Les transactins peuvent également être cnfigurées avec les Mdificateurs, qui changent la valeur de la requête dynamiquement pendant le rejeu. Les champs de frmulaires et les paramètres de requête d'url peuvent être dynamiquement changés par les dnnées saisies par l'utilisateur pur simuler des variatins du Cas-Test initial, cmme la recherche pur différents mts clés u l'ajut de différents prduits dans un panier d'achat. Tut enregistrement peut être rejué en appuyant simplement sur un Rejeu de Sessin butn. Pendant le rejeu, chaque page peut être visualisée dans un Oui Oui Suivi des perfrmances dans le temps navigateur pur bserver l'impact visuel subjectif des changements et des ptimisatins. Le rejeu terminé, les changements snt cmparés pur des changements bjectifs cette fis-ci, cmme la taille de la page, la cmptabilisatin des ressurces, les temps de répnse, etc. Vs pages Web gagnent-t-elles u perdent-elles en rapidité? Web Perfrmance Analyzer archive les mesures de perfrmance, et vus permet de les suivre dans le temps. Alrs que le prjet passe par les étapes de dévelppement, de test, puis de maintenance, les cncepteurs peuvent s'assurer qu'aucun impact sur les perfrmances de l'applicatin ne passe Oui Oui 86

88 inaperçu. Les pages Web qui ne répndent pas aux critères de perfrmance snt alrs marquées. Vir avec les yeux de l'utilisateur En dehrs de l'envirnnement de dévelppement, les utilisateurs peuvent faire l'expérience de perfrmances mindres dues à des cnnexins réseau avec des bandes passantes plus faibles, une cngestin du réseau, aux serveurs prxy, etc. Enregistrez et rejuez avec un simulateur de mdem pur vus retruver dans les mêmes cnditins que l'utilisateur dispsant d'une faible bande passante. Oui Oui Le rapprt Bande Passante prduit également des estimatins de perfrmance pur tus les niveaux de bande passante. Supprt SSL - Nn Oui 87

89 Le cût d une telle slutin versin prfessinnelle : DESIGNATION REF. PRIX UROS H.T. PRODUIT Licence Perpétuelle Fixe Web Perfrmance Analyzer Pr 3.6 Versin Française avec 1 an de maintenance - Livraisn électrnique - Prix prm de 500,00 urs H.T. au lieu de 624,00 urs H.T. jusqu'au 11 juin WPA3- SSPL-PSS 500,00 Licence Perpétuelle Fixe Web Perfrmance Lad Tester 100 VU - Versin 3.6 Française sans maintenance - Livraisn électrnique WPLT3- SSPL ,95 Licence Perpétuelle Fixe Web Perfrmance Lad Tester 100 VU - Versin 3.6 Française avec WPLT3-1 an de maintenance - Livraisn électrnique - Prix prm de 2.095,00 urs H.T. au lieu SSPL-100- de 2.493, 75,00 urs H.T. jusqu'au 11 juin PSS 2.095,95 Licence Perpétuelle Flttante Web Perfrmance Lad Tester 100 VU - Versin 3.6 Française sans maintenance - Livraisn électrnique WPLT3- FPL ,50 Licence Perpétuelle Flttante Web Perfrmance Lad Tester 100 VU - Versin 3.6 Française avec 1 an de maintenance - Livraisn électrnique - Prix prm de 3.392,50 urs H.T. au lieu de 3.740,63 urs H.T. jusqu'au 11 juin WPLT3- FPL-100- PSS 3.392,50 Mdule Optinnel - Licence Perpétuelle Fixe Web Perfrmance Advanced Server Analysis 100 VU - Versin 3.6 Française sans maintenance - Livraisn électrnique WPASA3- SSPL ,00 Mdule Optinnel - Licence Perpétuelle Fixe Web Perfrmance Advanced Server Analysis 100 VU - Versin 3.6 Française avec 1 an de maintenance - Livraisn électrnique - Prix prm de 550 urs H.T. au lieu de 625,00 urs H.T. jusqu'au 11 juin WPLT3- FPL-100- PSS 657,80 88

90 VI - BILAN ET PERSPECTIVES Les tests nt évlué au fil des années : - de 1960 à 1980, il s agissait d une mise au pint. - De 1980 à 1990, n a utilisé les tests afin de chercher et de truver uniquement des erreurs. On réalisait des tests et cela fnctinnait plutôt bien. - Depuis 1990, les tests se veulent préventifs. Lngtemps abandnnés u tut au mins minimisés, les tests snt aujurd hui au centre de tus les intérêts : de nmbreux prgiciels nt vu le jur pur tester, gérer les versins Des sciétés nt investi dans la créatin d un service interne, véritable structure de tests. Rien ne peut être mis en prductin sans être validé par ce service. Les applicatins snt de plus en plus cmplexes, les vlumes de dnnées snt de plus en plus grands Il était bligé que les tests ccupent à nuveau au devant de la scène. Même le Clud Cmputing, qui est un cncept émergent est impacté par ce nuvel élan pur les tests. Le clud cmputing cnsiste à utiliser un nuage de serveurs ffrant une puissance de calcul, de stckage et de traitement inégalé pur délcaliser l utilisatin de services infrmatiques. Réservé aujurd hui aux applicatins (SaaS), au dévelppement (PaaS) et aux insfrastructures (IaaS), le Clud Cmputing lance le HaaS (Human as a Service) qui cnsiste à externaliser le capital humain! Autrement dit, les tests! L Extreme Prgramming (Méthde agile de gestin de prjets) a cmpris et intégré elle aussi les tests dans sn cycle itératif de dévelppement. L Internet mbile, nuveau mde d infrmatin et nuveau challenge pur les entreprises, est un supprt graphique différent nécessitant une prgrammatin adaptée et dnc des tests cmplémentaires. Il semble bien que les tests snt aujurd hui revenus sur le devant de la scène 89

91 VII CONCLUSION Nus avns tenté de présenter le plus simplement pssible l intérêt des tests dans un prjet de dévelppement infrmatique. Nus espérns tutefis que ce dcument est suffisamment cmplet pur vus permettre d avir une cnnaissance glbale sur les différentes techniques de tests. Il n existe pas de techniques meilleures que d autres : Tut dépend de ns besins, de ns bjectifs Cependant, rien n empêche de cmbiner plusieurs techniques. C est d ailleurs ce que nus précnisns. Avec l imprtance crissante des prjets infrmatiques, les risques de dysfnctinnement, de retards u de pertes financières augmentent. La réussite et la rentabilité d un prjet passent par un suivi rigureux, tut au lng du prcessus, de la qualité de la réalisatin. Il ne fait aucun dute que la plitique de tests est aujurd hui une dimensin incnturnable de la gestin de prjet. Nus avns vu que les tests faisaient l bjet d une pratique encre trp suvent artisanale mais que demain, dans un futur prche, les tests sernt une activité rigureuse fndée sur des mdèles et des théries et qu elle sera de plus en plus autmatisée. C est ainsi que les utils de tests se snt inscrits cmme un myen de structurer les tests tut cmme les prjets. Les utils de tests cmme la fnctin de testeur est actuellement en pleine essr et l'évlutin rapide des technlgies internet nécessite une réactivité accrue des sciétés pur défendre leur place de marché. Les tests snt aujurd hui revenus sur le devant de la scène 90

92 REFERENCES : BIBLIOGRAPHIE / «WEBOGRAPHIE» - «Prgrammer» N 109 Juin Livre Blanc «Chisir une stratégie de test de mntée en charge» de Brland &cp=1-11_4000_ t.pdf 91

93 GLOSSAIRE Algrithme : Un algrithme est un énncé d une suite d pératins permettant de dnner la répnse à un prblème. Si ces pératins s exécutent en séquence, n parle d algrithme séquentiel. Si les pératins s exécutent sur plusieurs prcesseurs en parallèle, n parle d algrithme parallèle. API : Une interface de prgrammatin (Applicatin Prgramming Interface) est un ensemble de fnctins, prcédures u classes mises à dispsitin des prgrammes infrmatiques par une biblithèque lgicielle, un système d'explitatin u un service Benchmark : Un benchmark, en anglais, est un pint de référence servant à effectuer une mesure. En infrmatique, il s agit d un banc d'essai permettant de mesurer les perfrmances d'un système pur le cmparer à d'autres. Bug : Un bug infrmatique (anglicisme) u bgue infrmatique (francisatin) est une déficience dans un prgramme infrmatique l empêchant de fnctinner crrectement. Sa gravité peut aller de bénigne (défauts d affichage mineurs) à majeure. Les bugs résultent le plus suvent d erreurs de prgrammatin. Cmpsant : Un cmpsant est un élément d'un système rendant un service prédéfini et capable de cmmuniquer avec d'autres cmpsants. La prgrammatin rientée cmpsant a pris de l'ampleur avec l'avènement de l'bjet. Cycle de vie : Il existe différents types de cycles de dévelppement entrant dans la réalisatin d'un lgiciel. Ces cycles prennent en cmpte tutes les étapes de la cnceptin d'un lgiciel. Deadlck : Un inter blcage (appelé aussi étreinte fatale) est un phénmène qui peut survenir en prgrammatin cncurrente. L'inter blcage se prduit lrsque deux prcessus légers (thread) cncurrents s'attendent mutuellement. Les prcessus blqués dans cet état le snt définitivement, il s'agit dnc d'une situatin catastrphique. EDI : L'Échange de Dnnées Infrmatisées (EDI) u en versin riginale «Electrnic Data Interchange», est le terme générique définissant un échange d'infrmatins autmatiques entre deux entités à l'aide de messages standardisés, de machine à machine. Dans la pratique, l'edi permet de réduire ntablement les interventins humaines dans le traitement de l'infrmatin, et dnc de le rendre effectivement plus rapide et plus fiable. Effet tunnel : L effet tunnel cnsiste en gestin de prjet à gérer des phases lngues dépurvues de pints intermédiaires de cntrôle. FIFO : L'acrnyme FIFO est l'abréviatin de l'expressin anglaise First In, first Out, que l'n peut traduire par «premier arrivé, premier servi» (littéralement «premier entré, premier srti»). Ce terme est emplyé en infrmatique pur décrire une méthde de traitement des dnnées. 92

94 Framewrk : En infrmatique, un framewrk est un ensemble de biblithèques, d'utils et de cnventins permettant le dévelppement d'applicatins. Il furnit suffisamment de briques lgicielles et impse suffisamment de rigueur pur puvir prduire une applicatin abutie et dnt la maintenance est aisée. Ces cmpsants snt rganisés pur être utilisés en interactin les uns avec les autres. Fuite mémire : GUI : En anglais, GUI est l abréviatin de «Graphical User Interface», sit «interface utilisateur graphique». Elle s ppse à CLI pur Cmmand Line Interface, sit «interface en ligne de cmmande». En France n peut parler d IHM u «interface hmme-machine» ; par extensin en anglais cntinental eurpéen, n parle d IHM et d HCI. Histrisatin : En infrmatique, l histrisatin est très suvent assciée à la gestin des versins dévelppées. Jaln : Un jaln crrespnd à une balise, un repère dans le prjet qui est incnturnable. Un jaln peut crrespndre à une date de remise d un livrable (dcument, prduit lgiciel ). Livrable : En infrmatique, un livrable crrespnd à une prductin. Il peut s agir d un dcument écrit, d un cmpsant infrmatique, d un lgiciel Métrique : Une métrique lgicielle est une mesure d'une prpriété d'une partie d'un lgiciel u de ses spécificatins (Exemple : «Cmbien d'instructins cmprte ce mdule?», «Quel purcentage des spécificatins client nt été traités?»). Open surce : La désignatin Open Surce s'applique aux lgiciels dnt la licence respecte des critères précisément établis par l'open Surce Initiative, c'est-à-dire la pssibilité de libre redistributin, d'accès au cde surce, et de travaux dérivés. Prcessus : Un prcessus est une tâche en train de s'exécuter. On appelle prcessus l'image de l'état du prcesseur et de la mémire au curs de l'exécutin d'un prgramme. Un prcessus métier (u prcédure d'entreprise) est une suite d'pératins nrmalisées effectuées par tute u partie des emplyés pur effectuer une tâche dnnée. Prttype : Un prttype désigne le premier u l'un des premiers exemplaires d'un prduit. Reprting : Le terme désigne une technique infrmatique cnsistant à extraire des dnnées pur les présenter dans un rapprt lisible (affichable u imprimable). Ressurces infrmatiques : En infrmatique, les ressurces snt des cmpsants, matériels u lgiciels, cnnectés à un rdinateur. En gestin de prjet, il n est pas rare d asscier les intervenants à des ressurces. Revue de cde : La revue de cde est un examen du cde surce d un dévelppement infrmatique. Risque : Le risque est la prise en cmpte par une persnne de la pssibilité de réalisatin d'un évènement cntraire à ses attentes u à sn intérêt. Lrsque la persnne 93

95 cncernée agit malgré cette pssibilité et s'expse ainsi à cette réalisatin, n dit qu'elle prend un risque. La gestin du risque cnsiste en l évaluatin et l anticipatin des risques, et à mettre en place un système de surveillance et de cllecte systématique des dnnées pur déclencher les alertes. Scenari de test : Un scénari de test cnsiste en une prcédure détaillée que le testeur dit suivre pur exécuter le cas de test (manipulatins, saisie, résultat attendus ). Script : Un script est un prgramme en langage interprété. Spécificatins fnctinnelles : Les spécificatins fnctinnelles décrivent les prcessus métier auxquels le prduit infrmatique devra répndre. Spécificatins techniques : Les spécificatins techniques décrivent le système infrmatique dans lequel le prduit sera implanté, sn interactin avec les autres cmpsants du système infrmatique (Base de snnées ). Tableau de brd : Regrupement d indicateurs permettant la prise de décisin. Temps de répnse : Temps éculé entre l'instructin dnnée par l'utilisateur et la réalisatin de cet rdre. 94