Les Tests : L état de l Art

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

AUDITEURS AUDITEUR NUMERO D AUDITEUR Stéphane CALIMET NPC 008961 Philippe FIRMIN NPC 007654 Eric LELEU NPC 008029 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

LES TESTS : L ETAT DE L ART TESTS ET VALIDATION DU LOGICIEL SOMMAIRE PREAMBULE : NECESSITE DES TESTS... 5 I - INTRODUCTION AUX TESTS LOGICIELS... 6 1 QUELQUES EXEMPLES DE BUGS... 6 2 LES DEFINITIONS DES TESTS... 6 3 LES CLASSES DE DEFAUT... 8 4 DIFFICULTES LIEES AUX TESTS... 8 5 LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS... 10 LE MODE D EXECUTION... 10 LES MODALITES DE TEST... 10 LES METHODES DE TEST... 11 LES NIVEAUX DE TEST... 11 LES CARACTERISTIQUES DE TEST... 11 6 EXEMPLE DE CLASSEMENT SELON 3 AXES... 12 7 QUELQUES PRINCIPES UTILES... 12 II LA STRATEGIE DE TESTS... 13 1 GENERALITES... 13 2 L ACTIVITE TEST... 15 III TYPES DE TESTS DANS LE PROJET... 17 1 LES TESTS ET LE CYCLE DE VIE... 17 2 LES TESTS UNITAIRES... 24 3 LES TESTS D INTEGRATION... 28 4 LES TESTS DE CHARGE... 32 5 LES TESTS DE VALIDATION... 38 2

PREAMBULE... 38 LES PRINCIPALES TECHNIQUES DE VALIDATION... 39 IV LES TESTS ET LA QUALITE... 50 LES CONSEQUENCES DE CET ETAT DE FAIT... 51 LES EDITEURS... 51 LES SOCIETES DE SERVICES... 52 EXEMPLE: INDICATEURS QUALITE... 53 V LES OUTILS DE TEST... 56 LES OUTILS D AIDE A LA REALISATION DES TESTS... 56 MERCURY WINRUNNER ET QUICKTEST PRO DE MERCURY QUALITY CENTER... 57 QARUN DE MICRO FOCUS... 58 ABBOT (OPEN SOURCE)... 59 RATIONAL ROBOT DE IBM... 60 IRISE STUDIO DE IRISE... 60 LES OUTILS DE CAMPAGNE DE TEST... 61 TESTDIRECTOR DE MERCURY QUALITY CENTER - HP -... 61 SALOMÉ TMF (OPEN SOURCE)... 63 TEST MANAGER DE SOFT EDITION.NET... 64 QADIRECTOR DE MICRO FOCUS... 65 LES OUTILS DE TESTS FONCTIONNELS... 66 LEIRIOS TEST GENERATOR DE LEIROS... 66 CONFORMIQ TEST GENERATOR DE CONFORMIQ SOFTWARE... 69 MERCURY FUNCTIONAL TESTING ET MERCURY SERVICE TEST DE MERCURY QUALITY CENTER. 72 AUTRES OUTILS DE TESTS FONCTIONNELS... 75 LES OUTILS DE TESTS STRUCTURELS... 79 C++TEST,.TEST, JTEST, SOATEST ET INSURE++ DE PARASOFT... 79 RATIONAL TEST REALTIME DE IBM... 80 XUNIT : JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC... 80 LES OUTILS DE TESTS DE PERFORMANCE... 82 WAPT DE SOFTLOGICA... 82 MERCURY LOADRUNNER DE MERCURY QUALITY CENTER HP... 83 3

SIEGE (OPEN SOURCE)... 84 JMETER (OPEN SOURCE) DU GROUPE APACHE... 84 QALOAD DE MICRO FOCUS... 85 PERFORMANCE CENTER DE EMBARCADERO... 85 WEB PERFORMANCE LOAD TESTER DE WEB PERFORMANCE, INC... 86 VI - BILAN ET PERSPECTIVES... 89 VII CONCLUSION... 90 REFERENCES : BIBLIOGRAPHIE / «WEBOGRAPHIE»... 91 GLOSSAIRE... 92 4

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

I - INTRODUCTION AUX TESTS LOGICIELS 1 QUELQUES EXEMPLES DE BUGS 1992 - Les ambulances de Lndres snt mal rientées par le lgiciel. Des pertes humaines snt à déplrer. 1996 - Explsin de la fusée Ariane 5 au but de 30 secndes de vl suite à une erreur de cnversin de dnnées numériques. 2004 - Défaillance du système d'alarme d'une centrale qui prduisit une cupure d'électricité aux Etats-Unis et au Canada. 2006 - Deux grandes banques françaises exécutent un duble débit pur plus de 400 000 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

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

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

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

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

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

6 EXEMPLE DE CLASSEMENT SELON 3 AXES Surce : http://dept-inf.labri.u-brdeaux.fr/~felix/ 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

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

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

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

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

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

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

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 1980. 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 http://fr.wikipedia.rg/wiki/cycle_de_dévelppement 19

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

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 6 1 2 Validatin des besins 5 Dévelppement d'un prttype Déterminatin des besins 4 Tests du prttype Surce : adaptée de http://fr.wikipedia.rg/wiki/cycle_de_dévelppement 3 21

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

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 : http://fr.wikipedia.rg/wiki/cycle_de_dévelppement 23

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

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

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

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

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