tests_v10.00

Les Tests : Ltat de lArtTests et Validation du logiciel

CNAM 2008 / 2009 - CENTRE REGIONAL DE LILLE NFE209 AUDIT ET GOUVERNANCE DES SYSTEMES DINFORMATION

AUDITEURS

AUDITEURStphane CALIMET Philippe FIRMIN Eric LELEU

NUMERO DAUDITEURNPC 008961 NPC 007654 NPC 008029

HISTORIQUE DES MODIFICATIONS

DATE08/01/2009 26/01/2009 15/04/2009 30/04/2009 19/05/2009 21/05/2009 28/05/2009 03/06/2009 05/06/2009 27/06/2009

AUTEURS. CALIMET, Ph. FIRMIN, E. LELEU E. LELEU S. CALIMET, E. LELEU S. CALIMET, E. LELEU S. CALIMET, E. LELEU S. CALIMET, E. LELEU S. CALIMET, E. LELEU S. CALIMET, E. LELEU P. FIRMIN P. FIRMIN, E. LELEU

DESCRIPTIONCration Introduction, Les tests et le cycle de vie Avantages inconvnients des cycles Tests dintgration Tests de charge Tests Validation (Fonctionnel) Test Validation (Structurel) Glossaire Test Qualit, outils de test Conformiq Test Generator

VERSIONV_1.0 V_2.0 V_3.0 V_4.0 V_5.0 V_6.0 V_7.0 V_8.0 V_9.0 V_10.0

Le s Tests : Ltat de lArt

1

Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation

LES TESTS : LETAT DE LARTTESTS ET VALIDATION DU LOGICIELSOMMAIREPREAMBULE : 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 DEXECUTION ..................................................................................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 LACTIVITE 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 DINTEGRATION ............................................................................28 4 LES TESTS DE CHARGE .................................................................................32 5 LES TESTS DE VALIDATION ............................................................................38 Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation Le s Tests : Ltat de lArt

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 DAIDE 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 ..............................................................................60IRISE

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 Le s Tests : Ltat de lArt RATIONAL TEST REALTIME DE IBM ....................................................................80XUNIT

: 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 longtemps. Aprs avoir t dlaisss par manque dintrts de la part des dveloppeurs, il semblerait que se soit aujourdhui les directions informatiques qui prennent conscience de leur vritable utilit. Ils permettent de rassurer et de palier aux erreurs humaines. Avec limportance croissante des projets informatiques, les risques de dysfonctionnement, de retards ou de pertes financires augmentent. La russite et la rentabilit dun projet passent par un suivi rigoureux, tout au long du processus, de la qualit de la ralisation. Il ne fait aucun doute que la politique de tests est aujourdhui une dimension incontournable de la gestion de projet. Des formations sur la qualit des logiciels, les tests applicatifs voient le jour, preuve que les tests nont jamais t si au cur de tous les projets. Le choix de notre sujet a t guid par ce soudain engouement de la part des directions informatiques pour les tests. Cependant, il est prciser que chacun de nous dispose dune vision et dun intrt diffrent 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 socit pour un projet denvergure. Fort de cette russite, il a eu loccasion ensuite de dployer en clientle les outils et mthodes dvelopps. Il juge que cette activit est fort potentiel. Philippe a une raison diffrente : Il est amen dans le cadre de son activit professionnelle assurer un plan d'assurance qualit, ce qui induit de possder une vue d'ensemble sur les tests logiciels. Le plan mis en place dans sa socit ne couvrant que la partie dveloppement, le fait sorienter tout naturellement vers les outils de gestion de tests. Stphane dsire traiter ce sujet car nvoluant pas professionnellement dans le monde du dveloppement, les tests sont pour lui une terre inconnue. Il apportera un regard neuf quant la faon dapprhender ce thme.

-

-


Toutefois, nous avons tous les trois un point commun : nous sommes tous intervenus dans la mise en production dun projet. Vous aurez loccasion dans ce dossier de constater tout dabord quil est difficile de dfinir prcisment le test applicatif. La diversit des tests pouvant tre mens lors dun mme projet, nous amnera traiter le test sous divers angles : thorique et pratique (utilisation doutils de tests).

5


I - INTRODUCTION AUX TESTS LOGICIELS

1 QUELQUES EXEMPLES DE BUGS

1992 - Les ambulances de Londres sont mal orientes par le logiciel. Des pertes humaines sont dplorer. 1996 - Explosion de la fuse Ariane 5 au bout de 30 secondes de vol suite une erreur de conversion de donnes numriques. 2004 - Dfaillance du systme d'alarme d'une centrale qui produisit une coupure d'lectricit aux Etats-Unis et au Canada. 2006 - Deux grandes banques franaises excutent un double dbit pour plus de 400 000 transactions.

2 LES DEFINITIONS DES TESTS

Avant de nous lancer dans la dfinition des tests, il est important de dfinir la diffrence entre une erreur, un dfaut et une anomalie.

On constate une ANOMALIE due un DEFAUT du logiciel lui mme du a une ERREUR de programmeur.

Il n'existe pas de dfinition unique des tests. Nous vous en proposons quatre permettant d'apprhender les tests sous diffrents angles. Selon lAFNOR : Phase du projet dans laquelle le client et le fournisseur testent la correspondance entre ce qui a t command et ce qui est effectivement produit. Le s Tests : Ltat de lArt Selon Glendford.J Myers dans The art of software testing : Un test russi n'est pas un test qui n'a pas trouv de dfauts, mais un test qui a effectivement trouv un dfaut. Selon Bill Hetzel : Le test est une activit destine dterminer si l'valuation d'une caractristique ou d'une aptitude d'un programme ou d'un systme donne les rsultats requis. Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation

6

Selon l'IEEE (Institute of Electrical and Electronics Engineers): Le test est l'excution ou l'valuation d'un systme ou d'un composant, par des moyens automatiques ou manuels, pour vrifier qu'il rpond ses spcifications ou identifier les diffrences entre les rsultats attendus et les rsultats obtenus.


7


3 LES CLASSES DE DEFAUT

Les erreurs peuvent tre de divers ordres. Il peut s'agir d'erreurs : de calcul de logique d'entre / sortie de traitement des donnes (dpassement de tableau) d'interface (communication entre les programmes) de dfinition des donnes

Ces erreurs reprsentent 90% des cas dcels.

4 DIFFICULTES LIEES AUX TESTS

Mme si les tests font l'objet de mthodes, de planning... tel un vritable projet informatique, il n'en reste pas moins que certains paramtres viennent perturber leurs excutions : Il est impossible de raliser un test exhaustif (le produit cartsien de certaines variables prendrait trop de temps tester). La qualit des tests dpend des donnes utilises (donnes de test). Il est impossible de supprimer l'erreur humaine. Il existe naturellement une perte d'informations entre la collecte du besoin client, la perception de ce mme besoin par le chef de projet et le besoin modlis par le dveloppeur.

Source : Cours CNAM Gnie Logiciel

Il existe des difficults d'ordre psychologique ou culturel. Il existe un manque d'intrt pour les tests car les programmeurs ont l'impression que l'on ne pointe du doigt que leurs erreurs. Il existe des difficults dites formelles : il n'existe ce jour aucun algorithme capable de prouver l'exactitude totale d'un programme.



8

Il existe bien videmment de nombreux autres paramtres venant perturber l'activit tests : la taille et la complexit des programmes, la diffrence entre lenvironnement de dveloppement et de production...


9


5 LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS

Il existe diffrentes faons de classifier les tests. Il nexiste pas de classification officielle : Chaque ouvrage, auteur, site, dfinit sa manire les diffrentes techniques de tests. Il est cependant possible de les regrouper selon leur mode dexcution, leurs modalits, leurs mthodes, leurs niveaux et leurs caractristiques.

LE MODE DEXECUTION

Le test Manuel : Les tests sont excuts par le testeur. Il saisie les donnes en entre, vrifie les traitements et compare les rsultats obtenus avec ceux attendus. Ces tests sont fastidieux et offrent une plus grande possibilit derreurs humaines. Ces tests sont trs vite ingrables dans le cas dapplications de grandes tailles. Le test Automatique : Le testeur est en partie dcharg des tests dans la mesure o les tests sont raliss par des outils (JUnit par exemple dans le monde Java).

LES MODALITES DE TESTIl sagit de tests : Statiques : Les tests sont raliss par l'humain (testeur), sans machine, par lecture du code dans le but de trouver des erreurs. Il peut sagir : de linspection ou dune revue de code; dun travail de collaboration lors dune runion (le programmeur, le concepteur, un programmeur expriment, un testeur expriment, un modrateur) Le s Tests : Ltat de lArt

Dynamiques : On excute le systme de manire tester lensemble des caractristiques. Chaque rsultat est compar aux rsultats attendus.


10

LES METHODES DE TESTIl sagit de tests : Structurels (Bote blanche) : Les tests structurels reposent sur des analyses du code source. Il est possible danalyser la structure du programme. Fonctionnels (Bote noire) : Les tests fonctionnels reposent sur une spcification (formelle ou informelle) du programme. Le code source du programme nest pas utilis. Les tests fonctionnels permettent dcrire les tests bien avant le codage . Il est parfois utile de combiner ces deux mthodes.

LES NIVEAUX DE TESTIl sagit de tests raliss tout au long de la vie du logiciel (cycle de vie). Unitaires : s'assurer que les composants logiciels pris individuellement sont conformes leurs spcifications et prts tre regroups. Dintgration : s'assurer que les interfaces des composants sont cohrentes entre elles et que le rsultat de leur intgration permet de raliser les fonctionnalits prvues. Systme : s'assurer que le systme complet, matriel et logiciel, correspond bien la dfinition des besoins tels qu'ils avaient t exprims. On parle de validation ou de recette. De non rgression : vrifier que la correction des erreurs n'a pas affect les parties dj dveloppes et testes. Cela consiste systmatiquement rejouer les tests dj excuts.

LES CARACTERISTIQUES DE TESTIl sagit entre autre de tests : De Robustesse : permet d'analyser le systme dans le cas o ses ressources sont satures ou bien d'analyser les rponses du systme aux sollicitations proche ou hors des limites des domaines de dfinition des entres. Souvent ces tests ne sont effectus que pour des logiciels critiques, ncessitant une grande fiabilit. De performance : permet d'valuer la capacit du programme fonctionner correctement vis--vis des critres de flux de donnes et de temps d'excution. Ces tests doivent tre prcds tout au long du cycle de dveloppement du logiciel d'une analyse de performance, ce qui signifie que les problmes de performances doivent tre pris en compte ds les spcifications.


11


6 EXEMPLE DE CLASSEMENT SELON 3 AXES

Source : http://dept-info.labri.u-bordeaux.fr/~felix/

7 QUELQUES PRINCIPES UTILES

Si possible faire tester par un autre dveloppeur que celui qui a cod. Ne jamais partir du principe qu'un test ne trouvera pas d'erreurs. Examiner et mmoriser les rapports de tests. A la moindre modification ne pas hsiter refaire les tests (test de non rgression).


12


II LA STRATEGIE DE TESTS

1 GENERALITES

Comme nous lavons vu prcdemment, les tests sont primordiaux. Il en va de mme de la stratgie de tests. Une technique de tests adapte et puissante restera sans effet si elle ne fait pas partie dune stratgie de tests. Ce que nous ne nous doutons pas, cest quune stratgie de tests peut reprsenter plus de 50% de la charge totale dun projet. Il est donc opportun que cette stratgie soit pense et dfinie de faon rigoureuse et quelle soit intgre dans le processus de dveloppement du logiciel. Les tests doivent tre conus avant que le logiciel soit ralis : lactivit tests commence ds la phase de spcification dun logiciel et se droule durant toutes les phases du cycle de dveloppement. Cest ainsi que la conception du logiciel va faciliter les tests (testabilit). La stratgie de test dpend : De la criticit du produit raliser Du cot de dveloppement

Une stratgie consiste dfinir : Les ressources mises en uvre (quipes, testeurs, outils) Les mcanismes du processus de test (gestion de la configuration, valuation du processus de test)

Finalement, la stratgie de tests tient compte : Des mthodes de spcification, de conception (pour rappel, les tests sont conus avant le dveloppement) Du langage de programmation utilis Du type dapplication (temps rel, base de donnes) Lexprience des programmeurs


13


Lactivit tests est un PROJET part entire. Cest la raison pour laquelle nous retrouvons lensemble des caractristiques dun projet : Organisation des quipes Planification et contrle (planification, estimation des charges, dfinition des mtriques, dfinition des environnements matriels et logiciels, dfinition de la campagne, du plan et des livrables) Analyse et conception (organisation du rfrentiel, identification des conditions de tests, traabilit, cas de tests, donnes de tests, procdures de tests, scnarios) Implmentation, suivi et excution Gestion des configurations (Elle assiste les tests) Evaluation des risques (Dcrire les risques comme un problme probable qui peut compromettre latteinte des objectifs des tests) Gestion des incidents Evaluation et reporting Clture (recette ou arrt des tests) Bilan projet Amlioration des processus et mutualisation


14


2 LACTIVITE TEST

Stratgie de tests Lensemble de la stratgie de tests est dtaill dans le Plan Qualit Projet (PQP). Le plan qualit projet est trs important. Il va notamment : o Dfinir lorganisation mettre en place (quipe de tests). Une stratgie de tests est (ou devrait tre) une organisation part entire. Les tests sont gnralement raliss pas des dveloppeurs (autres que ceux qui ont dvelopps le produit). Le Chef de projet quant lui, suit les activits, calcul le reste faire, enregistre et analyse les mtriques et les incidents, labore les tableaux de bord Dfinir les responsabilits et relations entre les diffrents intervenants. Dfinir les types et les objectifs de tests pour chacun des niveaux (tests unitaires, tests dintgration, tests de validation). Dfinir les outils qui seront utiliss. Dfinir les moyens et les dlais investir dans lactivit de tests.

o o o o

La stratgie de tests vise rendre leffort de test efficace en : o o o Maximisant les chances de dtecter les erreurs. Tentant de trouver le plus derreurs possibles, le plus rapidement possible. Facilitant le diagnostique.

Plan de tests Le plan de tests est la continuit logique au plan qualit projet. Lensemble des points voqus de manire gnrale vont y tre dtaills. Cest ainsi quil existe autant de plan de tests que de phases de qualification du produit. o o o Au dossier de SPECIFICATION correspond le plan de tests de VALIDATION. Au dossier de CONCEPTION GENERALE correspond le plan de tests dINTEGRATION. Au dossier de CONCEPTION DETAILLEE correspond le plan de tests UNITAIRES.


De manire gnrale, les tests se droulent du gnral au particulier (dtail). Lobjectif de chaque plan de tests est de fournir un programme pour vrifier que le logiciel produit satisfait les spcifications et la conception du logiciel. Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation

15

Un plan de test doit : o o o Dfinir les lments tester et lordre dans lequel ils doivent tre tests (planifier les tests). Dcrire lenvironnement de tests. Dfinir la faon dont les tests vont tre mens (procdures) : processus exacts mener, lhistorisation, la traabilit, le reporting, le suivi, le contrle Il sagit de la procdure de tests. Il est important que cette procdure soit rptable. Dcrire et constituer les fiches de tests (dfinir les actions raliser, les jeux de donnes utiliser, les valeurs et les comportements attendus). Lensemble des fiches de tests constitue le dossier de tests. Il est important de concevoir le dossier de test de manire POSITIF et NEGATIF . Fixer les critres darrt des tests : selon la couverture dfinie, selon le nombre derreurs trouvs, selon le temps imparti (Appliquer la stratgie de tests aux tests).

o

o

Rapport de test Pour chaque phase de test (unitaires, dintgration, de validation), lquipe ddie aux tests doit laborer un rapport de tests. Ce rapport est la synthse des actions menes suivantes : o o o Excution des fiches de tests (effectuer les actions dcrites). Analyser les rsultats obtenus : comparer les rsultats attendus avec les rsultats obtenus. Les lments de mesure sont trs importants ! Emettre des fiches de non-conformit si ncessaire (ces fiches sont aussi appeles fiches danomalie, fiches de bug). Il sagit de coupler intelligemment la gestion des tests et la gestion des corrections (incidents). NB : Concernant les fiches danomalie, il est conseill de raliser une fiche par problme dcel afin de faciliter le suivi de celles-ci. o o Consigner tous les rsultats dexcution de tests. Rdiger des comptes rendus de tests. La somme de ces comptes rendus constituera le rapport de tests. Le s Tests : Ltat de lArt

Qualification, Validation La qualification est essentielle. Elle permet de conclure et dmettre un avis sur le produit dvelopp et sa mise en production : adquation entre produit et spcifications fonctionnelles 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.

Pour rappel, voici ci aprs la dfinition et le schma de chaque cycle.

1 Cycle en Cascade

Il dfinit des phases squentielles l'issue de chacune desquelles des documents sont produits pour en vrifier la conformit avant de passer la suivante. Dans le cas contraire, un Feed Back (Retour arrire) est opr.

Analyse des besoins

Spcification

Conception

Ralisation

Validation

Maintenance Le s Tests : Ltat de lArtSource : Cours CNAM Gnie Logiciel

17


Avantages : La qualit des livrables (Un livrable ralis chaque fin de phase). Un calendrier plus facile laborer (Le planning correspond aux phases. La fin de chaque phase correspond un jalon). Le projet se passe dans le bon sens (Les phases se droulent les unes aprs les autres Un seul fil directeur).

Inconvnients : Difficult de revenir en arrire en cas dinsatisfaction client. Les modifications en amont ont un impact majeur sur les cots (Plus le projet est avanc, plus un impact engendra un cot lev cot exponentiel). Le temps de raction est beaucoup plus long (Il est plus difficile de se rendre compte dune erreur Tests tardifs dans le projet) Risque deffet tunnel (Les jalons permettent de scinder le projet en phases clairement identifies, vitant ainsi d'avoir une fin de projet trop longue chance. On parle gnralement d' effet tunnel pour dsigner un projet de longue dure sans chance intermdiaire.)


18


2 Cycle en V

Le modle du cycle en V est un modle conceptuel de gestion de projet imagin suite au problme de ractivit du modle en cascade. Il permet, en cas d'anomalie, de limiter un retour aux tapes prcdentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis--vis lorsque des dfauts sont dtects, afin d'amliorer le logiciel. Le modle de cycle de vie en V part du principe que les procdures de vrification de la conformit du logiciel aux spcifications doivent tre labores ds les phases de conception. Ce cycle est utilis lorsque lenvironnement est stable et que le client connait son besoin dans le dtail. Le cycle en V est devenu un standard de l'industrie logicielle depuis les annes 1980.

Expression des besoins et faisabilit

Recette

Spcification Fonctionnelle et technique

Qualification

Conception globale

Intgration

Conception dtaille

Tests unitaires

Dveloppement

Source : adapte de http://fr.wikipedia.org/wiki/Cycle_de_dveloppement


19


Avantages : Temps de raction meilleur grce la transversalit (Grce aux phases de tests transversales, les imperfections sont dcouvertes plus rapidement) Anticipation des tapes suivantes (Dans chaque phase, il faut prvoir le droulement de la suivante) En cas de problme dans le projet, il permet de limiter le retour aux tapes prcdentes.

Inconvnients : La phase de conception est fortement lie la phase de ralisation. Le travail en quipe est OBLIGATOIRE. Moins adapt au dveloppement logiciel (Cest le temps qui nous le dit par comparaison au cycle itratif actuellement utilis) Risque deffet tunnel (Les jalons permettent de scinder le projet en phases clairement identifies, vitant ainsi d'avoir une fin de projet trop longue chance. On parle gnralement d' effet tunnel pour dsigner un projet de longue dure sans chance intermdiaire.)


20


3 Cycle en spiral (Boehm 1988)

Le cycle en spirale est bas sur une approche et une valuation des risques. A chaque risque identifi on lui affecte une priorit et donc un ordre de traitement. Il s'agit ensuite de dvelopper par prototype successif. Chaque prototype ayant son propre cycle de vie (Analyse, conception, ralisation, intgration, validation...) Il emprunte au prototypage incrmental mais lui adjoint une dimension relevant de la prise de dcision managriale et non purement technique. Il couvre l'ensemble du cycle de dveloppement d'un produit tout en mettant l'accent sur l'activit d'analyse des risques. Chaque cycle de la spirale comprenant 6 phases : analyse du risque (1), dveloppement d'un prototype (2), tests du prototype (3), dtermination des besoins (4), validation des besoins (5), planification du prochain cycle (6). Ce cycle est utilis dans le cas dun environnement instable et dans lequel le client ne connait pas suffisamment son besoin.

Planification du prochain cycle 6 1

Analyse du risque

2 5 Dveloppement d'un prototype

Validation des besoins Le s Tests : Ltat de lArt

Dtermination des besoins

4 3 Tests du prototype

Source : adapte de http://fr.wikipedia.org/wiki/Cycle_de_dveloppement

21


Avantages : Cahier des charges respect au pied de la lettre (Cahier des charges ralis au fur et mesure) Validit des besoins (A chaque cycle les besoins sont valids Moins de risque derreurs)

Inconvnients : Calendrier et budget souvent irralistes (Chaque cycle font habituellement lobjet de dpassements - On ne sait chiffrer quun seul cycle la fois) Problme pour les composants externes (Difficult danticiper les composants ncessaires dans les cycles ultrieurs) Sa mise en uvre demande de grandes comptences et devrait tre limite aux projets innovants cause de l'importance qu'il accorde l'analyse des risques.


22


4 - Conclusion

Quelque soit le cycle de vie du logiciel retenu, on peut noter que les grandes phases du projet sont toujours prsentes : Phase Phase Phase Phase d'analyse de conception d'intgration de validation

Par soucis de prsentation et de comprhension, nous prsentons ci dessous le cycle de vie en V dans lequel sont intgrs les tests. A l'expression du besoin correspond les tests de recette. Aux spcifications correspondent les tests systmes. A la conception globale correspond les tests d'intgration. A la conception dtaille et au dveloppement correspondent les tests unitaires.

Expression des besoins et faisabilit

Tests de recette

Spcification Fonctionnelle, technique

Tests de charge, tests de validation

Conception globale

Tests dIntgration

Conception dtaille

Tests unitaires

Dveloppement


Source : http://fr.wikipedia.org/wiki/Cycle_de_dveloppement

23


2 LES TESTS UNITAIRES

Dfinition

Le nom de test unitaire vient du fait qu'une partie de code est appel unit . Ils sont aussi appels test de composants. Ce type de test va donc vrifier un module du code et ainsi s'assurer qu'il fonctionne de manire indpendante du reste du programme. Il va aussi vrifier que ce module respecte les spcifications fonctionnelles et techniques du produit. Les tests unitaires sont habituellement la charge de l'quipe de dveloppement. Les tests unitaires peuvent tre manuels (dans la plupart des cas) et/ou automatiss par des solutions logicielles (permet de s'assurer dune non rgression).

Formalisme des tests unitaires : la fiche de test

Les tests unitaires sont formaliss par une fiche que lon appel la fiche de test unitaire. Cette fiche est une liste (ou aide mmoire) qui doit permettre de rappeler les grandes actions dune phase de tests. Elle permet galement de prparer les tests en lenrichissant tout au long des dveloppements. Elle permet de stipuler que tous les points contrler ont t tests (tels que les tests dinstructions, de conditions, tests aux limites). Ds le dmarrage dun dveloppement ou affectation dune nouvelle tche, le chef de projet ou l'analyste initialise une fiche destine au dveloppeur. Au fur et mesure des dveloppements celle-ci peut tre enrichie par des descriptions de contrles ou de tests spcifiques. Lors de la ralisation des tests unitaires, il sagira de drouler cette liste d'actions, de raliser les actions et de les valider (OK ou non OK). Un "non OK" (souvent not KO) doit toujours tre justifi. Chaque analyste ou chef de projet responsable d'une phase de recette se doit de rclamer l'ensemble des fiches de tests d'un projet afin de cibler au mieux la phase de recette. Cest ainsi que les fiches de test assurent un passage en recette dans les meilleures conditions. Ces fiches s'inscrivent dans un objectif de qualit. Elles doivent tre considres comme un outil et non comme une contrainte.


24


Voici un exemple de formalisme :

Entte : Nom de lentit ou des entits : nom du programme (ou module) tester (Ex : Facturation) Libell : Rsum en une phrase ce que fait lobjet du programme (ex : dition des factures) Nom ou code du projet : nom ou code du projet laquelle le cycle est rattach Nom collaborateur : Nom de la personne qui test le programme Date : date la quelle ont eu lieu les tests

Corps de la fiche de test :

Nom de lobjet

Evnement

Droulement du test

Rsultats attendus

OK/KO

FAC001

Consultation facture

Rechercher la facture XXX Appuyer sur le bouton Imprimer

Impression facture OK XXX

Bas de page : Remarques : ....


25


Les donnes

Afin de raliser des tests unitaires, il est ncessaire d'laborer au pralable des jeux de tests. Ces jeux de tests peuvent tre : des donnes fictives imagines par le dveloppeur pour valider un ensemble de cas de tests, des donnes de production : il s'agit de donnes relles (extraites de la production), des anciens jeux de tests.

Les ressources

Les ressources nous permettent de raliser les tests. On peut s'inspirer : des documents de spcifications, des spcifications de tests (Scnarios, jeux de tests), de la fiche de test initialise par le chef de projet, des tests prcdents (suite correction, test de non rgression).

La dmarche o Analyse statique

La notion d'analyse statique de programmes couvre une varit de mthodes utilises (nombre Cyclomatique , mesure de complexit Mc Cabe, mesure de Halstead, taux de commentaires...) pour obtenir des informations sur le comportement d'un programme lors de son excution sans rellement l'excuter. C'est cette dernire restriction qui distingue l'analyse statique des analyses dynamiques.

o

Analyse dynamique Structurelle

L'analyse dynamique structurelle consiste vrifier la structure du code ainsi que les variables. Le s Tests : Ltat de lArt La vrification de la structure du code correspond une stratgie axe sur les flots de contrles qui consistent parcourir tous les nuds, tous les arcs et tous les chemins du code. C'est de cette manire que l'on peut dcouvrir qu'un test de type SI NON ALORS (IF..THEN..ELSE) n'est pas utilis. La vrification des variables consiste contrler leur affectation, leur utilisation dans des conditions et dans les traitements (calculs...).


26

o

Analyse dynamique Fonctionnelle

L'analyse dynamique fonctionnelle consiste vrifier le service rendu et non la faon dont il est rendu. En d'autres termes, il s'agit ici de valider les rgles de gestions nonces dans le cahier des charges. La difficult de ce type de test rside dans le choix des donnes de tests afin d'obtenir les rsultats attendus.

o

Bote noire

Le test de la bote noire est utilis pour tester un programme en vrifiant que les sorties obtenues sont bien celles prvues pour des entres donnes. Ce fonctionnement interne est soit inaccessible (cas le plus frquent), soit omis dlibrment (c'est alors un outil thorique qui permet de choisir d'tudier exclusivement les changes dentre / sortie).

Ce type de test est couramment utilis dans les tests de non rgression, les tests de robustesse (fonctionnement en situation extrme : dbranchement d'un quipement...) et les tests de charge.

o

Bote blanche

Le test de la bote blanche permet de tester le code. Le but est de valider quil ny a pas de plantage. On ne teste plus le fonctionnel. Le but est de tester tous les chemins, toutes les branches et toutes les instructions contenues dans le code.


27


3 LES TESTS DINTEGRATION

Dfinition

Aprs que les dveloppeurs (ou chacune des quipes) aient valids leurs dveloppements, ils regroupent les diffrentes parties de programme assembler. Ce regroupement, ou intgration, permet d'tablir une nouvelle version du produit, souvent destine une livraison. Les tests d'intgration ont donc pour but de valider le fait que toutes les parties dveloppes sparment fonctionnement ensemble, tant d'un point de vue du fonctionnement que des aspects techniques de l'assemblage. La phase d'intgration intervient aprs les tests unitaires des modules.

Les objectifs

Les objectifs vont dpendre de la phase du projet. Le projet est presque termin : Le test d'intgration aura pour but de vrifier la version finale du produit : vrifier que le logiciel correspond aux attentes du client et rpond au cahier des charges. Il sagit dune Intgration GLOBALE. Le projet est en cours de dveloppement : Il s'agit de dployer une nouvelle version du logiciel en y intgrant les corrections, les nouvelles fonctionnalits Il sagit dune Intgration INCREMENTALE. Dans les deux cas, il sera opportun de valider les interfaages de composants et l'interaction matrielle. Les primtres couverts et exclus

Le primtre exclus : o Comme prcis prcdemment, aucune vrification lie au fonctionnelle ne sera effectue.

Le primtre couvert : o o o o Livraison des diffrents modules ou composants. Vrification du fonctionnement des composants. Vrification du dialogue entre les modules (compatibilit, appel, passage de paramtres). Prvision et anticipation dun retour une version antrieur en cas dincident.


28


Les mthodes o Big Bang

Lintgration Big Bang est aussi appel non-incrmentale (globale). Le principe est d'intgrer tous les composants en une seule tape. L'intgration est certes rapide mais ne peux tre envisage que pour les petits projets. Dans le cas de projets importants, il y a trop de risques implmenter un nombre important de composants (dtection tardives des anomalies).

o

De haut en bas (Top down) Descendante

L'approche en Top-down vient du fait que l'on droule le programme de haut en bas : les modules viennent s'empiler les uns aux autres. Des bouchons sont utiliss pour simuler les traitements. Les bouchons doivent tre vus comme des programmes renvoyant une ou plusieurs valeurs. Les diffrents modules doivent tre les plus petits possible afin de comprendre aisment leur rle. Avantages : Dtection prcoce des dfauts d'architecture. Facilit de comprhension.

Inconvnients : La cration des bouchons est consommatrice de temps. L'effort de simulation des composants absents constituent une source d'erreurs. Tests tardifs des couches basses.

Unit teste

Bouchon de test

Dpendance Simule

Dpendance Teste

1


2

2

3

3

Source : Ralis par Eric LELEU pour illustration

29


o

De Bas en Haut (Bottom up) Ascendante

A l'inverse de lapproche top-down, l'approche bottom-up part du bas vers le haut : Non pas que l'on dmarre de la fin du programme mais plutt des fonctionnalits qui sont considres comme fondamentales. Elle ncessite donc le fait de bien dcomposer les fonctionnalits du programme et ainsi de dfinir celles qui seront indispensables et prioritaires aux autres. Le dveloppeur cre et utilise des bouchons pour simuler des composants non dvelopps. Dans lapproche ascendante, les composants de bas niveaux sont raliss et donc tests en premier.

Avantages : Faible effort de simulation. Dfinition des jeux d'essais plus facile. Les fonctionnalits basses sont plus souvent testes.

Inconvnients : Dtection tardive des erreurs majeures.

Unit teste

Bouchon de test

Dpendance simule

Dpendance teste

3

2

2

1

1



30


o

Mixte

L'approche mixte est une combinaison des approches ascendantes et descendantes. Il est parfois vu dans la littrature le concept de botes grises. Avantages : Le planning de dveloppement est gr de faon intgrer les composants dans l'ordre de cration (comparable la mthode FiFo First In / First Out). Prise en compte de la criticit des composants : les composants les plus critiques sont intgrs les premiers.

Inconvnients : Difficult d'intgration du la mixit des mthodes (Concilier les mthodes ascendantes et descendantes).

o

Par paquet

Cette approche repose sur une dcomposition du programme en fonctionnalits et/ou par criticit (dpend de la taille du programme). Il est vident que l'on ne peut procder ce type d'approche qu'en prsence de logiciel permettant le dcoupage en modules.


31


4 LES TESTS DE CHARGE

Dfinition du test de charge

Les tests de charge consistent exposer une application des conditions d'exploitation et d'utilisation les plus proches de la ralit afin de valider le comportement du systme. Les tests fonctionnels ne suffisent pas : lapplication doit fonctionnellement rpondre aux besoins mais doit aussi tre performante (Temps de rponse).

Objectifs des tests de charge

Les tests de charge permettent d'analyser trois aspects fondamentaux de la qualit de service d'une application : o o o La performance (au travers essentiellement des temps de rponse) La monte en charge (Maintient des fonctionnalits sous la charge,) La fiabilit (Dtection des maillons faibles quil sagisse de matriel ou de logiciel, valider les plateformes, identifier les contentions de base de donnes ou de rseau)

Types de tests de charge

Il existe plusieurs types de tests de charges permettant datteindre les objectifs cits prcdemment : o Test de performance : il s'agit d'un test au cours duquel on va mesurer les performances de l'application soumise une charge d'utilisateurs. Les informations recueillies concernent les temps de rponse utilisateurs, les temps de rponse rseau et les temps de traitement dune requte sur le(s) serveur(s). Test de Dgradations des Transactions : il s'agit d'un test technique primordial au cours duquel on ne va simuler que l'activit transactionnelle d'un seul scnario fonctionnel parmi tous les scnarii du primtre des tests, de manire dterminer quelle charge limite simultane le systme est capable de supporter pour chaque scnario fonctionnel et d'isoler ventuellement les transactions qui dgradent le plus l'ensemble du systme. Test de stress : il s'agit d'un test au cours duquel on va simuler l'activit maximale attendue tous scnarios fonctionnels confondus en heures de pointe de l'application, pour voir comment le systme ragit au maximum de l'activit attendue des utilisateurs. Le s Tests : Ltat de lArt

o

o


32

o

Test dendurance, de robustesse, de fiabilit : il s'agit de tests au cours duquel on va simuler une charge importante d'utilisateurs sur une dure relativement longue, pour voir si le systme test est capable de supporter une activit intense sur une longue priode sans dgradations des performances et des ressources applicatives ou systme. Test de capacit, de monte en charge : il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs sans cesse croissant de manire dterminer quelle charge limite le systme est capable de supporter.

o

Il existe d'autres types de tests (test de tolrance aux pannes, tests de volumtrie), plus cibls et fonction des objectifs atteindre dans la campagne de tests. tant entendu qu'en principe un type de test correspond un type d'objectif.

La dmarche (ou la stratgie de conduite des tests de charge)

La dmarche consiste : o o o o o o o Prparer les tests (dossier de test, tude de faisabilit technique) Crer les scripts (QUOI) Crer les scnarios (COMMENT) Excuter les scnarios Analyser les rsultats Amliorer le systme (Tuning systme) Rdiger un rapport (prconisations)

La prparation des tests correspond la phase primordiale. Elle consiste tout dabord raliser un dossier de tests comprenant : o o o o o o o o o La description de lapplication Le descriptif des transactions Le descriptif des scripts Les scnarios Le planning Le plan de charge Les objectifs atteindre La configuration Les jeux de donnes.

QUOI

COMMENT POURQUOI AVEC QUOI


33


La prparation des tests a aussi pour but de raliser une tude de faisabilit technique sur les outils et leur environnement : Tests manuels : ont comme problme majeur leur organisation qui est une opration gnralement inefficace en matire d'utilisation du temps, des budgets et des ressources. En outre les tests manuels ne permettent pas de gnrer des rsultats productibles, ne fournissent aucun niveau quantifiable de stress des applications et ne peuvent pas tre coordonns dans des conditions satisfaisantes. Leur processus non extensible ne permet pas d'intgrer des outils de localisations de la cause source d'un problme de performance. Applications dveloppes en interne : permettent de rpondre au budget trop serr qui ne permet pas de recourir une solution extrieure trop coteuse. Les problmes sont d'ordres diffrents : par exemple la couverture applicative qui est souvent test par des scripts trs spcifiques l'application. Lorsqu'ils sont correctement dvelopps, ces scripts permettent de tester la capacit de l'application grer une action donne mais pas de mesurer sa capacit traiter un ensemble composite de transactions. L'obtention de rsultats exploitables est quasiment impossible. Un autre souci avec ce type de tests est donc la spcificit des outils. Ils ne peuvent pas tre utiliss pour d'autres applications au prix de changement du script : le processus de correction des scripts initiaux pour rpondre un nouveau besoin peut souvent s'avrer tout aussi long que d'en dvelopper un nouveau en partant de zro. La dernire difficult rencontre est que ce type de scripts (souvent dvelopp par une seule personne) sont assez peu exploitables et comprhensibles par d'autres intervenants si le script n'est pas assez document (ou pire si l'auteur quitte la socit en milieu de projet). Outils Open Source : permettent de raliser des tests lmentaires d'applications Web simples, des fonctionnalits essentielles leur font encore dfaut pour tester des applications critiques. Pour tester des applications critiques, l'absence de support des technologies autres que Web/HTTP rend leur utilisation impossible. En effet, beaucoup de ces outils sont incapables de mener des tests anticips de monte en charge des composants des implmentations de middleware ou de base de donnes. De plus en raison de l'absence d'API de haut niveau, les scripts ont tendance devenir extrmement longs et d'autant plus difficiles maintenir. La plus part des outils Open sources sont bass sur la technologie JAVA. Ces limitations ont souvent pour consquence de multiplier les cots matriels/ressources requis pour maintenir plusieurs machines de test de charge. Les outils Open Source sont gnralement des solutions ponctuelles et ne proposant aucune intgration avec d'autres outils grant les tests fonctionnels et de rgression. Framework de tests intgrs aux EDI : sont des outils ns d'une nouvelle tendance de l'industrie du dveloppement logiciel. Ces outils consistent concevoir des EDI trs importants intgrant galement des fonctions de test. Par exemple Microsoft Visual Studio Team System pour l'univers .NET est le plus rvlateur. L'avantage de ce type de solution est de promouvoir un dveloppement orient sur les tests, n'exigeant pas de maitriser plusieurs outils et permettant de tester l'application dans un environnement familier. Cet avantage majeur est aussi le plus gros inconvnient puisqu'il propose une vue entirement tourne sur le dveloppement, supposant que les dveloppeurs ralisent toutes les activits (c'est dire le codage, les tests unitaires, les tests de charge et de production). Ces outils ne prennent en charge que leur propre environnement, ils ne proposent que des fonctions trs rudimentaires pour tester la charge des applications Web et ne supportent pas d'autres environnements de


34


dveloppement. Elles se rvlent efficaces aux petits projets mais insuffisantes pour tester des applications stratgiques complexes. De plus, aucun de ces Frameworks ne couvre tous les aspects des tests fonctionnels aux tests de performance. Outils ddis au Web : utilisent tous la mme approche qui est de piloter Internet Explorer pour lui faire raliser des scripts de tests en tant qu'utilisateur virtuel. Ces outils sont prcis ou extensibles mais pas les deux la fois en raison de leurs limitations techniques. Ce n'est donc pas la solution idale pour construire des tests de charges. Pour progresser en extensibilit, il est ncessaire de rduire la consommation de ressources par utilisateurs virtuel. Cependant la prcision d'une telle approche est discutable dans la mesure o elle oblige tous les utilisateurs virtuels partager des pools communs de ressources, ce qui n'est pas une reprsentation raliste d'un contexte de production. Les outils ddis aux tests de charge Web fonctionnent exclusivement avec internet Explorer et les autres navigateurs ne sont absolument pas pris en charge. L'un des principaux inconvnients de ce type d'outil rside dans les limites des fonctionnalits de leur langage de script. Ils ignorent les principes lmentaires de tout langage de programmation. La ralisation de scripts pour d'autres projets est donc trs difficile voir impossible. Service de tests hbergs : sont gnralement raliss depuis un service Internet distant. Cette approche ne ncessite aucun matriel, logiciel ni expertise du cot client et peut prsenter des avantages pour dcouvrir les premiers bnfices de tests de montes en charges. Le seul inconvnient est que les tests doivent tre raliss de faon rgulire tout au long du cycle de dveloppement (aussi bien de faon mthodes que dans sa globalit). Certains composants applicatifs ne sont pas accessibles sur les rseaux publics et leur test avec une solution hberge devient difficile. Le comportement d'Internet tant largement imprvisible, ces tests hbergs ne sont pas reproductibles. Ils sont donc utiles pour tester un concept et doivent tre raliss suffisamment tt. Plateformes d'entreprise : sont les seules qui rpondent l'intgralit des besoins de test de charge. Ces solutions sont suffisamment extensibles pour tester des environnements applicatifs htrognes pour un cot raisonnable. En assurant galement les tests de stress des composants, elles permettent de dtecter les enjeux de performance en amont du cycle. Leur capacit contrler intgralement les flux d'activit des utilisateurs virtuels et un langage de script avanc et flexible permettent de facilement rutiliser les scripts dans diffrents scnarios d'utilisation. Des API de haut niveau pour les environnements applicatifs supports simplifient grandement la maintenance des scripts de tests. Des outils de reporting permettent galement d'analyser rapidement les rsultats des tests de charge travers des outils de diagnostic localisant la cause source des ventuels problmes pour en acclrer la rsolution. La problmatique qualit est traite dans une approche globale. Des diteurs proposent gnralement des prestations de support, de formations pour garantir une implmentation optimise et russie. Il existe bien entendue de notables diffrences entre les diffrentes offres du march mais elles sont dans tous les cas bien plus performantes que les diffrentes alternatives que nous avons vu prcdemment voques.


35


Quand mener les tests de charge

Plus les tests de charge dbutent tt dans le processus de dveloppement, plus ils permettent de mettre rapidement en vidence les possibles dfauts du logiciel ou de son infrastructure sous-jacente. Si l'on sait que le cot des corrections des dfauts non dcouverts progresse exponentiellement chaque phase suivante du cycle de dveloppement, il n'en est que plus essentiel de dbuter les tests de monte en charge le plus tt possible. Compte tenu de la structure multi-niveau des applications existantes, les diffrentes phases du processus de dveloppement ont t synthtises dans la figure ci dessous avec les tests correspondants chaque phase.

Phases au cours desquelles des activits de test de charge peuvent tre intgrs Source : Livre Blanc Choisir une stratgie de test de monte en charge de Borland

Le diagnostic de ces problmes immdiatement avant le dploiement avec une solution classique de test de bout en bout est gnralement trop complexe, et dans tous les cas, leur rsolution est infiniment plus coteuse que s'ils avaient t dtects en amont. Cette phase de test est unique dans la mesure o elle est gnralement ralise avant qu'il n'existe de vritables clients permettant d'enregistrer un script de test; ces derniers doivent donc tre rutiliss (en tests unitaires) ou dvelopps manuellement.


36


Pour les tests de composants, on procde des tests de stress qui permettent de localiser simplement et conomiquement les problmes potentiels tels que les situations d'inter-blocage (deadlock), les problmes de synchronisation, des fuites mmoires, des enjeux de performance...

Pour les tests de charge de l'infrastructure (ou benchmark), les dcisions concernant celle ci sont gnralement prise assez tt. Cependant, l'infrastructure retenue peut intgrer un systme d'quilibrage de charge, des serveurs d'applications, des serveurs web..., jouera un rle cl dans la performance de l'application. Les rsultats officiels aux benchmarks standard ne sont gnralement pas d'une grande aide et ne peuvent pas prendre en compte l'architecture complte de l'application. Une bonne comprhension des effets des diffrents paramtres de configuration systme permet de disposer suffisamment tt de donnes utiles pour l'optimisation ultrieure des performances. La connaissance des indicateurs cls de performance fournit un benchmark significatif pour les tests ultrieurs de monte en charge de bout en bout et de monitoring applicatif. En ralisant assez tt les tests de charge de l'infrastructure, il est possible de vrifier que les composants rsidant dans les diffrentes couches collaborent comme prvu. L'utilisation d'un prototype tous niveaux incluant un sous ensemble de la fonctionnalit complte touchant tous les niveaux de l'architecture permet de raliser les tests suffisamment tt dans le processus de dveloppement pour dtecter rapidement les potentiels dfauts de conception. Il est galement possible d'valuer diffrentes alternatives de conception comme la distribution et la rplication des couches de prsentation/mtier/donnes. Les tests de charge de bout en bout permettent d'analyser le fonctionnement de l'ensemble de l'application dans diffrents scnarios ralistes d'utilisation et de charge. Ils peuvent durer quelques heures ou plusieurs jours. Ces tests sont gnralement conduits dans un environnement temporaire de pr production et leurs rsultats permettent de rpondre aux questions suivantes : o o o o o Des erreurs se produisent-elles dans des conditions particulires de charge ? Quelle est la capacit systme requise pour les couches de l'application ? L'application pourra-t-elle satisfaire les niveaux de services requis ? L'application est elle optimise pour offrir les meilleurs performances ? Les activits de rsolution des erreurs, d'optimisation et de rglage ou l'introduction de nouvelles fonctionnalits ont elles eu des effets ngatifs sur les performances ? L'application est elle prte pour un dploiement intgral ?

o


37


5 LES TESTS DE VALIDATION

PREAMBULELes tests de validation ont pour objectif de vrifier que toutes les exigences du cahier des charges soient respectes. Ces tests sont effectus immdiatement aprs les tests d'intgration. Il existe deux stratgies ou approches pour les tests de validation : La premire consiste identifier toutes les fonctions du logiciel et de les tester de faon squentielle. La deuxime approche est de tester les caractristiques du logiciel (interface, ergonomie, performance).

-

Dans la pratique, les deux sont utiliss. Les tests de validation font partie de la stratgie de tests (Stratgie de tests). A ce titre, l'organisation de la recette doit respecter les consignes dcrites dans le dossier de stratgie de tests, savoir : Vrification et respect du primtre dfini. Validation de toutes les fonctionnalits inventories. Utilisation des jeux de tests dfinis (idalement, le jeu d'essai doit tre le plus proche possible de la ralit. Dans la plupart des cas, on prendra des donnes relles) et de la plateforme de recette associe. La plateforme de test doit tre la plus proche possible de celle o sera dploy le logiciel. Excution de l'ensemble des scnarios labors. Suivi et synthse des fiches de recettes. .

-


38


LES PRINCIPALES TECHNIQUES DE VALIDATION APPROCHE FONCTIONNELLE (BOITE NOIRE)Les tests fonctionnels ne permettent pas d'accder au code source. Il est donc plus difficile par ces techniques de dtecter des dfauts du logiciel.

APPROCHE FONCTIONNELLE CLASSIQUEL'approche fonctionnelle classique a pour objectif de tester que le logiciel fait effectivement ce qu'il est cens faire. Cette approche teste chacune des fonctions que le composant accomplie (Rgles de gestion prcise dans la documentation de spcifications ou le cahier des charges) sans se soucier de la structure interne du programme. Cette approche se fait donc en bote noire . C'est l'approche privilgie ce jour.

ANALYSE PARTITIONNELLEL'analyse partitionnelle se base sur le domaine de variation des donnes en entre du composant logiciel. Dans la pratique, on segmente les cas fonctionnels (ralisation de partitions) en supposant que tous les cas d'un segment se comportent comme les autres. Ainsi, si un test est valid pour un cas A appartenant un ensemble, il sera valable pour toutes les classes de donnes quivalentes du mme ensemble. On choisira une donne de test gale au moins un choix quelconque d'un reprsentant de chaque classe.

Comportement 1 Ensemble de toutes les valeurs possibles Comportement 2

1 Valeur Comportement 1

1 Valeur limite


1 Valeur Comportement 2Source : Ralis par Eric LELEU pour illustration

39


Exemple : Soit la fonction qui calcule les frais de port : frais de 10 si montant dachat infrieur 100 (on suppose quun montant dachat ne peut pas tre ngatif). Il existe 2 comportements : le montant dachat peut tre infrieur ou suprieur 100. Il est inconcevable de tester toutes les valeurs possibles. Il convient de choisir une valeur dans chacun des deux domaines de comportement : par exemple 15 et 110 dachat. Ne pas oublier de tester les valeurs limites : 100 dans notre cas !

TESTS AUX LIMITESL'exprience prouve que les erreurs se situent trs souvent la frontire de comportements diffrents ( les bugs se cachent dans les coins ). Ces tests aux limites sont souvent utiliss avec la technique de partitionnement : les valeurs aux limites peuvent tre des valeurs aux frontires des partitions. Exemple de bugs aux limites : L'indice de tableau est dpass. Une comparaison stricte au lieu d'une avec galit. Oublie de traitement du premier ou du dernier record d'un fichier.

Exemple : En gnral, pour un paramtre appartenant un intervalle, il y a gnration de 6 donnes de test. Pour tester si P est compris entre [0,100], nous slectionnerons six valeurs (donnes de test) de manire tester chacune des bornes (limites) : -1, 0, 1, 99, 100, 101.


40


TESTS COMBINATOIRES (PAIRWISE)

L'approche Pairwise fait que l'on slectionne les donnes de test pour couvrir toutes les paires de valeurs. Ceci sur la constatation qu'un seul test couvre plusieurs paires et qu'il y a beaucoup plus de combinaisons que de paires. Le dfaut de cette technique est qu'il n'y a aucune chance de dtecter les erreurs demandant des combinaisons de deux valeurs et plus. Exemple 1 : imaginons une bote de dialogue compose de 4 listes avec 3 valeurs possibles. Il existe donc 81 combinaisons possibles (34). En ralit, dans l'approche PairWise seul 9 cas (ou paires) seront tests : Chacune des valeurs de la premire liste combine avec une seule valeur de chacune des autres listes. Exemple 2 : imaginons 3 variables boolennes A, B, C. Le nombre de combinaisons de valeurs / tests : 23 = 8. Le Nombre de paires de valeurs : 12. (A=1, (A=0, (B=1, (B=0, B=1), B=1), C=1), C=1), (A=1, (A=0, (B=1, (B=0, B=0), (A=1, C=1), (A=1, C=0) B=0), (A=0, C=1), (A=0, C=0) C=0) C=0)

La donne de test (A=1, B=1, C=1) couvre 3 paires : (A=1,B=1),(A=1,C=1),(B=1,C=1) La donne de test (A=0, B=0, C=0) couvre 3 paires : (A=0,B=0),(A=0,C=0),(B=0,C=0) La donne de test (A=1, B=0, C=0) couvre 2 paires : (A=1,B=0),(A=1,C=0) La donne de test (A=0, B=1, C=1) couvre 2 paires : (A=0,B=1),(A=0,C=1) Reste deux cas disponibles (B=1, C=0) et (B=0,C=1). Ici 6 tests sont ncessaires pour couvrir lensemble des cas.


41


TESTS SYNTAXIQUES

Cette technique de test est peu utilise. Elle peut cependant se rvler utile pour des applications qui ncessitent des donnes d'entre respectant une syntaxe rigide et bien dfinie. C'est le cas des applications qui autorisent un lancement direct par ligne de commande (Exemple : lutilitaire darchivage Winzip). Afin de raliser les tests, il convient : De dfinir la grammaire (la syntaxe de la ligne de commande). De construire un arbre rpertoriant l'ensemble des cas possibles. De construire les jeux de tests ncessaires partir de cet arbre.

Le but est de couvrir tous les nuds (qu'ils soient terminaux ou non).

Logiciel Archivage

Crer une archive

Ajouter fichier(s) une archive existante

1 Fichier

Plusieurs Fichiers

1 Fichier

Plusieurs Fichiers



42


TESTS ALEATOIRESLes tests alatoires se diffrencient des autres tests par leur approche probabiliste. En effet, les jeux de tests sont raliss de manire automatique et alatoire par un produit logiciel. L'avantage est que l'on atteint rapidement 50% de l'objectif des tests. Cependant, ces tests ont tendance plafonner ensuite car il est impossible de gnrer un ensemble de donnes alatoires totalement cohrent.

Satisfaction

Test Dterministe

Test Alatoire

Effort



43


COUVERTURE GRAPHE FONCTIONNELLa couverture du graphe fonctionnel est comme son nom l'indique le parcours complet de tous les nuds, de tous les arcs, de tous les chemins. Tous les lments de l'arborescence du programme doivent tre excuts au moins une fois. C'est une technique qui est trs utile pour les tests IHM (Interface Homme Machine) mais sa modlisation est trs vite complexe.

Source : Cours Test et validation CNAM


44


GRAPHES CAUSE-EFFETCette mthode, concept labor par G.J. Myers, relie les effets d'un programme (les sorties) aux causes (entres). Les causes sont des entres possibles (variables d'entre, actions utilisateurs etc.) et les effets sont les sorties du systme (variable de retour, modification de la base de donnes etc.). Il faut donc identifier les causes et les effets du systme partir des spcifications puis laborer un graphe de cause effet. L'laboration de ce graphe est l'tape la plus difficile : une mauvaise interprtation aurait des consquences directes sur les cas tester. On cherchera si possible rduire ou simplifier ce graphe de cause effet. On pourra ainsi gnrer les donnes de tests pour le couvrir. Exemple de reprsentation :

A1

A2

B1

A3

B2

C1

B3


C1 dpend de B2 , de B3 mais aussi de A1 , A2 et A3 . Le nombre de donnes de test augmente trs rapidement (il est utile dutiliser un tableau de vrit pour reprsenter et tenter de simplifier les cas tester) !


45


APPROCHE STRUCTURELLE (BOITE BLANCHE)Les tests boite blanche sont utiliss lorsque les jeux d'essais dpendent de l'analyse du code source. Pour chacun de ces types de tests, on aura deux approches : L'approche statique. L'approche dynamique.

L'approche statique ne prvoit pas dexcution de code. On passe en revue le code, on estime la complexit de celui-ci. L'excution reste symbolique et l'interprtation abstraite : On sattarde sur la structure du programme. L'approche dynamique est de produire un jeu de donnes de tests en fonction du code source. Ces donnes excuteront un ensemble de comportements et de rsultats qui seront compars avec ceux du cahier des charges. Cette approche est limite par l'excution partielle du programme et de son comportement. Lapproche structurelle permet la dtection d'erreurs indpendantes de l'application et davoir une vue globales des algorithmes. Les tests structurels font une utilisation importante de la thorie des graphes. Elle reste cependant limite du fait de la non excution relle du programme et donc le fait que l'on ne test pas les fonctionnalits.

LES TESTS STRUCTURELS STATIQUESRevue de codes

Une revue de code consiste en un examen dtaill dune spcification, dune conception par une personne ou un groupe de personnes, afin de dceler des fautes, des violations de normes de dveloppement ou dautres problmes. Il sagit dune TECHNIQUE DE CONTROLE plutt que de test. Exemple de contrle : o o o o o o o o o Taux de commentaires Intrt des commentaires Variables non initialises Gestion des indices de tableau Conversion de types Division par zro Terminaison des boucles Sortie dune procdure ou fonction


46


-

Estimation de la complexit

Statistiquement, la complexit dun programme est corrle avec le nombre de ses dfauts : en dautres termes, plus un programme comporte de lignes, plus il a de pourcentage derreurs. Il existe plusieurs faons dapprhender cette notion de complexit. Les mtriques dHALSTEAD Les mtriques dHALSTEAD valuent la complexit lie la distribution des variables et des instructions. La base des mesures est fournie par le vocabulaire utilis : les oprateurs et les oprandes. Formulation : n1 = nombre doprateurs uniques n2 = nombre doprandes uniques (termes, constantes, variables) N1 = nombre total dapparition des oprateurs N2 = nombre total dapparition des oprandes l = n1 + n2 L = N1 + N2 Taille estime du programme = n1(Log2 n1) + n2(Log2 n2) Volume du programme = L Log2 (n1 + n2) Difficult du programme = (n1/2) (N2/2) Nombre derreurs = Volume du programme / 3000

Les mtriques de Mc CABE

Mac CABE tudie le logiciel en analysant le graphe de contrle du programme et calcule la complexit structurelle ou nombre cyclomatique de ce graphe. Le nombre cyclomatique donne une valuation du nombre de chemins indpendants dans le graphe et donc une indication sur le nombre de tests ncessaires. Cette mesure indique la borne suprieure du nombre de tests effectuer pour que tous les arcs soient couverts au moins une fois. Le s Tests : Ltat de lArt Dans la pratique, on admet que la limite suprieure du nombre cyclomatique soit de 30. Cette valeur est dfinie comme un critre de qualit dans le plan qualit (PAQ).

47


Formulation : n = nombre de nuds (blocs dinstructions squentielles) e = nombre darcs (branches suivies par le programme) v = nombre cyclomatique o Dans le cas dune entre et dune sortie v = e-n+2 o Dans le cas de i points dentre et de s points de sortie v = e-n+i+s Exemple : Voici un exemple simplifi dun graphe de flot de contrle.

A

B

C

D

E

FSource : Ralis par Eric LELEU pour illustration

En thorie, il existe 4 cas pour tester lensemble des solutions : ABCDF, ABCEF, ACDF et ACEF. Or selon Mc CABE, il existe 3 chemins : V=7 arcs 6 nuds + 2 = 3 En effet, un seul des 2 cas sera utile parmi ACDF et ACEF (AC, CDF et/ou CEF ayant dj t parcourus). Le s Tests : Ltat de lArt


48

LES TESTS STRUCTURELS DYNAMIQUES

Les tests structurels sont bass sur le graphe de flot de contrle (couverture de toutes les nuds-instructions, de toutes les branches, de tous les chemins). Lobjectif est de produire les donnes de test qui excuteront un certain ensemble de comportements du programme (chemin dans le graphe de contrle).

Exemple : Voici un exemple simplifi dun graphe de flot de contrle.

A

B

C

D

E

FSource : Ralis par Eric LELEU pour illustration

En thorie, il existe 4 cas pour tester lensemble des solutions : ABCDF, ABCEF, ACDF et ACEF.


49


IV LES TESTS ET LA QUALITELe cot des tests est valu lors de lestimation du projet global et est souvent sous estim par rapport lorganisation mis en place sur le projet. En consquence les projets dpassent le budget en ce qui concerne les cots et la dure (les deux tant plus ou moins lis). Des enqutes ont t effectues et rvlent une tendance par rapport aux diffrentes phases dun projet. En exemple aux USA en 1986 une tude mene auprs de 55 entreprises rvle que 53% du budget total d'un logiciel est affect la maintenance. Ce cot est rparti comme suit : 34% maintenance volutive : modification des spcifications initiales ; 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ; 17% maintenance corrective : correction des bogues ; 16% maintenance perfective : amliorer les performances sans changer les spcifications ; 6% assistance aux utilisateurs ; 6% contrle qualit ; 7% organisation/suivi ; 4% divers.

On saperoit que le cot des corrections de bug se situe en second position aprs la maintenance volutive et quel reprsente une part non ngligeable du budget dun logiciel. Pour faciliter et fiabiliser lestimation des projets des mthodologies ont t dvelopps pour valuer la complexit de lenvironnement et du logiciel. Cest le cas du modle COCOMO pour COnstructive COst Model estime quun projet est rparti comme suit : 15 20% programmation 40% spcification et conception 40% validation et vrification

Ce nest pas comme il est souvent constat la programmation qui require le plus dnergie mais bien la dfinition du produit et son contrle. Le s Tests : Ltat de lArt Cette mthode dfinit des mtriques et des rgles afin dvaluer de manire plus fiable le cot dun logiciel. Nous constatons que lestimation dun logiciel et tout aussi difficile que celle de le tester et ncessite tout comme les tests des mthodes et des outils logiciels permettant daider la dcision finale. Ceci s'explique par l'augmentation de la complexit des logiciels avec la monte en puissance des performances du matriel.


50

LES CONSEQUENCES DE CET ETAT DE FAITFace au bug le client a un choix restreint daction selon la provenance du bug : matriel, logiciel, performance Il peut faire appel son service informatique ou la socit ditrice de logiciel ou la socit de service. Dans le cas dun contrat, une question se pose immdiatement qui va supporter le cot de correction de lanomalie ? La lgislation est peu dveloppe sur le sujet. Cest le contenu du contrat qui fait force le loi.

LES EDITEURSLes diteurs fournissent des logiciels dont ils ont dfinies les fonctionnalits au pralable qui savrent figs dans le temps jusqu la version suivante. Lachat doit donc se faire en connaissant les limites du produit tant fonctionnel quau niveau fiabilit. Le fournisseur dlivre dans ce cas une licence qui donne le droit dutiliser le produit en ltat. Il se dcharge de toutes responsabilits lies lutilisation de son produit et de ces consquences. Lditeur nayant pas connaissant du contexte de dploiement de son produit. Exemple de garanties et responsabilit des diteurs :

Le logiciel et la documentation qui laccompagne sont fournis dans ltat o ils se trouvent et sans aucune garantie. En cas de support dfectueux, un autre exemplaire sera dlivr par la socit sur demande. La socit dcline toute responsabilit dcoulant dun dommage direct ou indirect en relation avec lutilisation ou limpossibilit dutilisation de le logiciel , y compris les dommages entrans par la perte de bnfices, linterruption des activits, la perte dinformations et autres, et ce mme si la socit a t inform de la survenance ou de lventualit de tels dommages. Comme lacheteur nachte pas le logiciel, mais une licence dutilisation, lditeur retire sa responsabilit sur son exploitation.


51


LES SOCIETES DE SERVICESLe cas dune socit de service dingnierie informatique est diffrent puisquelle offre un service son client de type cl en main. Elle est pour des raisons marketing, stratgique et conomique dans le devoir de fournir une prestation qui rpond aux besoins du client. Elle a connaissance du contexte de dploiement du produit puisque cest lune des contraintes incontournables pour rpondre au mieux la dfinition des besoins labors par le client. Elle ne peut donc pas, comme lditeur, se dcharger de sa responsabilit de qualit du produit mais aussi de qualit de la rponse donne au cahier des charges mis par son client. Elle va donc mettre un contrat allant dans ce sens et dfinissant les actes auxquels elle sengage ainsi que les limites de sa prestation. Elle va donc par ce contrat se protger face aux exigences volutives du client mais aussi permettre au client dexiger la prestation et la qualit quelle met en avant. Le client va donc sappuyer sur une norme ou des mthodologies, nous prendrons pour exemple la norme ISO9000. Le but de cette norme est de donner au client une garantie sur le produit ou le service offert par son fournisseur et davoir un recours en cas de litige. Elle dfinit tous les tats du processus de conception mais aussi lassurance que lentreprise rpond une politique qualit en ce qui concerne son organisation. Deux parties sont donc dfinies : le produit fabriqu. l'organisation et le management.

Cette norme dfinie une qualit de travail, une mthode, une traabilit ainsi que des mtriques permettant de mesurer la qualit de la prestation offerte et les actions a mener au niveau des deux partenaires pour atteindre le niveau de satisfaction propos la signature du contrat. Le client pourra galement sappuyer sur un autre le PAQ : Plan dAssurance Qualit fourni par le prestataire. Ce PAQ dfinit prcisment le primtre dintervention du fournisseur et leurs dlais mais aussi les obligations et les devoirs de chaque partenaire et les limites de lintervention de lune ou lautre des parties. Et permet donc de justifier les surcots ou les actions mener pour les viter. La socit de service peut par exemple fournir une prestation supplmentaire daccompagnement llaboration dune plate-forme de tests client ou au dploiement et formation des utilisateurs du client dans les cas les plus complexe ou si le client ne la pas insrer dans son contrat. Certains PAQ dfinissent des mtriques sur la base des quels le client peut exiger en accord avec son fournisseur de dfinir des pnalits en cas de dpassement de seuils pralablement dfinis.


52


EXEMPLE: INDICATEURS QUALITE

Indicateur

RDL RESPECT DES DELAIS DE LIVRAISON DES LIVRABLES Respecter les dlais de livraison des livrables (documentaires, logiciels). RDL Ecart dates relles / prvues doit tre infrieur ou gal 5j Analyse des causes et actions correctives

Objectif

Mode de calcul

Action Pnalit

Indicateur Objectif

RCM RESPECT DES CONTRAINTES ET DES METHODES Respecter les mthodes et outils de gestion de projet du logiciel de dveloppement utilis et les contraintes du produit RCM - Pour chaque thme, respect O/N Prise en compte des remarques par les Prestataires, avec correction sous un dlai de 5 jours

Mode de calcul Action

Pnalit

Indicateur Objectif Le s Tests : Ltat de lArt Mode de calcul

RDC RESPECT DES DELAIS DE CORRECTION Respecter les dlais de correction des anomalies logicielles RDC - Anomalie bloquante corrige sous 24h , les autres types danomalies sous 48h Analyse des causes et actions correctives

Action Pnalit

53


La ngociation et la mise au point du contrat est, comme on vient de le voir, primordiale et ncessite de passer un temps important pour le bon droulement du projet. Dans cette exemple la mise en uvre des pnalits applicables par le matre duvre dans le cas de non respect des facteurs qualit, dans le cas o le Prestataire est seul responsable, reste prciser par rapport au contrat ngoci. Lensemble des 5 critres suivant donne lassurance qualit : la confiance du client, rpondre exactement ses besoins et attentes, amliorer la performance, obtention dune meilleure rentabilit de l'entreprise Amliorer l'accs au march.

La norme ISO dfinit la qualit comme tant les exigences du client en terme de service et de normes de produit. Elle incite donc les entreprises rpondre aux exigences du client pour obtenir cette certification. Elle reprsente un gage de qualit obligatoire et une mthodologie de lorganisation auquel tendent toutes les socits commerciales et industrielles. Cette certification ISO 9000 est obtenue, par une entreprise, si elle rpond aux 20 conditions suivantes : Responsabilit de la direction Systme Qualit Revue de contrat Matrise de la conception Matrise des documents Achats Matrise du produit fourni par le client Identification et traabilit Matrise du processus Contrle et essais Matrise des quipements de contrle, de mesure et d'essai Etat des contrles et essais Matrise du produit non conforme Actions correctives et prventives Manutention, stockage, ... Enregistrements relatifs : la qualit Audits qualit internes Formation Prestations associes Techniques statistiques

Ces 20 conditions montrent limpact psychologique et la qualit du travail quest en droit dattendre le client. Il dmontre le degr dorganisation dune entreprise certifi. Dautres mthodologies sont aujourdhui utilises pour atteindre le zro dfaut : CMMI, ITIL.


54


Le but de ce dossier nest pas de dcrire ces diffrentes mthodes ou normes. Ce paragraphe montre limportance des tests et des outils qui les accompagnes face aux exigences du client qui utilise ces mthodes ou ces normes pour obtenir ce qui lui est d. La norme ISO9000 et les mthodes CMMI ou ITIL sont les moteurs de la qualit et incitent contrler, tester. Lenvironnement de plus en plus complexe du systme dinformation contribue chercher des solutions pour augmenter la qualit, la fiabilit et la robustesse du systme dinformation. Elles ont donc contribues aux dveloppements des outils de tests.


55


V LES OUTILS DE TESTLes outils de tests que lon trouve sur le march peuvent tre classs en cinq groupes : Le premier concerne les outils daide la ralisation des tests. o Capture et r excution des scripts raliss via une IHM. o Sauvegarde des tests et des rsultats associs. o Gnration de scripts de tests en fonction des langages et des plateformes Le second groupe concerne les outils de campagne de tests. Les outils de gestion des plans et campagnes de test servent dfinir, organiser et conduire les campagnes de tests. Ils doivent donc s'interfacer avec tous les outils qui interviennent dans les tests. Le troisime groupe concerne les tests fonctionnels (boite noire). Les tests concernent l'analyse des spcifications du logiciel, sans tenir compte du code source. Le primtre des contrles englobe les interfaces utilisateurs, les API, la gestion des bases de donnes, la scurit et le rseau. Il vrifie la conformit du fonctionnement dun systme vis--vis des exigences de lutilisateur (se rfre au cahier des charges). Le quatrime groupe concerne les tests structurels (boite blanche). Ces outils permettent de valider ce que fait le logiciel test. Ils sont donc complmentaires aux outils de tests fonctionnels qui vrifient, eux, ce que doit faire le logiciel. Ces pourquoi des diteurs ont cr des suites comprenant ces deux types de tests. Le cinquime groupe concerne la performance des logiciels dvelopps, quelque soit lenvironnement : applications Web, intranet ou des Web services.

LES OUTILS DAIDE A LA REALISATION DES TESTS

Appels "automates de tests", ces outils prsentent des fonctionnalits communes : Capture et r excution des scripts raliss via une IHM (=Interface homme machine). Sauvegarde des tests et des rsultats associs. Gnration de scripts de tests en fonction des langages et des plateformes. Le s Tests : Ltat de lArt Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation

56

MERCURY WINRUNNER ET QUICKTEST PRO DE MERCURY QUALITY CENTERMercury Quality Center fournit un ensemble d'outils Web permettant de grer et d'automatiser les tests de qualit logicielle dans un large ventail d'environnements applicatifs. Mercury Quality Center comprend des produits leaders tels que Mercury TestDirector, Mercury QuickTest Professional et Mercury WinRunner. WinRunner et QuickTest Professional sont des automates de nouvelle gnration. Cette suite permet de crer un ensemble de tests, de le grer en testant l'application tout au long du cycle de dveloppement et de coordonner les rsultats. Pour dfinir un test, Mercury WinRunner enregistre simplement les actions de l'utilisateur sur l'interface du programme traiter (processus mtier type : commande d'un article saisi d'un client...). Les scripts gnrs peuvent tre modifis pour rpondre aux besoins de tests les plus complexes. Ensuite, les testeurs peuvent ajouter des points de contrle, qui comparent les rsultats attendus et rels obtenus lors de l'excution du test. Il est mme possib

tests_v10.00

Documents

tests dans

tests unitaires

tests dintegration

necessite des tests

definitions des tests

tests et la qualite

la realisation des tests

cycles tests dintgration