Quadra Informatique

TESTS ET VALIDATION DU LOGICIEL

Tests et Validation du logiciel Etat de lart

Intervention Stphane CALIMET, Philippe FIRMIN, Eric LELEU Juin 2009 - CNAM de Lille NFE 209 / 210 Audit et Gouvernance des Systmes dInformation

Prambule

Quelques exemples de Bugs

Dfinitions des tests Les classes de dfaut

Les difficults lies aux tests

Les diffrentes faons de classifier les tests Quelques principes La stratgie de tests

Prambule

Les tests existent depuis toujours (mauvaise perception). Prise de conscience actuelle de la part des socits et notamment des directions informatiques (risque de dysfonctionnement, perte financire, retard). Les tests rassurent et permettent de palier aux erreurs humaines. Le sujet des tests est vaste. Nous avons tenter dans cette prsentation de vous en prsenter les principaux aspects (gnralits, techniques et outils). Notre tude sera votre disposition sur le site http://home.nordnet.fr/~ericleleu

La politique de tests est aujourdhui une dimension incontournable de la gestion de projet.

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.

Les bugs sont omniprsents et ont parfois des consquences dramatiques.

Dfinitions des tests

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

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 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.

Les classes de dfaut

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.

Les difficults lies aux tests

Impossible de raliser un test exhaustif (variables) Qualit des tests dpend donnes utilises Impossible de supprimer lerreur humaine Difficults dordre psychologique, culturel Manque dintrt pour les tests Taille et complexit des programmes Diffrence entre environnement de dveloppement et de production Perte dinformation naturelle

Difficult formelle : pas dalgorithme capable de prouver lexactitude dun programme

Concernant la perte dinformation

Les diffrentes faons de classifier les tests

Il nexiste pas de classification officielle

Chaque ouvrage, chaque auteur, chaque site dfinit sa manire les diffrentes techniques de tests.

Selon le mode d excution

Le test Manuel :

Les tests sont excuts par le testeur qui 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).

Selon les modalits du test

Statiques :

Les tests sont raliss par l'humain (testeur), sans machine, par lecture du code dans le but de trouver des erreurs (revue de code).
Dynamiques : On excute le systme de manire tester lensemble des caractristiques. Chaque rsultat est compar aux rsultats attendus.

Selon les mthodes de tests

Structurels (Bote blanche) :

Les tests structurels reposent sur des analyses du code source.

Fonctionnels (Bote noire) : Les tests fonctionnels reposent sur une spcification 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.

Selon les niveaux de tests

Il 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.

Selon les caractristiques des 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.
De performance :

Permet d'valuer la capacit du programme fonctionner correctement vis--vis des critres de flux de donnes et de temps d'excution.

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

Quelques principes

- Si possible faire tester par un autre dveloppeur.

- 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).

La stratgie de tests

- Une stratgie de tests peut reprsenter 50% de la charge totale dun projet - La stratgie de test doit tre intgre au processus de dveloppement du logiciel. 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 processus de test Finalement, la stratgie de tests tient compte : Des mthodes de spcification, de conception Du langage de programmation utilis Du type dapplication (temps rel, base de donnes) Lexprience des programmeurs Une technique de tests adapte et puissante restera sans effet si elle ne fait pas partie dune stratgie de tests.

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,) Analyse et conception Evaluation des risques Gestion des incidents Evaluation et reporting Clture (recette ou arrt des tests) Bilan projet Amlioration des processus et mutualisation

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 : Dfinir lorganisation mettre en place (quipe de tests : Testeur, CP qui 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.

La stratgie de tests vise rendre leffort de test efficace

Il existe autant de plan de tests que de phases de qualification du produit : 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. 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. Un plan de test doit : Dfinir les lments tester et lordre dans lequel ils doivent tre tests (planifier) Dcrire lenvironnement de tests. Dfinir la faon dont les tests vont tre mens (procdures rptable : processus exacts mener, lhistorisation, la traabilit, le reporting, le suivi, le contrle) Dcrire et constituer les fiches de tests. Lensemble des fiches de tests constitue le dossier de tests. Fixer les critres darrt des tests

Rapport de test (ensemble des comptes rendus de rapport de tests) 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 : Excution des fiches de tests (effectuer les actions dcrites). Analyser les rsultats obtenus Emettre des fiches de non-conformit si ncessaire

Il sagit de coupler intelligemment la gestion des tests et la gestion des corrections (incidents).

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.

PRESENTATION STEPHANE

Tests et Cycles de vie Les tests UNITAIRES Les Tests dINTEGRATION Les tests de CHARGE Les tests de VALIDATION

Tests et Cycles de vie

3 Cycles de vie principaux - Cascade - En V - En spirale

Cycle en Cascade

Dfinit les phases squentielles A la fin de chaque phase, des documents sont cres pour en vrifier la conformit Si c'est bon on passe la phase suivante Si ce n'est pas bon, on retourne en arrire (Feedback)

 Avantages : Qualit des livrables Calendrier plus facile laborer Un seul fil directeur

Inconvnients : Difficult de revenir en arrire Temps de raction plus long Effet tunnel

Cycle en V

Cr suite au manque de ractivit du modle en cascade. Il part du principe que les procdures de vrification de la conformit doivent tre labor ds les phases de conception Le client connait son besoin dans le dtail Standard depuis les annes 1980

 Avantages : Meilleur temps de raction Anticipation des tapes En cas de problme, permet de limiter le retour aux tapes prcdentes

Inconvnients : Conception fortement lie la ralisation Moins adapt au dveloppement logiciel Risque deffet tunnel

Cycle en Spirale

Il est bas sur une approche et une valuation des risques. Un risque identifi est assign dune priorit. Un prototype possde son cycle de vie propre
Le cycle en spirale couvre lensemble du cycle de vie de dveloppement mais ajoute une dimension managriale et donc non technique

 Chaque cycle de la spirale comprend 6 phases :

Analyse du risque Dveloppement dun prototype Test du prototype Dtermination des besoins Validation des besoins Planification du prochain cycle

 Avantages : Cahier des charges respect au pied de la lettre Validit des besoins

Inconvnients : Calendrier et budget souvent irralistes (on ne sait chiffrer quun cycle la fois) Problme pour les composants externe Limit aux projets innovants (tude des risques)

Conclusion sur les cycles de vie

Chaque cycle de vie contient les mmes grandes phases du projet : Analyse du produit Phase de conception Phase dintgration Phase de validation

Les Tests UNITAIRES

Dfinition

Vient du fait quune partie du code est appel Unit Ce type de test va vrifier un module du code et quil fonctionne de manire indpendante du reste Respect aussi des spcifications fonctionnelles Ils peuvent tre manuels ou automatiss par des logiciels

Formalisme

On va crer une fiche de test unitaire qui contient une liste (ou aide mmoire) pour les grandes actions Elle permet de prparer les tests Chaque analyste ou chef de projets doit la remplir afin dassurer un passage en recette dans les meilleures conditions Donne une garantie de qualit lors du dveloppement (ce nest pas une contrainte mais un outil !)

Exemple de fiche de test

 Pour raliser des tests unitaires il nous faut : des jeux de donnes (fictives, de production, ancien jeux de tests) des ressources (documents de spcifications, scnarios, fiches de tests, tests prcdents) Une dmarche

Les diffrentes dmarches : Analyse statique Analyse dynamique structurelle

Analyse dynamique fonctionnelle

Boite noire Boite blanche

Analyse Statique

Cette notion danalyse permet dobtenir des informations sur le comportement du programme sans rellement lexcuter On utilise des mthodes comme les nombres cyclomatiques, la mesure de Halstead

Analyse Dynamique Structurelle

Consiste vrifier la structure du code ainsi que les variables On parcours tous les nuds, les arcs, et chemins du programme On peut vrifier ainsi si un test If Then Else nest pas utilis

Analyse Dynamique Fonctionnelle

Consiste vrifier le service rendu (la fonction) mais pas comment il est rendu On valide les rgles de gestion La difficult rside au choix des donnes de tests pour obtenir les rsultats attendus

Bote NOIRE

On vrifie que les sorties obtenues sont celles prvues pour les donnes entres Le fonctionnement interne nest pas accessible

Souvent utilis pour les tests de non rgression, de robustesse et de charge

Bote BLANCHE

On valide le code et on vrifie quil ny a pas de plantage

On ne teste pas le fonctionnel mais tous les chemins possibles du programme

Les tests dINTEGRATION

Dfinition

On regroupe chaque partie teste unitairement afin dtablir une nouvelle version du produit Le test dintgration a pour but de tester que tout fonctionne ensemble Il existe une intgration incrmentale et une intgration globale

 Il existe plusieurs mthodes dintgration : Big bang Top Down (haut en bas) Bottom up (ascendante) Mixte Par paquet

Big Bang

Le principe est dintgrer tous les composants en une seule tape. Lintgration est rapide mais valable que pour les petits projets Trop de risques pour les gros projets

Approche Top Down

On droule le programme de haut en bas. Les modules sempilent les uns aux autres. Des bouchons simulent les traitements. Les modules doivent tre les plus petits possible Avantages : Dtection prcoce des dfauts darchitecture Facilit de comprhension Inconvnients : Crer des bouchons prend du temps Effort de simulation des composants absents (risque derreurs) Tests tardifs des couches de bases

Approche Bottom Up

On droule le programme de bas en haut. Les modules fondamentaux sont tests en premier. Des bouchons simulent les traitements. Il est ncessaire de dfinir les fonctionnalits indispensables et prioritaires aux autres. Avantages : Faible effort de simulation Dfinition de jeux dessais plus facile Fonctionnalits basses plus souvent testes Inconvnients : Dtection tardive des erreurs majeures

Intgration Mixte

Cest une combinaison des approches Bottom up et Top down. On lappelle de temps en temps bote grise.

Avantages : Planning de dveloppement qui gre les composants dans lordre de cration Les composants les plus critiques sont intgrs en premier

Inconvnients : Difficult dintgration due la mixit des mthodes

Intgration par Paquet

On dcompose le programme par fonctionnalit ou criticit si les modules le permettent.

Les Tests de CHARGE

Dfinition

On expose lapplication des conditions dexploitations pour valider le systme.

Objectifs : Tester la performance Maintien des fonctionnalits sur une monte en charge Fiabilit (plateforme, BDD)

Principaux type de tests de charge :

-Test de performance -Test de dgradation des transactions -Test de stress -Test dendurance, de robustesse, de fiabilit -Test de capacit, de monte en charge

 Quand mener les tests de charge ? Le plus tt possible dans le processus de dveloppement fin de mettre en vidence rapidement les dfauts dinfrastructure.

Les Tests de VALIDATION

Objectifs

Vrifier que toutes les exigences du cahier des charges soient respectes. Ils ont lieu immdiatement aprs les tests dintgration. 2 approches : Identifier et tester toutes les fonctions du logiciel Tester les caractristiques du logiciel (interfaces)

Principales techniques de validation

Approche fonctionnelle (bote noire)

Approche fonctionnelle classique Analyse Partitionnelle Tests aux limites Tests combinatoires Tests syntaxiques Tests alatoires Couverture de graphe fonctionnel Graphe cause effet

Approche structurelle (bote blanche) Tests structurels statiques Tests structurels dynamiques

PRESENTATION PHILIPPE

Les outils de tests Le classement Les outils daide la ralisation Les outils de campagne de tests Les outils de tests fonctionnels Les outils de tests structurels Les outils de tests de performance

Les outils de Tests

Pourquoi un outil de test :

Lexemple

du triangle : en entre 3 entiers et en sortie triangle isocle, scalne ou quilatral.

14 cas de tests : GJ Myers The Art of Software Testing - 1979

Rsultats sur des dveloppeurs expriments 7,8 en moyenne sur 14.

Cot dun test est de 30% 60% du cot de dveloppement

Pourquoi un outil de test :

Lenvironnement du SI est toujours plus complexe La programmation volue et implique plusieurs langages Dtection des bugs plus difficile, dbuggeur difficile mettre en uvre. Lexigence qualit du client SI ou fournisseurs engagement qualit Base de la rponse : ISO20000, CMMI, ITIL Le SI, les fournisseurs cherchent une rponse pour automatiser les tests.

Le Classement

Classs en 5 groupes doutils :

Les outils daide la ralisation des tests Les outils de campagne de tests

Les outils de tests fonctionnels (boite noire)

Les outils de tests structurels (boite blanche)

Les outils de tests de performance

Les outils daide la ralisation

Les fonctionnalits communes :

Capture et r-excution des scripts raliss via une IHM Sauvegarde des tests et des rsultats associs Gnration de scripts de tests en fonction des langages et des
plateformes.

MERCURY WINRUNNER et CENTER HP depuis 2006

QUICK TEST PRO

de MERCURY QUALITY

Mercury TestDirector Outils web et

automatisation des tests : environnements applicatifs diffrents Automates de tests de nouvelle gnration Crer, grer un ensemble de tests et coordonnes les rsultats

Enregistre les actions de l'utilisateur, ajout de points de contrle.

Fonctionne exclusivement sur plateforme Microsoft Windows.

WinRunner (script TSL ) a t supplant par QuickTest Pro (VBScript +

interface ergonomique )

Limportance du march :

Mercury Quality Center reprsente un CA

pour 3000 salaris

de 686 millions de dollars

HP
HP HP

reprsente un CA dans la vente de matriel avec 87 milliards de dollars en 2005.

rachet Mercury pour 4,5 milliards de dollars en 2006 CA du logiciel 2 milliards avec ce rachat. consolide son offre de logiciels et concurrence IBM et Computer Associate

Rational Robot de IBM

Automatiser les tests de fonctionnalit et de rgression des applications :

.NET
Java Web toutes les commandes VS.NET (VB.NET, J#, C# et Managed C++)

Et autres applications graphiques.

 Outil de test de fonctionnalits, de rgression et de configuration

polyvalent

Automatisation aise des tests manuels Dtection du plus grand nombre d'erreurs Scnarios de tests adapts aux objets communs Intgration

(menus, listes) et spcialiss aux objets spcifiques (environnement de dveloppement)

d'un outil de gestion des tests, suivi des erreurs : Team Unifying Platform

QARun de Micro Focus

mainframe, client/serveur au Web

De la gestion des tests la validation, du test fonctionnel au test de

charge, les outils de la gamme QACenter sont :

Qualit de code (DevPartner) Suivi des dfauts (TrackRecord) Gestion des exigences (Reconcile, Optimal Trace)

Tests fonctionnels (QARun, TestPartner, QADirector)

Tests de performance (QALoad)

Abbot (Open Source)

Spcifique aux IHM raliss en Java (Abbot signifie "A Better Bot")
Linterface Costello permet d'enregistrer des actions Une API Java est disponible pour Junit.
iRise Studio de iRise

Permet

la dfinition, les tests et la validation des fonctionnalits de solutions Web avant tout dveloppement

Propose une approche diffrente : on simule avant de livrer le produit

ce qui permet de mieux coller aux rsultats attendus

Les outils de campagne de tests

Les principales fonctionnalits de ce type doutils sont :

La dfinition de campagnes de tests Lhistorisation des rsultats La gestion des tests de non rgression Ils servent dfinir, organiser et conduire les campagnes de tests Interfaage avec tous les outils. Ne sont pas des automates de tests Suites Intgres doutils de gestion de tests et automates viter la
concurrence.

TestDirector de Mercury Quality Center HP Une seule application Web se charge de l'intgralit de la procdure de test :

Gestion des besoins Planification

laboration
Organisation et excution des tests Gestion des anomalies Analyse de l'tat du projet La documentation

Salom TMF (Open Source) Un des rares outils libres de gestion de tests

Organisation du plan de tests sous forme d'arbre hirarchique

Organisation des tests en campagnes, pour l'excution Possibilit d'intgrer et d'excuter des tests automatiques (JUnit, Abbot,
Beanshell).

Gestion des anomalies via Bugzilla ou Mantis Production de documents au format HTML. Architecture pouvant inclure des plugins (connexion Junit, planification
des tests-cronExec-...).

C'est un logiciel multi plateformes (Java).

Test Manager de Soft Edition.Net Se prsente sous forme d'une application intranet. A pour but :

De crer De planifier Dorganiser les diffrentes sessions de tests Gestion documentaire Apport mthodologique pour des quipes de tests

 Liste des fonctions de Test Manager :

Aide la cration et lorganisation des documents de test Aide la cration des plans et stratgies de tests Dimensionne, organise et cre les campagnes de tests Dlivre des rapports prcis au responsable pour le suivi Suivi de la production, des campagnes et de la couverture fonctionnelle tablit le lien entre les documents et les spcifications Donne un statut en temps rel des campagnes de tests Point dintgration avec les demandes de fonctionnalits Point dintgration avec les anomalies

QADirector de Micro Focus : permet de tester compltement une application avec une rutilisation des tests, un partage des informations et une facilit dutilisation. Planification des tests

Excution des tests Variation des environnements de test Analyse dynamique de l'application teste Analyse des rsultats des tests Soumettre les problmes

Les outils de Tests Fonctionnels

 Vrifier la conformit du fonctionnement dun systme vis--vis du

cahier des charges.

Ces outils vitent la cration "manuelle" de scripts de tests

Offre des fonctionnalits automatiques (gnration de scripts de tests,
de rapports des rsultats attendus et atteints ou non) et des indicateurs graphiques

Ces outils de gnration automatique de tests ncessitent une

modlisation fonctionnelle

Ces outils sont une valeur ajoute pour les projets de grande taille

Leirios Test Generator de LEIROS

Rduction de plus de 30% de l'effort de conception des tests fonctionnels Avec une couverture des tests 2 5 fois suprieure.

Une modlisation fonctionnelle partir des Spcifications Techniques

Utilisation du modle par "gnrateur de tests LTG" pour crer les cas de tests Lutilisateur paramtre simplement ses critres de couverture Le "gnrateur de scripts LTG" compose alors les scnarios de tests Les scripts ainsi crs sont excuts dans lenvironnement ddi (banc de test).

Conformiq Test Generator de Conformiq Software

Permet d'effectuer des tests sur les problmes de synchronisation Cration d'une plate-forme commune pour les concepteurs et testeurs Large couverture de test Maintenance simple de l'environnement de test - modles de test
graphiques.

Rsultats des tests et des couvertures de tests automatiss Permet de gnrer des scripts de test hors ligne

Les outils de tests structurels

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.

Cest pourquoi des diteurs ont cr des suites comprenant ces deux types de tests.

C++test, .TEST, Jtest, SOAtest et Insure++ de PARASOFT

Dveloppe et commercialise des outils daide la dtection des erreurs

dans les logiciels.

Produits lis au dveloppement orient objet et web Bass sur la mthodologie AEP (Automated Error Prevention), ces outils
mettent en uvre une dmarche de prvention.

La technologie Bug Detective rvle les bugs lexcution en pistant et

simulant les chemins dexcution automatiquement

Rational Test RealTime de IBM

Solution multiplateforme pour les langages C, C++, Java et Ada Produit particulirement adapt pour les applications embarques ou
les autres types de produits informatiques nomades

Prise en charge des applications critiques et confidentielles embarques Pro activit pour dboguer, dtecter et corriger les erreurs avant
qu'elles n'affectent le code de production

xUnit : JUnit, PHPUnit, CPPUnit, PyUnit,

Propuls Le

par le succs de l'Extreme Programming (XP), le Test-Driven Developpement ou TDD est devenu une vidence principe du TDD est donc, avant mme d'crire le code d'une fonctionnalit, d'crire le test pour ce futur code

Le code de la fonctionnalit devra toujours passer correctement le test

avant de pouvoir valider celle-ci.

JUnit

4.0 teste le code au moyen d'assertions, simulant diverses situations possibles

Les outils de tests de performance

 Les tests de performances sont mens pour des sites Web ou Intranet

Rpondre aux exigences de performance daccs au site

Les outils de tests de performance proposent souvent :

Le test de monte en charge

La simulation d'un environnement spcifique

Lvolution agressive de l'accs aux ressources

WAPT de SoftLogica

Enregistre des scnarios de tests Les rejouer volont Fait varier : le nombre d'utilisateurs, l'intervalle entre chaque test
Le principe :

Simule des adresses IP htroclites Paramtrages cookies, donnes d'entre pour diffrentes

pages, nom et mot de passe, vitesse de connexion et son propre "chemin" dans l'application

Temps alatoire entre les "clics d'utilisateurs" : ralisme de lutilisateur

virtuel

Siege (Open Source)

Simuler nombre de connexions sur un site web Ne dispose pas d'une interface utilisateur ( la diffrence de WAPT) Un scnario en lisant une liste d'URL partir d'un fichier Stresser une seule URL avec un nombre dfini d'utilisateurs Un utilitaire de capture de trafic Sproxy
permet de faire varier les tests

JMeter (Open Source) du groupe Apache

Outil de tests de performance pour ressources statiques ou dynamiques Simuler de lourdes montes en charge : serveur/rseau Mesurer les performances de sites Internet, serveurs FTP, BDD, Scripts
Perl, objets java

Autres Outils :

Performance Center de Embarcadero, Mercury LoadRunner de Mercury Quality Center HP , QALoad de Micro Focus

Bilan et perspective

-Les tests ont volu au fil des annes : - De 1960 1980, il sagissait dune mise au point. - De 1980 1990, les tests cherchaient uniquement trouver des erreurs. - Depuis 1990, les tests se veulent prventifs. - Les applications sont de plus en plus complexes, les volumes de donnes sont de plus en plus grands Il tait oblig que les tests occupent nouveau au devant de la scne (Nombreux outils, Certaines socits ont leur propre structure de tests) - LExtreme programming (Mthode agile de gestion de projets) qui a compris et intgr les tests dans son cycle itratif de dveloppement. -Mme le Cloud Computing, qui est un concept mergent est impact par ce nouvel lan pour les tests (nuages de serveurs) : on parle dj de HaaS (Human as a Service) qui consiste externaliser le capital humain ! Autrement dit, les tests !

Conclusion

Nous avons tent de prsenter le plus simplement possible ce vaste sujet des tests.
Il nexiste pas de techniques meilleures que dautres : Tout dpend de nos besoins, de nos objectifs Rien nempche de combiner plusieurs techniques. Cest ce que nous prconisons dailleurs. Nous avons vu quaujourdhui que les tests faisaient lobjet dune pratique encore trop souvent artisanale mais que dans un futur proche, les tests seront une activit rigoureuse fonde sur des modles et des thories et quelle sera de plus en plus automatise. Il ne fait aucun doute que la politique de tests est aujourdhui une dimension incontournable de la gestion de projet.

Nous vous remercions de votre attention. Avez-vous des questions ?