Tests V10.00

Les Tests : Ltat de lArt
Tests et Validation du logiciel
CNAM 2008 / 2009 - CENTRE REGIONAL DE LILLE NFE209 AUDIT ET GOUVERNANCE DES SYSTEMES DINFORMATION
AUDITEURS
AUDITEUR
Stphane CALIMET Philippe FIRMIN Eric LELEU
NUMERO DAUDITEUR
NPC 008961 NPC 007654 NPC 008029
HISTORIQUE DES MODIFICATIONS
DATE
08/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
AUTEUR
S. 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
DESCRIPTION
Cration 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
VERSION
V_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
Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation
LES TESTS : LETAT DE LART

TESTS ET VALIDATION DU LOGICIEL
SOMMAIRE
PREAMBULE : NECESSITE DES TESTS ......................................................................... 5 I - INTRODUCTION AUX TESTS LOGICIELS .................................................................... 6 1 QUELQUES EXEMPLES DE BUGS ........................................................................ 6 2 LES DEFINITIONS DES TESTS .......................................................................... 6 3 LES CLASSES DE DEFAUT ................................................................................ 8 4 DIFFICULTES LIEES AUX TESTS ......................................................................... 8 5 LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS ..............................................10 LE MODE 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
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 ..............................................................................60
IRISE
STUDIO DE IRISE .................................................................................60
LES OUTILS DE CAMPAGNE DE TEST ...............................................................61 TESTDIRECTOR DE MERCURY QUALITY CENTER - HP -..............................................61 SALOM TMF (OPEN SOURCE) .........................................................................63 TEST MANAGER DE SOFT EDITION.NET ...............................................................64 QADIRECTOR DE MICRO FOCUS ........................................................................65 LES OUTILS DE TESTS FONCTIONNELS ............................................................66 LEIRIOS TEST GENERATOR DE LEIROS ...............................................................66 CONFORMIQ TEST GENERATOR DE CONFORMIQ SOFTWARE ........................................69 MERCURY FUNCTIONAL TESTING ET MERCURY SERVICE TEST DE MERCURY QUALITY CENTER .72 AUTRES OUTILS DE TESTS FONCTIONNELS.............................................................75 LES OUTILS DE TESTS STRUCTURELS .............................................................79 C++TEST, .TEST, JTEST, SOATEST ET INSURE++ DE PARASOFT ............................79 Le s Tests : Ltat de lArt RATIONAL TEST REALTIME DE IBM ....................................................................80
XUNIT
: JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC.................................................80
LES OUTILS DE TESTS DE PERFORMANCE ........................................................82 WAPT DE SOFTLOGICA..................................................................................82 MERCURY LOADRUNNER DE MERCURY QUALITY CENTER HP .....................................83
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
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).
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
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.
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.
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...
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 TEST

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

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

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.
LES CARACTERISTIQUES DE TEST

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

Source : 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.
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
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.
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.
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).
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
Source : Ralis par Eric LELEU pour illustration
29
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
30
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).
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
32
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.
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 ?
37
5 LES TESTS DE VALIDATION
PREAMBULE
Les 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 CLASSIQUE

L'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 PARTITIONNELLE
L'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 2
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 LIMITES

L'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 ALEATOIRES
Les 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 FONCTIONNEL

La 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-EFFET
Cette 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 STATIQUES

Revue 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.
F
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.
F
En thorie, il existe 4 cas pour tester lensemble des solutions : ABCDF, ABCEF, ACDF et ACEF.
49
IV LES TESTS ET LA QUALITE

Le 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 FAIT

Face 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 EDITEURS
Les 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 SERVICES

Le 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 TEST

Les 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 CENTER

Mercury 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 possible de vrifier les valeurs des bases de donnes afin de garantir la prcision des transactions et l'intgrit des bases de donnes, en mettant en vidence les enregistrements qui ont t mis jour, modifis, supprims et insrs. Lors de l'excution des tests, Mercury WinRunner fait fonctionner l'application automatiquement, simulant un utilisateur rel excutant chaque tape du processus mtier. Cet outil fonctionne exclusivement sur plateforme Microsoft Windows. Pourquoi deux versions d'un mme type d'outil chez le mme editeur ? WinRunner existe depuis 1995. La premiere version de QuickTest Pro date de 2002. Ce dernier a t ralis comme la suite logique du premier englobant ses fonctionnalits et rajoutant les siennes. A la base QuickTest Pro avait t cre parce que WinRunner grait les environnements Web. WinRunner a fondamentalement t supplant par QuickTest Pro. Le s Tests : Ltat de lArt WinRunner est plus complexe mettre en oeuvre, son langage de script (TSL) est propritaire. QuickTest Pro utilise le mme langage (par souci de compatibilit) mais aussi VBScript largement plus rpandu. L'interface de QuickTest Pro est plus ergonomique utiliser, facilement manipulable par point and click et donc ainsi plus accessible un novice.
57
Mercury Interactive a t rachet en juillet 2006 par HP afin de consolider son offre de logiciels. HP espre ainsi concurrencer IBM et Computer Associates (CA). HP acquire ainsi les outils de tests, de gestion de projets et de gestion du cycle de vie et de la performance des applications de Mercury Interactive. HP atteint ainsi son objectif de construire une offre intgre de logiciels de gestion des infrastructures informatique et rseaux. Cette acquisition lui permet de rivaliser, en termes d'offre produits, avec des acteurs comme Computer Associates (CA) ou IBM. Le chiffre daffaire du logiciel chez HP atteint 2 milliards de dollars par cet achat. HP ralise toutefois la majeure partie de son chiffre daffaire dans la vente de matriel avec 87 milliards de dollars en 2005. Mercury Interactive reprsente un chiffre daffaire de 686 millions de dollars pour 3000 salaris. HP a dbours 4,5 milliards de dollars pour cette acquisition.
QARUN DE MICRO FOCUS

Issu de la gamme QACenter. Du mainframe au Web, en passant par le client/serveur, de la gestion des tests la validation, du test fonctionnel au test de charge, les outils de la gamme QACenter permettent aux entreprises de raliser des tests de performances cohrents et fiables. Grce QARun, les programmeurs obtiennent les fonctionnalits d'automatisation dont ils ont besoin pour crer et excuter des scripts de tests rapidement et de faon productive ainsi que pour vrifier les tests et analyser les rsultats. Compuware sest spar de la partie solution de qualit que gre Micro Focus. Laccord de dsinvestissement comprend certains produits de qualit et dessai distribus, y compris : Tests fonctionnels (QARun, TestPartner, QADirector) Gestion des exigences (Reconcile, Optimal Trace) Suivi de dfauts (TrackRecord) Test de performance (QALoad) Qualit de code (Gamme de produits DevPartner)
58
ABBOT (OPEN SOURCE)

http://abbot.sourceforge.net/doc/overview.shtml Spcifique aux IHM raliss en Java (Abbot signifie "A Better Bot"), cette application permet d'enregistrer des actions via une interface (Costello) sur l'application teste. Ces scenarios de tests peuvent ensuite tre rejous volont. Une API Java est disponible pour automatiser ces tests avec Junit.
59
RATIONAL ROBOT DE IBM

http://www.142.ibm.com/software/dre/ecatalog/detail.wss?locale=fr_FR&S_TACT=none &S_CMP=none&synkey=K108274U58759I63 Comme les prcdents, il permet d'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 adapt aux environnements o les applications sont dveloppes dans plusieurs environnements intgrs et/ou langages de programmation. Automatisation aise des tests manuels : La ralisation de tests de rgression avec IBM Rational Robot constitue une bonne introduction l'automatisation, car l'outil est simple utiliser et permet aux testeurs de dcouvrir les processus d'automatisation mesure qu'ils voluent dans leur travail. Dtection d'un plus grand nombre d'erreurs : Les ingnieurs spcialiss dans l'automatisation des tests peuvent dtecter un plus grand nombre d'erreurs en ajoutant leurs scripts de test des oprateurs logiques conditionnels pour couvrir davantage l'application et dfinir des scnarios de test pour appeler des fichiers excutables ou des bibliothques DLL externes. Mise disposition de scnarios de test adapts aux objets communs (menus, listes et images bitmap) et de scnarios de test spcialiss adapts aux objets spcifiques l'environnement de dveloppement. Intgration d'un outil de gestion des tests et compatibilit avec les outils de la plateforme IBM Rational Team Unifying Platform ddis au suivi des erreurs, la gestion des modifications et la traabilit des exigences. Prise en charge de plusieurs technologies varies.
IRISE STUDIO DE IRISE

http://www.irise.com/products/studio.php Plateforme permettant la dfinition, les tests et la validation des fonctionnalits de solutions Web avant tout dveloppement. iRise propose une approche diffrente de la phase de test : on simule avant de livrer le produit ce qui permet de mieux coller au rsultat attendu.
60
LES OUTILS DE CAMPAGNE DE TEST
Les principales fonctionnalits de ce type doutils sont : La dfinition de campagnes de test. Lhistorisation des rsultats. La gestion des tests de non-rgression.
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. Les outils de gestion des tests ne sont donc pas des automates de test. Certains diteurs de logiciels ont sorti des suites intgres comprenant outil de gestion de test et automates afin dviter linterfaage entre des outils dditeurs diffrents.
TESTDIRECTOR DE MERCURY QUALITY CENTER - HP http://www.mercury.com/fr/products/quality-center/testdirector Cet outil, complet comme ceux de la famille Mercury, prend en charge via une seule application Web 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 Dans cette suite, TestDirector est un outil de gestion intgr qui organise et gre les processus de tests. TestDirector devient le point central de l'organisation, de la documentation et la structure dans chaque projet de test. TestDirector peut organiser une combinaison de tests manuels et automatiques, de rgression, de charge, dans le mme plan hirarchique et visuel, ce qui permet de bien analyser la porte de tous les tests.
61
Une fois le planning fait, TestDirector peut excuter les tests manuels et automatiques, sparment ou groups. Il organise lui-mme des petites combinaisons de tests qui permettent plus de spcificit dans le test. L'interface de TestDirector s'adapte aussi l'utilisation des autres outils de test comme LoadRunner (test de charge et de performance) ou WinRunner (test fonctionnel). Les tests raliss, les rsultats (succs ou chec) sont stocks dans la base de donnes de Testdirector, afin d'tre tudis et utiliss. Trs volu, TestDirector permet la gestion des dfauts de l'application : l'analyse des dfauts est ce qui aide essentiellement les intgrateurs prendre la dcision de "go/no-go" au sujet du dploiement de l'application. Le gestionnaire de dfaut de TestDirector (Defect Management) supporte le cycle de vie entier d'un bug de conception de la dtection initiale du problme la correction. Ceci assure qu'aucun dfaut n'est nglig ou n'est cltur avant qu'il n'ait t corrig et valid. La force de TestDirector est aussi qu'avant qu'un nouveau dfaut soit soumis, une fonction examine la base de donnes pour dceler les dfauts semblables ou les dfauts doubles rduisants au minimum le besoin de contrle et l'limination manuelle.
62
SALOM TMF (OPEN SOURCE)

https://wiki.objectweb.org/salome-tmf
Salom-TMF est un des rares outils libres de gestion de tests. Les principales fonctionnalits de Salom-TMF sont : 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-...). Son systeme de plugins offre un certain avantage pour peu d'avoir des connaissances en Java. C'est aussi, grce Java, un logiciel multi-plateformes.
63
TEST MANAGER DE SOFT EDITION.NET

http://softedition.net/HomePage.html Sous forme d'une application intranet Test Manager a pour but daider les managers responsables dquipes de tests crer, planifier et organiser leurs diffrentes sessions. Cest aussi une gestion documentaire et un apport mthodologique pour les quipes de tests. Liste des fonctions de Test Manager : 1. 2. 3. 4. 5. 6. 7. 8. 9. Aide la cration et lorganisation des documentations de test Aide la cration des plans et stratgies de tests Dimensionne, organise et crez les campagnes de tests Dlivre des rapports prcis au Top Management pour le suivi Suivi de la production, des campagnes et de la couverture fonctionnelle Etablit le lien entre les documents de tests et les spcifications Donne un statut prcis et en temps rel pour toutes les campagnes de tests Point dintgration avec les demandes de fonctionnalits Point dintgration avec les anomalies
Pour rsumer, Test Manager aide les gestionnaires de projets de tests planifier et assurer le suivi de leurs sessions de tests. Test Manager, au sein dune gestion documentaire, aide aussi les quipes de tests crer rapidement et efficacement tous les documents de tests dont elles ont besoin. Test Manager permet de mieux tester le logiciel et acclrera de ce fait la mise en production. Qualit et accroissement de la productivit des quipes sont les deux principaux atouts. Test Manager est un produit concurrent de Test Director de Mercury, mais se distingue par son prix. Le prix de Test Director est environ 24 fois suprieur. Ceci est d en partie business model (tout se fait via le Web : Support, renseignements commerciaux, etc.).
64
QADIRECTOR DE MICRO FOCUS

http://www.microfocus.com/solutions/TestingASQ/index.asp Comme les autres outils de cette catgorie, QADirector vous donne un environnement de travail pour grer le processus de test dans sa globalit, de la conception l'excution et l'analyse. QADirector est une solution de gestion des tests efficace et extensible pour des tests complets du cycle de vie des applications distribues tendues. D'un seul point de contrle : 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
Une architecture ouverte intgre un large ventail d'outils de dveloppement et de test automatiss requis pour tester compltement les applications tout en prservant les investissements existants. QADirector permet aux testeurs, aux dveloppeurs et aux managers de tester compltement une application avec une rutilisation des tests, un partage des informations et une facilit dutilisation amliore.
65
LES OUTILS DE TESTS FONCTIONNELS
Lobjectif des outils de gnration de tests fonctionnels est de vrifier la conformit du fonctionnement dun systme vis--vis des exigences de lutilisateur (plus globalement du cahier des charges). Ces outils vitent la cration "manuelle" de scripts de tests, qui prend du temps et qui nest pas forcment parfaite. Les diteurs proposent donc des outils les plus complets possibles, en offrant un maximum de fonctionnalits automatiques (gnration de scripts de tests, de rapports des rsultats attendus et atteints ou non, etc.) et dindicateurs graphiques pour une utilisation conviviale, aise et rapide. Les outils de gnration automatique de tests ncessitent une modlisation fonctionnelle (notation B, Statecharts Statemate et/ou UML selon loutil). Dans le cas dUML il sagit de diagrammes de classe, dactivit et dtats / transitions avec expressions OCL. A partir de l, le modle est analys et, grce un moteur algorithmique propre chaque diteur, des scripts de tests sont gnrs, pour une couverture maximale des cas possibles. Ces scripts scnarios sont excuts dans un environnement ddis et les rsultats analyss avec tableaux de rsultats, etc. Ces scnarios peuvent tre sauvegards, modifis et rejouer volont. Les outils de gnration automatique de tests sont donc vritablement une valeur ajoute pour les projets de grande taille o la complexit des fonctionnalits grverait le capital financier et temps de la partie relative aux tests.
LEIRIOS TEST GENERATOR DE LEIROS

www.leiros.com Cr en 2003, Leirios est un diteur de logiciels de gnration automatique de tests. Prix de la meilleure innovation technologique de Capital-IT 2007 et Prix de lEntreprise dAvenir 2006 pour la Rgion Est, Leirios est un essaimage du Laboratoire Informatique (CNRS/INRIA) de lUniversit de Franche-Comt. Leirios Smart Testing est aujourdhui utilise par des grands industriels de la carte puce ou de la montique comme Austria Card, Gemalto, Giesecke & Devrient, Ingenico, Parkeon ou Sagem (SESAM VITALE 2) Le s Tests : Ltat de lArt Leirios, soutenu par OSEO/ANVAR, emploie 30 personnes entre Paris, Munich et Besanon, o sont implants son sige social et sa R&D. LEIRIOS fait galement partie des deux ples de comptitivit TES (Transactions Electroniques Scurises) Caen et Microtechniques Besanon. Leirios dveloppe des solutions permettant d'automatiser la conception des tests pour les applications et systmes logiciels. Ce produit marque une rupture technologique par rapport la pratique de test actuelle, qui est principalement empirique et manuelle. Il permet de rationaliser et d'amliorer fortement les processus de validation de systmes.
66
La socit Leirios rpond aux besoins de validation des systmes logiciels par une offre en gnration automatique de tests. Au coeur des activits de validation figure la conception des tests fonctionnels. Ces tests permettent de garantir la conformit d'une application, d'un systme logiciel par rapport ses spcifications initiales. Les pratiques actuelles, essentiellement manuelles et empiriques, constituent un facteur de non-qualit important pour les systmes logiciels. Les solutions Leirios Test Generator intgrent cette technologie Smart Testing, technologie mise en uvre depuis 1999 pour Schlumberger (dans les dpartements cartes puces et terminaux urbains) et pour PSA Peugeot Citron sur plusieurs projets d'envergure. Un transfert de proprit exclusif et complet de la technologie a t ralis dbut 2003 entre l'Universit de Franche-Comt et Leirios Technologies. Leirios Test Generator permet une rduction de plus de 30% de l'effort de conception des tests fonctionnels, avec une couverture des tests 2 5 fois suprieure. Les solutions de Leirios en gnration automatique de tests permettent ainsi une meilleure matrise de la fiabilit des systmes logiciels, une rduction des cots de validation et une acclration du "time to market" des produits. Voici une prsentation de lutilisation de Leirios Test Generator (LTG) : 1. Une modlisation fonctionnelle est effectue partir des Spcifications Techniques de Besoins par lutilisateur. 2. Le modle fonctionnel rsultant (B, Statecharts ou UML) est utilis par le "gnrateur de tests LTG" pour crer les cas de tests. Lutilisateur paramtre simplement ses critres de couverture. 3. Le "gnrateur de scripts LTG" compose alors les scnarios de tests.
4. Les scripts ainsi crs sont excuts dans lenvironnement ddi (banc de test).
67
Exemples dapplications : GSM 11-11 gestion puce SIM Java CardJCVM mcanisme de transaction Gestion des cls, des identits et de la scurit Fonctions visibilit gnrique essuyage, dgivrage, lavage Contrleur de climatisation Algorithme de validation tickets Metro/RER Validation terminal de paiement (CB 5.2)
Groupement des Cartes Bancaires Authentification du porteur
68
CONFORMIQ TEST GENERATOR DE CONFORMIQ SOFTWARE

www.conformiq.com Conformiq Test Generator est un produit invent par la socit Finlandaise Conformiq Software Ltd cre en 1998. Il est distribu en France depuis un an environ par Verifysoft Technology (entreprise allemande). Conformiq Test Generator fonctionne avec tous les langages de programmation. Champs d'application : Conformiq Test Generator peut tre utilis dans les champs d'application suivants : Le s Tests : Ltat de lArt Test de fonction, de systme et d'acceptance Test de rgression (tests quotidiens automatiques des structures) Test d'intgration (simulation de parties du systme) Interface de test (JPOS, COM, J2EE, HTTP, SQL, OPC) Test de protocole / plate-forme (TCP/IP, IPSec, GSM, Symbian) Supports QML (UML + Java / C # syntaxe compatible) pour la modlisation Support pour les modles systmes Support pour les donnes structurelles de modles de systmes Support simultan dans des modles de systmes Support pour les communications temps rel script de test par le biais dinterfaces plug-in Livr avec la gnration dexemple de scripts backends Construction de modle d'analyse statique et dbogueur Support de la traabilit et de la cartographie des exigences leves Support des scnarios de tests et de cas d'utilisation de modles pour d'autres modles de conception axe sur la gnration de tests Support danalyse de la valeur limite Couverture gnrale des heuristiques de conception de tests Transition UML au niveau de couverture et de l'tat de conception de tests heuristiques Facilement paramtrable et extensible pour la plate-forme de conception de tests heuristiques Outil interactif d'orientation et d'aide Livr avec manuel lectronique, par exemple des modles, des plug-ins et des testables systmes
69
Avantages de Conformiq Test Generator Conformiq Test Generator est le seul outil qui permet d'effectuer des tests qui sont normalement trs difficiles tester, comme par exemple les problmes de synchronisation. Conformiq Test Generator garantit une meilleure efficacit de test, une baisse de la dure de phase de test et une plus grande couverture de test. Supprime le risque derreur dans la conception des tests. Support de dveloppement pour l'ensemble des phases du projet et, en outre, pour tous les cycles de vie du logiciel. Cration d'une plate-forme commune pour les concepteurs et testeurs. Large couverture de test : un grand nombre de combinaisons de test pertinent est couvert par les tests automatiques. Maintenance simple de l'environnement de test - modles de test graphiques sont plus simples et plus rapides entretenir et rutiliser que les scripts de test. Applique les exigences de la qualit de la documentation. Rsultats des tests et des couvertures de tests automatiss : les donnes formules clairement facilitent la gestion des erreurs et aident la correction des erreurs. En plus de l'excution des tests en ligne, Conformiq Test Generator peut galement gnrer des scripts de test hors ligne qui pourront tre utiliss plus tard. Conformiq Test Generator peut tre intgr dans des outils de planification et de gestion de test (comme par exemple l'outil de gestion de test Mercury). Disponible pour les plates-formes suivantes : Microsoft Windows NT, 2000 et XP Linux
70
71
MERCURY FUNCTIONAL TESTING ET MERCURY SERVICE TEST DE MERCURY QUALITY CENTER

http://www.mercury.com/fr/products/quality-center/functional-testing Mercury Functional Testing offre la solution la plus complte du march en matire d'automatisation des tests fonctionnels, d'interface utilisateur graphique et de nonrgression. Il prend en charge pratiquement toutes les applications et tous les environnements logiciels. Tirer parti la fois de Mercury WinRunner et de Mercury QuickTest Professional. Mercury Functional Testing vous permet de profiter des ressources de test offertes par les scripts WinRunner et QuickTest Professional. Les ingnieurs qualit peuvent utiliser Mercury Functional Testing pour crer des "scripts composs" qui comportent des tests labors dans WinRunner et QuickTest Professional. Mercury Functional Testing tire en effet profit de l'interoprabilit de WinRunner et de QuickTest Professional : chaque produit peut appeler les scripts de l'autre produit et les rsultats des tests apparaissent dans une interface commune. La SOA est le moteur des rsultats mtier. La SOA augmente la complexit informatique et elle peut compromettre l'activit si elle n'est pas correctement mise en uvre. Les dcideurs informatiques prvoyants adoptent une nouvelle approche du test des services SOA et Web reposant sur Mercury Service Test. Mercury Service Test permet aux quipes informatiques de mener des tests fonctionnels et de performances pour les services. S'appuyant sur la technologie leader du march Mercury LoadRunner, cette solution rduit considrablement les dures de test et permet de s'assurer que les services rpondront aux exigences de fonctionnement et de performances de l'entreprise avant de les dployer en production. Grce Mercury Service Test, vous pouvez : Rduire la dure des cycles d'assurance qualit en automatisant les tests fonctionnels, de non-rgression et de performance des services qui ne sont pas dots d'une interface graphique utilisateur. Simuler des environnements client J2EE, AXIS et .NET pour valuer
l'interoprabilit des services. Simuler des environnements de production via la simulation des souches serveur et les tests asynchrones. Tester diffrences interfaces SOA. Crer et suivre les appels serveur pour garantir la russite des tests de performances asynchrones. Offrir des fonctionnalits d'mulation des services permettant aux testeurs de commencer trs tt, avant mme la construction effective des services. Le s Tests : Ltat de lArt
72
HP est devenu un concurrent srieux pour IBM avec loutil Functional testing en comparaison avec Rational. Voici le rsultat dune tude de comparaison entre les deux outils : S.NO Criteria Rational Functional Tester ***** Mercury Quick Test Professional *** Reason
Generation of Scripts
Scripts
**
*****
Playback of the scripts
*****
Feature generate different cases
to test
***
*****
5 6
Cost Accommodation of new versions of applications
***** *****
** ***
7 Le s Tests : Ltat de lArt
Script Reuse
*****
*****
Test Results
***
*****
The Rational Functional tester is capable of generating VB scripts and Java scripts (Java statements). It is Eclipse based. The Mercury Quick Test Professional generates only VB Scripts. Mercury Quick Test Professional is GUI based. Auto documentation is created for each step performed by the user (in the table) in the keyword view and a novice tester finds the tool easy to work with. The Rational Functional Tester requires some programming experience. User actions performed during recording are replayed during playback. Multiple values selected using the shift keys did not work with the Rational Functional Tester. However, multiple select capabilities worked with Mercury Quick Test Professional. The Rational Functional Tester has data driven commands to generate different test cases. The Mercury Quick Test Professional uses parameterizing the tests to generate test cases. However, the output values have to be manually entered with the Rational Functional Tester. With Mercury Quick Test Professional the output values are generated automatically. Rational Functional Tester is cheaper than Mercury Quick Test Professional. The two tools have features that allow one script to call another script and identical activities are not repeated. This process is easily accomplished with the Rational Functional Tester compared to the Mercury Quick Test Professional which requires technical expertise. The tools have smart recognition features which permit reuse of the script on a new build. The test results are displayed in the html/text log for the Rational Functional Tester. But the Mercury Quick Test Professional displayed the results in the form of a tree in the test result window. When the target object was selected, the tool gives a visual representation of the snapshot (captured during recording) in the screen recorder.
73
Cette tude a t mene par luniversit de lArizona Polytechnique. (Division of Computing Studies Arizona State University, Polytechnic kkarthi1@asu.edu) Les environnements utiliss pour ltude de comparaison entre les deux outils sont :
- IBM Rational Software, Essentials of IBM Rational Functional Tester, Java Scripting, v.6.1, IBM Corporation, Jan 2005. - Hewlett Packard Development Company, L.P. Mercury QuickTestProfessional. (2007) http://www.mercury.com/us/products/qualitycenter/functionaltesting/quicktestprofessional/ (11 Mar.2007). - Marty hall and Mary Brown, Core Servlets and Java Server pages, Sun Microsystems Press/Prentice Hall PTR - IBM Corporation. Rational Functional Tester. http://www-306.ibm.com/software/awdtools /tester/functional/index.html (25 Jan.2007).
74
AUTRES OUTILS DE TESTS FONCTIONNELS
Test Vector Generation de T-VEC

www.t-vec.com
T-VEC Technologies est un grand fournisseur mondial de solutions permettant dautomatiser la gnration de vecteurs de test partir doutils de dveloppement bass sur un modle guid par les exigences et la conception. Les solutions T-VEC permettent aux organisations de faire correspondre les cycles de vie des produits, des systmes et du dveloppement de logiciels aux objectifs commerciaux et aux besoins des clients afin damliorer de manire considrable la qualit et la prvisibilit, tout en rduisant de manire importante les dlais de commercialisation et les cots gnraux. T-VEC a son sige social Herndon, en Virginie (USA), et compte des clients dans des domaines varis tels que llectronique aronautique, larospatial, lautomobile, la mdecine et dautres industries utilisant des produits intgrs. Test Driver Generation permet dtendre dautre langage : C, C++, Java, SQL/ODBC/JDBC, XML, SAVON WinRunner, JCL, Perl, python, ADA, base et VB, coutume (graphiques), assembleur, coquille, langages de commande, mulateurs, classe des propritaires, plus.
Reactis de Reactive Systems - www.reactive-systems.com Le s Tests : Ltat de lArt Il sagit dun outil amricain.
75
76
AutoTester ONE de AutoTester

http://www.autotester.com/content/soft_at1.htm
Offre des tests fonctionnels, de rgression et d'integration pour environnements Windows, applications client/server ou Web. Compatible Windows 3.x, 95/98, NT, 2000, XP. QACenter Enterprise Edition de Compuware
http://www.compuware.com/products/qacenter/enterprise.htm
Supporte les environnements client/serveur, L4G, Java et Web. Rational Robot d'IBM
http://www-306.ibm.com/software/awdtools/tester/robot/
Automatisation de tests de rgression, de tests fonctionnels et de tests de configuration pour applications e-commerce, client/serveur et ERP. iRise Application Simulator de iRise
http://www.irise.com
Plate-forme permettant la dfinition, les tests et la validation des fonctionnalits de solutions Web avant tout dveloppement. Mercury Business Process Testing de Mercury Interactive
http://www.mercury.com/fr/products/quality-center/business-process-testing
Permet aux spcialistes "mtier" et aux quipes "assurance qualit" de valider les processus mtier automatiss. TestView, WebFT de Radview
http://www.radview.com/products/Index.asp
Solution permettant de dfinir des plans de tests automatiss d'applications Web tout en centralisant les scripts de ces tests. Seapine SQA de Seapine
http://www.ideotechnologies.com
Suite logicielle compose de trois outils permettant d'automatiser les tests fonctionnels, de grer les dfauts et les changements de configurations. SilkTest de Segue
http://www.borland.com/us/products/silk/silktest/index.html
Tests fonctionnels et de rgression automatiss. Support des applications Web, Java, client/server d'entreprise. Visual WebTester de Softbees http://4.27.176.151/softbeeswebapp/products.jsp?display=summary
Outil de tests automatiss : tests fonctionnels, de rgression et d'usabilit pour applications Web. eValid de Software Research
http://www.soft.com/eValid
Vrifie la conformit aux spcifications fonctionnelles des sites Web. Multiples modes de synchronization possibles. HTTP/HTTPS, JavaScript, XML, Applets Java, Flash, ASP, JSP et ActiveX supports. Quality Forge de TestSmith
http://qualityforge.com/testsmith/index.html
Automatisation de tests fonctionnels et de rgression pour Windows. Les tests concernent les sites et des applications Web. Les langages supports sont Java et C++.
77
Certify de Worksoft
http://www.worksoft.com
Plate-forme permettant l'automatisation de tests fonctionnels pour applications Web, client/server et mainframe.
78
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

www.parasoft.com
Socit capitaux privs fonde en 1987 par de jeunes diplms de CALTECH (Institut de Technologie de Californie) ParaSoft Corporation a son sige en Californie avec des bureaux de distribution en Australie, en Inde, en Isral, en Chine, Hong Kong, Taiwan, au Brsil et au Japon. ParaSoft Europe, dont le sige social est en France, possde galement des bureaux au Royaume-Uni et en Allemagne. Parmi les clients de ParaSoft, se retrouvent Nokia, Thomson, IBM, Ericsson, Alcatel, Philips, Cap Gmini et Boeing. ParaSoft dveloppe et commercialise des outils de dveloppement qui apporte une aide la dtection des erreurs dans les logiciels. En renforant les standards de programmation et en automatisant le test unitaire, les technologies ParaSoft, uniques et trs souvent primes, aident les utilisateurs amliorer la qualit de leur logiciel, acclrer la mise sur le march et rduit considrablement les dpenses de dveloppement. Depuis ses dbuts, la socit a t largement reconnue pour dvelopper des technologies innovatrices en matire de logiciels et d'outils de programmation de haute productivit. ParaSoft a dvelopp plusieurs produits lis au dveloppement orient objet et web. Les technologies dautomatisation des tests de ParaSoft sont le rsultat de 20 ans de R&D sur les erreurs logicielles et prouvent quamliorer la qualit permet de rduire les dpenses tout en augmentant la productivit. Le s Tests : Ltat de lArt Bases sur la mthodologie AEP (Automated Error Prevention), les outils ParaSoft mettent en uvre une dmarche de prvention, dune part pour liminer des erreurs avant quelles ne se manifestent dans les applications en production, et dautre part pour viter que les erreurs identifies et corriges suite un dysfonctionnement ne se reproduisent. En pistant et simulant les chemins dexcution automatiquement, la technologie Bug Detective rvle les bugs lexcution qui seraient difficilement dtectables lors de tests ou inspections de code manuels. Les utilisateurs peuvent ainsi trouver, diagnostiquer et Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation
79
corriger les catgories derreurs logicielles qui chappent lanalyse base sur les standards de codage et aux tests unitaires.
RATIONAL TEST REALTIME DE IBM

http://www-306.ibm.com/software/info/ecatalog/fr_FR/products/X799502M73821D46.html
Solution multiplateforme permettant de tester les composants et d'analyser l'excution du code C, C++, Java et Ada. Produit particulirement adapt aux individus, qui crivent du code pour les applications embarques ou les autres types de produits informatiques nomades. Prise en charge des applications critiques et confidentielles embarques. Proactivit extrme pour dboguer, dtecter et corriger les erreurs avant qu'elles n'affectent le code de production. Totalement compatible avec les autres solutions IBM Rational (dveloppement pilot par modles, gestion des tests et des configurations logicielles). Totalement compatible avec les outils tiers novateurs (Mathworks Simulink, Microsoft Visual Studio et TI Code Composer Studio).
XUNIT : JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC.

JUnit Propuls sur le devant de la scne par le succs de l'Extreme Programming (XP), le dveloppement pilot par les tests (Test-Driven Developpement ou TDD) est devenu une vidence implacable : on ne peut tre certain du bon fonctionnement d'un morceau de code, qu' partir de moment o l'on en a test toutes les possibilits d'erreur. Le principe du TDD est donc, avant mme d'crire le code d'une fonctionnalit, d'crire le test pour ce futur code. Une fois le test crit, le code de la fonctionnalit devra toujours passer correctement le test avant de pouvoir valider celle-ci. Chaque fonctionnalit peut donc se retrouver avec plusieurs tests sur le dos, chacun vrifiant d'une manire diffrente le bon fonctionnement d'une petite partie de l'application. Parce qu'une application complte peut disposer de plusieurs milliers de tests, l'automatisation devient ncessaire. C'est ici qu'entre en jeu l'architecture de test JUnit, destine tester le code Java. Plus largement, tous les langages activement utiliss disposent de leur quivalent xUnit : PHPUnit pour PHP, nUnit pour les langages .NET, ou AS2Unit pour ActionScript 2.0. Tous drivent de SUnit pour Smalltalk, conu par Kent Beck, par ailleurs l'un des instigateurs du mouvement Extreme Programming. Beck a ensuite port SUnit vers Java avec l'aide d'Erich Gamma, l'un des auteurs du livre fondateur sur les design patterns, et l'un des meneurs du projet Eclipse.
80
La mise en place d'un test sur une mthode Java est assez simple avec JUnit. Chaque classe dispose de son jeu de tests, chaque test injectant par exemple une erreur potentielle que le code doit prvoir, ou vrifiant le bon rsultat d'un traitement. Les mthodes de test sont toutes prcdes du marqueur @Test, ce qui permet JUnit de les reconnatre et de les excuter automatiquement. Chaque classe de test doit importer les paquetages org.junit.Test et org.junit.Test, JUnit tant install et configur pour le systme ou l'outil de dveloppement. JUnit 4.0 teste le code au moyen d'assertions, simulant diverses situations possibles. Ces assertions sont places au cur mme des mthodes de la classe, aux cts du code de l'application. Chaque assert*** place correspond un test effectif. Exemple avec assertEquals : public static void assertEquals(boolean expected,boolean actual) Asserts that two booleans are equal.
81
LES OUTILS DE TESTS DE PERFORMANCE

Les outils de test de performance proposent souvent : Le test de monte en charge. La simulation d'un environnement spcifique. Lvolution agressive de l'accs aux ressources.
Les tests de performances d'une application sont souvent mens pour des sites Web ou Intranet. En effet, lors du dveloppement de sites Web il y a souvent des exigences quant aux performances daccs au site (afin dviter des temps daccs trop longs).
WAPT DE SOFTLOGICA
http://www.loadtestingtool.com
WAPT est un outil de test de charge pour applications Web et intranet. Il enregistre des scnarios de tests puis permet de les rejouer volont en faisant varier : le nombre d'utilisateurs, l'intervalle entre chaque test, etc. WAPT emploie plusieurs techniques avances pour simuler de vraies conditions de charge. Cette approche est beaucoup plus efficace que d'envoyer simplement beaucoup de demandes identiques au serveur en rafale. En fait WAPT simule un grand nombre d'utilisateurs diffrents venant dadresses IP htroclites ; chacune avec ses propres paramtres : cookies, donnes d'entre pour diffrentes pages, nom et mot de passe, vitesse de connexion et son propre "chemin" dans l'application. WAPT peut mme simuler un temps alatoire entre les "clics d'utilisateurs" afin de rendre les actions de ces "utilisateurs virtuels" aussi ralistes que possible, proches de celles de vritables utilisateurs. Si vous voulez simuler des milliers d'utilisateurs, vous n'avez pas besoin d'indiquer le comportement spar pour chacun d'eux. La pratique prouve qu'habituellement les visiteurs d'un site peuvent tre diviss en plusieurs catgories cette approche est employe par WAPT. Il suffit dindiquer le comportement pour chaque type d'utilisateurs dsir, et vous ajoutez dans la campagne de tests autant de ces types d'utilisateurs dont vous avez besoin. Par exemple, des utilisateurs d'un magasin en ligne peuvent tre diviss entre ceux qui passent en revue le catalogue, et ceux connects une certaine page, ajoutant une charge spcifique. Pour chaque type vous crez un profil spar ou toutes ses donnes peuvent tre indiques. A chaque test vous pouvez employer autant d'utilisateurs virtuels de chaque type que vous avez besoin. Les demandes HTTP peuvent inclure des paramtres spcifiques chaque utilisateur. Les valeurs de tels paramtres peuvent mme tre diffrentes pour chaque utilisateur du mme type et peuvent changer dans toute la session. Par exemple, le serveur peut Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation
82
envoyer une variable de session en rponse la premire demande d'un nouvel utilisateur. Cette variable est ajoute aux demandes suivantes de cet utilisateur afin de les identifier. Vous pouvez indiquer comment employer ces paramtres changeants via une interface graphique. Vous pouvez choisir le niveau constant de charge pendant tout le temps du test ou augmenter la charge par intervalle. Vous pouvez indiquer la priode globale du test et le nombre d'utilisateurs virtuels pour chaque profil. La charge globale dpend galement des types d'utilisateurs, ainsi les profils connects peuvent varier au cour du test. Les rsultats du test sont visualiss sous forme de rapports et de graphiques descriptifs. Ils sont disponibles chaud pendant le droulement du test. Ainsi vous pouvez surveiller les paramtres principaux de l'excution des enchanements en marches et suivre la rponse de votre site face au volume croissant de la charge.
MERCURY LOADRUNNER DE MERCURY QUALITY CENTER HP

http://www.mercury.com/fr/products/performance-center/loadrunner
LoadRunner est le produit de Mercury charg des tests de stress et de monte en charge. L'avantage de LoadRunner par rapport a ses concurrents rside dans la multitude de types d'applications gres. De plus, grce la prcision des donnes obtenues, chaque test de charge fournit au dveloppeur des rsultats pouvant donner lieu une action. Exemple : lors d'une transaction lente au niveau de l'utilisateur final, le dveloppeur peut accder la mthode ou l'instruction SQL prsentant un goulet d'tranglement qui provoque le ralentissement. LoadRunner vite les problmes de performances coteux rencontrs en production en dtectant les goulets d'tranglement avant le dploiement d'un nouveau systme ou d'une mise niveau. Vous pouvez vous assurer que des applications nouvelles ou mises niveau fourniront les rsultats mtier recherchs avant le dploiement, et ainsi viter des dpenses excessives sur le matriel et l'infrastructure. Vritable rfrence du secteur en matire de prvision du comportement et des performances du systme, ce produit constitue la seule solution intgre de tests de charge, d'optimisation et de diagnostic propose aujourd'hui sur le march. Avec Loadrunner, vous pouvez valuer les performances, les applications de diagnostic et les goulets d'tranglement sur le systme du dbut la fin et les rgler pour obtenir une meilleure performance ; tout cela partir d'un seul point de contrle. Il prend en charge de nombreux environnements d'entreprise, notamment Web Services, J2EE et .NET. Le s Tests : Ltat de lArt Avec LoadRunner, vous pouvez : Obtenir un tableau prcis des performances systme de bout en bout. Vrifier que les applications nouvelles ou mises niveau rpondent aux besoins de performances spcifis. Identifier et liminer les goulets d'tranglement des performances pendant le cycle de vie du dveloppement. Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation
83
LoadRunner comprend dsormais une technologie avec changement des jeux qui rduit le processus de cration de scripts quelques clics de souris. Web (Click and Script) for LoadRunner vous permet d'enregistrer des scripts sur une couche de prsentation plus leve. Il identifie automatiquement les meilleurs scripts et cre des scripts autoexplicatifs courts et intuitifs qui rduisent de 80 % la maintenance et le temps de cration des scripts. Ces scripts sont galement beaucoup plus simples grer puisque tout le monde a accs au script et peut rapidement en visualiser l'volution chaque message. Web (Click and Script) for LoadRunner diminue en plus les qualifications techniques ncessaires l'laboration de tests de charge.
SIEGE (OPEN SOURCE)

http://www.joedog.org/JoeDog/Siege
Un outil Open Source permettant de simuler nombre de connexions sur un site web. Le dsavantage par rapport a un outil comme WAPT rside dans le fait qu'il ne dispose pas d'une interface utilisateur. Il peut jouer un scnario en lisant une liste d'URL partir d'un fichier ou stresser une seule URL avec un nombre dfini d'utilisateur. Ces URL peuvent tre captures et modifies en fonction des besoins et pour faire varier les profils de test en utilisant Sproxy, un utilitaire de capture de trafic du mme auteur. Sortie le 11 mai 2009 de la version Siege 2.69
JMETER (OPEN SOURCE) DU GROUPE APACHE

http://jakarta.apache.org/jmeter
JMeter est un outil de test de performance pour ressources statiques ou dynamiques, cr le 15 dcembre 1998 par Stefano Mazzocchi. Il est hberg sur le site du Projet Jakarta. JMeter peut simuler de lourdes montes en charge sur une application serveur ou sur un rseau. Cod 100% en Java, interface graphique en Swing. JMeter permet de mesurer les performances de : Sites Internet Serveurs FTP Bases de donnes (via les drivers JDBC) Scripts Perl Objets JAVA (applets) 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
84
QALOAD DE MICRO FOCUS

http://www.compuware.com/solutions/qaload.htm
Outil de monter en charge de la suite QACenter.
PERFORMANCE CENTER DE EMBARCADERO

http://www.embarcadero.com/products/performancecenter/index.html
Cest un portail de qualit industrielle de suivi et de reporting des performances de bases de donnes. En proposant une dtection automatique des problmes qui menacent la disponibilit et performance des bases supervises par cet outil, l'administrateur de la base est inform de problmes potentiels et peut ainsi agir d'une faon proactive afin d'pargner aux utilisateurs des lenteurs et/ou dysfonctionnement.
85
WEB PERFORMANCE LOAD TESTER DE WEB PERFORMANCE, INC

http://www.kapitec.com/Testing/Webperformance/fr/index.html
Web performance est un outil de test de charge permettant de configurer des tests de charge sur des applications web complexe. Les tests peuvent tre effectus avec des utilisateurs virtuels en nombre important (plusieurs milliers) afin de mettre en vidence la capacit de charge du site web test. Les caractristiques :
Caractristique
Description
Capturez des pages Web complexes lors de la navigation, en visualisant les
Free Pro
Enregistrement & Analyse des pages
temps de rponse et les tailles pour toutes les pages Web et leur contenu. Tous les aspects des pages Web peuvent tre examins, dont les en-ttes de requte et de rponse, les cookies, les erreurs et le contenu. Les pages peuvent galement tre visualises dans un navigateur intgr Web Performance Analyzer. Spcifiez vos critres de performance et Web Performance Analyzer
Oui
Oui
Dtection des pages Web lentes
marquera alors les pages trop lentes.
Oui
Oui
La plupart des erreurs dans le code HTML ou JavaScript ne sont pas Dtection des erreurs d'Enregistrement dtectes par les navigateurs, et pourtant elles sont une cause de mauvais fonctionnement des applications Web. Dterminez exactement o vos pages Web sont casses avant que cela ne devienne un vritable problme pour vos visiteurs. Les Cas-Tests peuvent tre personnaliss pour permettre chaque rejeu Personnalisation de Cas- d'effectuer une variation de l'enregistrement original. Des valeurs de Tests remplacement peuvent tre substitues pour les champs de formulaire, ce qui permet, par exemple, chaque Rejeu successif de mesurer les performances d'un terme de recherche diffrent. Oui Oui Oui Oui
Les transactions individuelles peuvent tre dites pour personnaliser le comportement du Cas-Test. Chaque en-tte et chaque partie de l'URL peuvent tre dits. Les transactions peuvent galement tre configures avec les Modificateurs, qui changent la valeur de la requte dynamiquement pendant le rejeu.
Les champs de formulaires et les paramtres de requte d'URL peuvent tre dynamiquement changs par les donnes saisies par l'utilisateur pour simuler des variations du Cas-Test initial, comme la recherche pour diffrents mots cls ou l'ajout de diffrents produits dans un panier d'achat. Tout enregistrement peut tre rejou en appuyant simplement sur un Rejeu de Session bouton. Pendant le rejeu, chaque page peut tre visualise dans un navigateur pour observer l'impact visuel subjectif des changements et des optimisations. Le rejeu termin, les changements sont compars pour des changements objectifs cette fois-ci, comme la taille de la page, la comptabilisation des ressources, les temps de rponse, etc. Vos pages Web gagnent-t-elles ou perdent-elles en rapidit ? Web Suivi des performances dans le temps Performance Analyzer archive les mesures de performance, et vous permet de les suivre dans le temps. Alors que le projet passe par les tapes de dveloppement, de test, puis de maintenance, les concepteurs peuvent s'assurer qu'aucun impact sur les performances de l'application ne passe Oui Oui Oui Oui
86
inaperu. Les pages Web qui ne rpondent pas aux critres de performance sont alors marques. En dehors de l'environnement de dveloppement, les utilisateurs peuvent Voir avec les yeux de l'utilisateur faire l'exprience de performances moindres dues des connexions rseau avec des bandes passantes plus faibles, une congestion du rseau, aux serveurs proxy, etc. Enregistrez et rejouez avec un simulateur de modem pour vous retrouver dans les mmes conditions que l'utilisateur disposant d'une faible bande passante. Oui Oui
Le rapport Bande Passante produit galement des estimations de performance pour tous les niveaux de bande passante. Support SSL Non Oui
87
Le cot dune telle solution version professionnelle :
DESIGNATION
REF. PRIX UROS H.T. PRODUIT
Licence Perptuelle Fixe Web Performance Analyzer Pro 3.6 Version Franaise avec 1 an de maintenance - Livraison lectronique - Prix promo de 500,00 uros H.T. au lieu de 624,00 uros H.T. jusqu'au 11 juin 2009.
WPA3SSPL-PSS
500,00
Licence Perptuelle Fixe Web Performance Load Tester 100 VU - Version 3.6 Franaise sans WPLT3SSPL-100 maintenance - Livraison lectronique
1.995,95
Licence Perptuelle Fixe Web Performance Load Tester 100 VU - Version 3.6 Franaise avec WPLT31 an de maintenance - Livraison lectronique - Prix promo de 2.095,00 uros H.T. au lieu SSPL-100PSS de 2.493, 75,00 uros H.T. jusqu'au 11 juin 2009.
2.095,95
Licence Perptuelle Flottante Web Performance Load Tester 100 VU - Version 3.6 Franaise sans maintenance - Livraison lectronique
WPLT3FPL-100
2.992,50
Licence Perptuelle Flottante Web Performance Load Tester 100 VU - Version 3.6 Franaise avec 1 an de maintenance - Livraison lectronique - Prix promo de 3.392,50 uros H.T. au lieu de 3.740,63 uros H.T. jusqu'au 11 juin 2009.
WPLT3FPL-100PSS
3.392,50
Module Optionnel - Licence Perptuelle Fixe Web Performance Advanced Server Analysis 100 VU - Version 3.6 Franaise sans maintenance - Livraison lectronique
WPASA3SSPL-100
500,00
Module Optionnel - Licence Perptuelle Fixe Web Performance Advanced Server Analysis 100 VU - Version 3.6 Franaise avec 1 an de maintenance - Livraison lectronique - Prix promo de 550 uros H.T. au lieu de 625,00 uros H.T. jusqu'au 11 juin 2009.
WPLT3FPL-100PSS
657,80
88
VI - BILAN ET PERSPECTIVES
Les tests ont volu au fil des annes : de 1960 1980, il sagissait dune mise au point. De 1980 1990, on a utilis les tests afin de chercher et de trouver uniquement des erreurs. On ralisait des tests et cela fonctionnait plutt bien. Depuis 1990, les tests se veulent prventifs.
Longtemps abandonns ou tout au moins minimiss, les tests sont aujourdhui au centre de tous les intrts : de nombreux progiciels ont vu le jour pour tester, grer les versions Des socits ont investi dans la cration dun service interne, vritable structure de tests. Rien ne peut tre mis en production sans tre valid par ce service. 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. Mme le Cloud Computing, qui est un concept mergent est impact par ce nouvel lan pour les tests. Le cloud computing consiste utiliser un nuage de serveurs offrant une puissance de calcul, de stockage et de traitement ingal pour dlocaliser lutilisation de services informatiques. Rserv aujourdhui aux applications (SaaS), au dveloppement (PaaS) et aux insfrastructures (IaaS), le Cloud Computing lance le HaaS (Human as a Service) qui consiste externaliser le capital humain ! Autrement dit, les tests ! LExtreme Programming (Mthode agile de gestion de projets) a compris et intgr elle aussi les tests dans son cycle itratif de dveloppement. LInternet mobile, nouveau mode dinformation et nouveau challenge pour les entreprises, est un support graphique diffrent ncessitant une programmation adapte et donc des tests complmentaires. Il semble bien que les tests sont aujourdhui revenus sur le devant de la scne
89
VII CONCLUSION
Nous avons tent de prsenter le plus simplement possible lintrt des tests dans un projet de dveloppement informatique. Nous esprons toutefois que ce document est suffisamment complet pour vous permettre davoir une connaissance globale sur les diffrentes techniques de tests. Il nexiste pas de techniques meilleures que dautres : Tout dpend de nos besoins, de nos objectifs Cependant, rien nempche de combiner plusieurs techniques. Cest dailleurs ce que nous prconisons. 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. Nous avons vu que les tests faisaient lobjet dune pratique encore trop souvent artisanale mais que demain, 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. Cest ainsi que les outils de tests se sont inscrits comme un moyen de structurer les tests tout comme les projets. Les outils de tests comme la fonction de testeur est actuellement en pleine essor et l'volution rapide des technologies internet ncessite une ractivit accrue des socits pour dfendre leur place de march. Les tests sont aujourdhui revenus sur le devant de la scne
90
REFERENCES : BIBLIOGRAPHIE / WEBOGRAPHIE

Programmer N109 Juin 2008 http://fr.wikipedia.org http://fr.wikipedia.org/wiki/Cycle_de_developpement http://fr.wikipedia.org/wiki/Cycle_en_V http://www.itformation.com/IMG/doc/gestionProjet.doc http://dchaffiol.free.fr/info/blagues/art_bg_cycleEnV.htm http://www.oggam.org/IMG/pdf/Intervention_frank_mosser.pdf http://www.commentcamarche.net/contents/projet/gantt.php3 http://www.robdavispe.com/free2/2097-what-is-bottom-up-testing.html http://dept-info.labri.u-bordeaux.fr/~felix/ Livre Blanc Choisir une stratgie de test de monte en charge de Borland http://fr.wikipedia.org/wiki/Test_de_performance http://dept-info.labri.u-bordeaux.fr/~felix/ http://www.irisa.fr/lande/gotlieb/enseignement/MASTER_COT_05.pdf https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto &cp=1-11_4000_100__ http://archives.lesechos.fr/archives/2006/LesEchos/19717-89-ECH.htm http://technology.asu.edu/files/documents/tradeshow/May07/KavithaProjectRepor t.pdf
91
GLOSSAIRE
Algorithme : Un algorithme est un nonc dune suite doprations permettant de donner la rponse un problme. Si ces oprations sexcutent en squence, on parle dalgorithme squentiel. Si les oprations sexcutent sur plusieurs processeurs en parallle, on parle dalgorithme parallle. API : Une interface de programmation (Application Programming Interface) est un ensemble de fonctions, procdures ou classes mises disposition des programmes informatiques par une bibliothque logicielle, un systme d'exploitation ou un service Benchmark : Un benchmark, en anglais, est un point de rfrence servant effectuer une mesure. En informatique, il sagit dun banc d'essai permettant de mesurer les performances d'un systme pour le comparer d'autres. Bug : Un bug informatique (anglicisme) ou bogue informatique (francisation) est une dficience dans un programme informatique lempchant de fonctionner correctement. Sa gravit peut aller de bnigne (dfauts daffichage mineurs) majeure. Les bugs rsultent le plus souvent derreurs de programmation. Composant : Un composant est un lment d'un systme rendant un service prdfini et capable de communiquer avec d'autres composants. La programmation oriente composant a pris de l'ampleur avec l'avnement de l'objet. Cycle de vie : Il existe diffrents types de cycles de dveloppement entrant dans la ralisation d'un logiciel. Ces cycles prennent en compte toutes les tapes de la conception d'un logiciel. Deadlock : Un inter blocage (appel aussi treinte fatale) est un phnomne qui peut survenir en programmation concurrente. L'inter blocage se produit lorsque deux processus lgers (thread) concurrents s'attendent mutuellement. Les processus bloqus dans cet tat le sont dfinitivement, il s'agit donc d'une situation catastrophique. EDI : L'change de Donnes Informatises (EDI) ou en version originale Electronic Data Interchange , est le terme gnrique dfinissant un change d'informations automatiques entre deux entits l'aide de messages standardiss, de machine machine. Dans la pratique, l'EDI permet de rduire notablement les interventions humaines dans le traitement de l'information, et donc de le rendre effectivement plus rapide et plus fiable. Le s Tests : Ltat de lArt Effet tunnel : Leffet tunnel consiste en gestion de projet grer des phases longues dpourvues de points intermdiaires de contrle. FIFO : L'acronyme FIFO est l'abrviation de l'expression anglaise First In, first Out, que l'on peut traduire par premier arriv, premier servi (littralement premier entr, premier sorti ). Ce terme est employ en informatique pour dcrire une mthode de traitement des donnes.
92
Framework : En informatique, un framework est un ensemble de bibliothques, d'outils et de conventions permettant le dveloppement d'applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et dont la maintenance est aise. Ces composants sont organiss pour tre utiliss en interaction les uns avec les autres. Fuite mmoire :
GUI : En anglais, GUI est labrviation de Graphical User Interface , soit interface
utilisateur graphique . Elle soppose CLI pour Command Line Interface, soit interface en ligne de commande . En France on peut parler dIHM ou interface homme-machine ; par extension en anglais continental europen, on parle dIHM et dHCI. Historisation : En informatique, lhistorisation est trs souvent associe la gestion des versions dveloppes. Jalon : Un jalon correspond une balise, un repre dans le projet qui est incontournable. Un jalon peut correspondre une date de remise dun livrable (document, produit logiciel). Livrable : En informatique, un livrable correspond une production. Il peut sagir dun document crit, dun composant informatique, dun logiciel Mtrique : Une mtrique logicielle est une mesure d'une proprit d'une partie d'un logiciel ou de ses spcifications (Exemple : Combien d'instructions comporte ce module ? , Quel pourcentage des spcifications client ont t traits ? ). Open source : La dsignation Open Source s'applique aux logiciels dont la licence respecte des critres prcisment tablis par l'Open Source Initiative, c'est--dire la possibilit de libre redistribution, d'accs au code source, et de travaux drivs. Processus : Un processus est une tche en train de s'excuter. On appelle processus l'image de l'tat du processeur et de la mmoire au cours de l'excution d'un programme. Un processus mtier (ou procdure d'entreprise) est une suite d'oprations normalises effectues par toute ou partie des employs pour effectuer une tche donne. Prototype : Un prototype dsigne le premier ou l'un des premiers exemplaires d'un produit. Reporting : Le terme dsigne une technique informatique consistant extraire des donnes pour les prsenter dans un rapport lisible (affichable ou imprimable). Le s Tests : Ltat de lArt Ressources informatiques : En informatique, les ressources sont des composants, matriels ou logiciels, connects un ordinateur. En gestion de projet, il nest pas rare dassocier les intervenants des ressources. Revue de code : La revue de code est un examen du code source dun dveloppement informatique. Risque : Le risque est la prise en compte par une personne de la possibilit de ralisation d'un vnement contraire ses attentes ou son intrt. Lorsque la personne Dossier ralis par Stphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 NFE209 Audit et gouvernance des systmes dinformation
93
concerne agit malgr cette possibilit et s'expose ainsi cette ralisation, on dit qu'elle prend un risque. La gestion du risque consiste en lvaluation et lanticipation des risques, et mettre en place un systme de surveillance et de collecte systmatique des donnes pour dclencher les alertes. Scenario de test : Un scnario de test consiste en une procdure dtaille que le testeur doit suivre pour excuter le cas de test (manipulations, saisie, rsultat attendus). Script : Un script est un programme en langage interprt. Spcifications fonctionnelles : Les spcifications fonctionnelles dcrivent les processus mtier auxquels le produit informatique devra rpondre. Spcifications techniques : Les spcifications techniques dcrivent le systme informatique dans lequel le produit sera implant, son interaction avec les autres composants du systme informatique (Base de sonnes). Tableau de bord : Regroupement dindicateurs permettant la prise de dcision. Temps de rponse : Temps coul entre l'instruction donne par l'utilisateur et la ralisation de cet ordre.
94

Tests V10.00

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tests V10.00

Uploaded by

Copyright:

Available Formats

Les Tests : Ltat de lArt

Tests et Validation du logiciel

HISTORIQUE DES MODIFICATIONS

Le s Tests : Ltat de lArt

LES TESTS : LETAT DE LART

STUDIO DE IRISE .................................................................................60

: JUNIT, PHPUNIT, CPPUNIT, PYUNIT, ETC.................................................80

Le s Tests : Ltat de lArt

PREAMBULE : NECESSITE DES TESTS

Le s Tests : Ltat de lArt

I - INTRODUCTION AUX TESTS LOGICIELS

1 QUELQUES EXEMPLES DE BUGS

2 LES DEFINITIONS DES TESTS

Le s Tests : Ltat de lArt

3 LES CLASSES DE DEFAUT

Ces erreurs reprsentent 90% des cas dcels.

4 DIFFICULTES LIEES AUX TESTS

Source : Cours CNAM Gnie Logiciel

Le s Tests : Ltat de lArt

Le s Tests : Ltat de lArt

5 LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS

LES MODALITES DE TEST

LES METHODES DE TEST

LES NIVEAUX DE TEST

LES CARACTERISTIQUES DE TEST

Le s Tests : Ltat de lArt

6 EXEMPLE DE CLASSEMENT SELON 3 AXES

7 QUELQUES PRINCIPES UTILES

Le s Tests : Ltat de lArt

Le s Tests : Ltat de lArt

Le s Tests : Ltat de lArt

Le s Tests : Ltat de lArt

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.

Analyse des besoins

Maintenance Le s Tests : Ltat de lArt

Le s Tests : Ltat de lArt

Expression des besoins et faisabilit

Spcification Fonctionnelle et technique

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

Le s Tests : Ltat de lArt

Le s Tests : Ltat de lArt

3 Cycle en spiral (Boehm 1988)

Planification du prochain cycle 6 1

2 5 Dveloppement d'un prototype

Validation des besoins Le s Tests : Ltat de lArt

Dtermination des besoins

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

Le s Tests : Ltat de lArt

Expression des besoins et faisabilit

Spcification Fonctionnelle, technique

Tests de charge, tests de validation

Le s Tests : Ltat de lArt

2 LES TESTS UNITAIRES

Formalisme des tests unitaires : la fiche de test

Le s Tests : Ltat de lArt

Voici un exemple de formalisme :

Corps de la fiche de test :

Rechercher la facture XXX Appuyer sur le bouton Imprimer

Impression facture OK XXX

Bas de page : Remarques : ....