Tests_V10.00

Les Tests : L’état de l’Art Tests et Validation du logiciel

CNAM 2008 / 2009 - CENTRE REGIONAL DE LILLE NFE209 – AUDIT ET GOUVERNANCE DES SYSTEMES D’INFORMATION

AUDITEURS

AUDITEUR

NUMERO D’AUDITEUR

Stéphane CALIMET

NPC 008961

Philippe FIRMIN

NPC 007654

Eric LELEU

NPC 008029

HISTORIQUE DES MODIFICATIONS

DATE

AUTEUR

DESCRIPTION

VERSION

08/01/2009

S. CALIMET, Ph. FIRMIN, E. LELEU

Création

V_1.0

26/01/2009

E. LELEU

V_2.0

15/04/2009

S. CALIMET, E. LELEU

Introduction, Les tests et le cycle de vie Avantages inconvénients des cycles

30/04/2009


Tests d’intégration

V_4.0

19/05/2009


Tests de charge

V_5.0

21/05/2009


Tests Validation (Fonctionnel)

V_6.0

28/05/2009


Test Validation (Structurel)

V_7.0

03/06/2009


Glossaire

V_8.0

05/06/2009

P. FIRMIN

Test Qualité, outils de test

V_9.0

27/06/2009

P. FIRMIN, E. LELEU

« Conformiq Test Generator »

V_10.0

Le s Tests : L’état de l’Art

V_3.0

1

Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information

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

1 – LES TESTS ET LE CYCLE DE VIE ........................................................................17 2 – LES TESTS UNITAIRES ..................................................................................24 3 – LES TESTS D’INTEGRATION ............................................................................28 4 – LES TESTS DE CHARGE .................................................................................32 5 – LES TESTS DE VALIDATION ............................................................................38 Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information


III – TYPES DE TESTS DANS LE PROJET ......................................................................17

2

PREAMBULE ................................................................................................38 LES PRINCIPALES TECHNIQUES DE VALIDATION .......................................................39 IV – LES TESTS ET LA QUALITE ..............................................................................50 LES CONSEQUENCES DE CET ETAT DE FAIT................................................................51 LES EDITEURS .............................................................................................51 LES SOCIETES DE SERVICES .............................................................................52 EXEMPLE: INDICATEURS QUALITE ....................................................................53 V – LES OUTILS DE TEST ......................................................................................56 LES OUTILS D’AIDE A LA REALISATION DES TESTS ...........................................56 MERCURY WINRUNNER ET QUICKTEST PRO DE MERCURY QUALITY CENTER......................57 QARUN DE MICRO FOCUS ...............................................................................58 ABBOT (OPEN SOURCE) .................................................................................59 RATIONAL ROBOT DE IBM ..............................................................................60 IRISE

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

LES OUTILS DE CAMPAGNE DE TEST ...............................................................61 TESTDIRECTOR DE MERCURY QUALITY CENTER - HP -..............................................61 SALOMÉ TMF (OPEN SOURCE) .........................................................................63 TEST MANAGER DE SOFT EDITION.NET ...............................................................64 QADIRECTOR DE MICRO FOCUS ........................................................................65 LES OUTILS DE TESTS FONCTIONNELS ............................................................66 LEIRIOS TEST GENERATOR DE LEIROS ...............................................................66 CONFORMIQ TEST GENERATOR DE CONFORMIQ SOFTWARE ........................................69 MERCURY FUNCTIONAL TESTING ET MERCURY SERVICE TEST DE MERCURY QUALITY CENTER .72 AUTRES OUTILS DE TESTS FONCTIONNELS.............................................................75 LES OUTILS DE TESTS STRUCTURELS .............................................................79


C++TEST, .TEST, JTEST, SOATEST ET INSURE++ DE PARASOFT ............................79 RATIONAL TEST REALTIME DE IBM ....................................................................80 XUNIT

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

LES OUTILS DE TESTS DE PERFORMANCE ........................................................82 WAPT DE SOFTLOGICA..................................................................................82 MERCURY LOADRUNNER DE MERCURY QUALITY CENTER – HP .....................................83

3


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


GLOSSAIRE ......................................................................................................92


4

PREAMBULE : NECESSITE DES TESTS

Les tests existent depuis longtemps. Après avoir été délaissés par manque d’intérêts de la part des développeurs, il semblerait que se soit aujourd’hui les directions informatiques qui prennent conscience de leur véritable utilité. Ils permettent de rassurer et de palier aux erreurs humaines. Avec l’importance croissante des projets informatiques, les risques de dysfonctionnement, de retards ou de pertes financières augmentent. La réussite et la rentabilité d’un projet passent par un suivi rigoureux, tout au long du processus, de la qualité de la réalisation. Il ne fait aucun doute que la politique de tests est aujourd’hui 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 n’ont jamais été si au cœur 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 à préciser que chacun de nous dispose d’une vision et d’un intérêt différent vis-à-vis de ce vaste sujet : -

Eric a été amené dans un premier temps à mettre en place une équipe de tests au sein de sa société pour un projet d’envergure. Fort de cette réussite, il a eu l’occasion ensuite de déployer en clientèle les outils et méthodes développés. Il juge que cette activité est à fort potentiel.

-

Philippe a une raison différente : Il est amené dans le cadre de son activité professionnelle à assurer un plan d'assurance qualité, ce qui induit de posséder une vue d'ensemble sur les tests logiciels. Le plan mis en place dans sa société ne couvrant que la partie développement, le fait s’orienter tout naturellement vers les outils de gestion de tests.

-

Stéphane désire traiter ce sujet car n’évoluant pas professionnellement dans le monde du développement, les tests sont pour lui une terre inconnue. Il apportera un regard neuf quant à la façon d’appréhender ce thème.


Toutefois, nous avons tous les trois un point commun : nous sommes tous intervenus dans la mise en production d’un projet. Vous aurez l’occasion dans ce dossier de constater tout d’abord qu’il est difficile de définir précisément le test applicatif. La diversité des tests pouvant être menés lors d’un même projet, nous amènera à traiter le test sous divers angles : théorique et pratique (utilisation d’outils de tests).

5


I - INTRODUCTION AUX TESTS LOGICIELS

1 – QUELQUES EXEMPLES DE BUGS

1992 - Les ambulances de Londres sont mal orientées par le logiciel. Des pertes humaines sont à déplorer. 1996 - Explosion de la fusée Ariane 5 au bout de 30 secondes de vol suite à une erreur de conversion de données numériques. 2004 - Défaillance du système d'alarme d'une centrale qui produisit une coupure d'électricité aux Etats-Unis et au Canada. 2006 - Deux grandes banques françaises exécutent un double débit pour plus de 400 000 transactions.

2 – LES DEFINITIONS DES TESTS

Avant de nous lancer dans la définition des tests, il est important de définir la différence entre une erreur, un défaut et une anomalie.

« On constate une ANOMALIE due à un DEFAUT du logiciel lui même du a une ERREUR de programmeur. »

Il n'existe pas de définition unique des tests. Nous vous en proposons quatre permettant d'appréhender les tests sous différents angles. Selon l’AFNOR :

Selon Glendford.J Myers dans « The art of software testing » : « Un test réussi n'est pas un test qui n'a pas trouvé de défauts, mais un test qui a effectivement trouvé un défaut. » Selon Bill Hetzel : « Le test est une activité destinée à déterminer si l'évaluation d'une caractéristique ou d'une aptitude d'un programme ou d'un système donne les résultats requis. » Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information


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

6

Selon l'IEEE (Institute of Electrical and Electronics Engineers):


« Le test est l'exécution ou l'évaluation d'un système ou d'un composant, par des moyens automatiques ou manuels, pour vérifier qu'il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus. »

7


3 – LES CLASSES DE DEFAUT

Les erreurs peuvent être de divers ordres. Il peut s'agir d'erreurs : • • • • • •

de calcul de logique d'entrée / sortie de traitement des données (dépassement de tableau) d'interface (communication entre les programmes) de définition des données

Ces erreurs représentent 90% des cas décelés.

4 – DIFFICULTES LIEES AUX TESTS

Même si les tests font l'objet de méthodes, de planning... tel un véritable projet informatique, il n'en reste pas moins que certains paramètres viennent perturber leurs exécutions :

• • •

Il est impossible de réaliser un test exhaustif (le produit cartésien de certaines variables prendrait trop de temps à tester). La qualité des tests dépend des données utilisées (données 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 même besoin par le chef de projet et le besoin modélisé par le développeur.

Source : Cours CNAM Génie Logiciel

• • •

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



•

8

Il existe bien évidemment de nombreux autres paramètres venant perturber l'activité tests : la taille et la complexité des programmes, la différence entre l’environnement de développement et de production...


-

9


5 – LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS

Il existe différentes façons de classifier les tests. Il n’existe pas de classification officielle : Chaque ouvrage, auteur, site, définit à sa manière les différentes techniques de tests. Il est cependant possible de les regrouper selon leur mode d’exécution, leurs modalités, leurs méthodes, leurs niveaux et leurs caractéristiques.

LE MODE D’EXECUTION

Le test Manuel : Les tests sont exécutés par le testeur. Il saisie les données en entrée, vérifie les traitements… et compare les résultats obtenus avec ceux attendus. Ces tests sont fastidieux et offrent une plus grande possibilité d’erreurs humaines. Ces tests sont très vite ingérables dans le cas d’applications de grandes tailles. Le test Automatique : Le testeur est en partie déchargé des tests dans la mesure où les tests sont réalisés par des outils (JUnit par exemple dans le monde Java).

LES MODALITES DE TEST Il s’agit de tests : Statiques : Les tests sont réalisés «par l'humain» (testeur), sans machine, par lecture du code dans le but de trouver des erreurs. Il peut s’agir : de l’inspection ou d’une revue de code; d’un travail de collaboration lors d’une réunion (le programmeur, le concepteur, un programmeur expérimenté, un testeur expérimenté, un modérateur…)

Dynamiques : On exécute le système de manière à tester l’ensemble des caractéristiques. Chaque résultat est comparé aux résultats attendus.



• •

10

LES METHODES DE TEST Il s’agit de tests : Structurels (Boîte blanche) : Les tests structurels reposent sur des analyses du code source. Il est possible d’analyser la structure du programme. Fonctionnels (Boîte noire) : Les tests fonctionnels reposent sur une spécification (formelle ou informelle) du programme. Le code source du programme n’est pas utilisé. Les tests fonctionnels permettent d’écrire les tests bien avant le « codage ». Il est parfois utile de combiner ces deux méthodes.

LES NIVEAUX DE TEST Il s’agit de tests réalisés tout au long de la vie du logiciel (cycle de vie). Unitaires : s'assurer que les composants logiciels pris individuellement sont conformes à leurs spécifications et prêts à être regroupés. D’intégration : s'assurer que les interfaces des composants sont cohérentes entre elles et que le résultat de leur intégration permet de réaliser les fonctionnalités prévues. Système : s'assurer que le système complet, matériel et logiciel, correspond bien à la définition des besoins tels qu'ils avaient été exprimés. On parle de validation ou de recette. De non régression : vérifier que la correction des erreurs n'a pas affecté les parties déjà développées et testées. Cela consiste à systématiquement rejouer les tests déjà exécutés.

LES CARACTERISTIQUES DE TEST


Il s’agit entre autre de tests :

11

De Robustesse : permet d'analyser le système dans le cas où ses ressources sont saturées ou bien d'analyser les réponses du système aux sollicitations proche ou hors des limites des domaines de définition des entrées. Souvent ces tests ne sont effectués que pour des logiciels critiques, nécessitant une grande fiabilité. De performance : permet d'évaluer la capacité du programme à fonctionner correctement vis-à-vis des critères de flux de données et de temps d'exécution. Ces tests doivent être précédés tout au long du cycle de développement du logiciel d'une analyse de performance, ce qui signifie que les problèmes de performances doivent être pris en compte dès les spécifications.


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 développeur que celui qui a codé. Ne jamais partir du principe qu'un test ne trouvera pas d'erreurs. Examiner et mémoriser les rapports de tests. A la moindre modification ne pas hésiter à refaire les tests (test de non régression).


• • • •


12

II – LA STRATEGIE DE TESTS

1 – GENERALITES

Comme nous l’avons vu précédemment, les tests sont primordiaux. Il en va de même de la stratégie de tests. Une technique de tests adaptée et puissante restera sans effet si elle ne fait pas partie d’une stratégie de tests. Ce que nous ne nous doutons pas, c’est qu’une stratégie de tests peut représenter plus de 50% de la charge totale d’un projet. Il est donc opportun que cette stratégie soit pensée et définie de façon rigoureuse et qu’elle soit intégrée dans le processus de développement du logiciel. Les tests doivent être conçus avant que le logiciel soit réalisé : l’activité tests commence dès la phase de spécification d’un logiciel et se déroule durant toutes les phases du cycle de développement. C’est ainsi que la conception du logiciel va faciliter les tests (testabilité). La stratégie de test dépend : -

De la criticité du produit à réaliser Du coût de développement

Une stratégie consiste à définir : -

Les ressources mises en œuvre (équipes, testeurs, outils…) Les mécanismes du processus de test (gestion de la configuration, évaluation du processus de test…)

Finalement, la stratégie de tests tient compte :


-

13

-

Des méthodes de spécification, de conception (pour rappel, les tests sont conçus avant le développement)… Du langage de programmation utilisé Du type d’application (temps réel, base de données…) L’expérience des programmeurs …


L’activité tests est un PROJET à part entière. C’est la raison pour laquelle nous retrouvons l’ensemble des caractéristiques d’un projet : • •

• • • •


• • • • •

Organisation des équipes Planification et contrôle (planification, estimation des charges, définition des métriques, définition des environnements matériels et logiciels, définition de la campagne, du plan et des livrables) Analyse et conception (organisation du référentiel, identification des conditions de tests, traçabilité, cas de tests, données de tests, procédures de tests, scénarios) Implémentation, suivi et exécution Gestion des configurations (Elle assiste les tests) Evaluation des risques (Décrire les risques comme un problème probable qui peut compromettre l’atteinte des objectifs des tests) Gestion des incidents Evaluation et « reporting » Clôture (recette ou arrêt des tests) Bilan projet Amélioration des processus et mutualisation


14

2 – L’ACTIVITE TEST

•

Stratégie de tests L’ensemble de la stratégie de tests est détaillé dans le Plan Qualité Projet (PQP). Le plan qualité projet est très important. Il va notamment : o

o o o o

Définir l’organisation à mettre en place (équipe de tests). Une stratégie de tests est (ou devrait être) une organisation à part entière. Les tests sont généralement réalisés pas des développeurs (autres que ceux qui ont développés le produit). Le Chef de projet quant à lui, suit les activités, calcul le reste à faire, enregistre et analyse les métriques et les incidents, élabore les tableaux de bord… Définir les responsabilités et relations entre les différents intervenants. Définir les types et les objectifs de tests pour chacun des niveaux (tests unitaires, tests d’intégration, tests de validation). Définir les outils qui seront utilisés. Définir les moyens et les délais à investir dans l’activité de tests.

La stratégie de tests vise à rendre l’effort de test efficace en : o o o

•

Maximisant les chances de détecter les erreurs. Tentant de trouver le plus d’erreurs possibles, le plus rapidement possible. Facilitant le diagnostique.

Plan de tests Le plan de tests est la continuité logique au plan qualité projet. L’ensemble des points évoqués de manière générale vont y être détaillés.


C’est ainsi qu’il existe autant de plan de tests que de phases de qualification du produit.

15

o o o

Au dossier de SPECIFICATION correspond le plan de tests de VALIDATION. Au dossier de CONCEPTION GENERALE correspond le plan de tests d’INTEGRATION. Au dossier de CONCEPTION DETAILLEE correspond le plan de tests UNITAIRES.

De manière générale, les tests se déroulent du général au particulier (détail). L’objectif de chaque plan de tests est de fournir un programme pour vérifier que le logiciel produit satisfait les spécifications et la conception du logiciel. Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information

Un plan de test doit : o o o

o

o

•

Définir les éléments à tester et l’ordre dans lequel ils doivent être testés (planifier les tests). Décrire l’environnement de tests. Définir la façon dont les tests vont être menés (procédures) : processus exacts à mener, l’historisation, la traçabilité, le reporting, le suivi, le contrôle… Il s’agit de la procédure de tests. Il est important que cette procédure soit répétable. Décrire et constituer les fiches de tests (définir les actions à réaliser, les jeux de données à utiliser, les valeurs et les comportements attendus). L’ensemble des fiches de tests constitue le dossier de tests. Il est important de concevoir le dossier de test de manière « POSITIF » et « NEGATIF ». Fixer les critères d’arrêt des tests : selon la couverture définie, selon le nombre d’erreurs trouvés, selon le temps imparti… (Appliquer la stratégie de tests aux tests).

Rapport de test Pour chaque phase de test (unitaires, d’intégration, de validation), l’équipe dédiée aux tests doit élaborer un rapport de tests. Ce rapport est la synthèse des actions menées suivantes : o o o

Exécution des fiches de tests (effectuer les actions décrites). Analyser les résultats obtenus : comparer les résultats attendus avec les résultats obtenus. Les éléments de mesure sont très importants ! Emettre des fiches de non-conformité si nécessaire (ces fiches sont aussi appelées fiches d’anomalie, fiches de bug). Il s’agit de coupler intelligemment la gestion des tests et la gestion des corrections (incidents). NB : Concernant les fiches d’anomalie, il est conseillé de réaliser une fiche par problème décelé afin de faciliter le suivi de celles-ci.

•

Consigner tous les résultats d’exécution de tests. Rédiger des comptes rendus de tests. La somme de ces comptes rendus constituera le rapport de tests.

Qualification, Validation La qualification est essentielle. Elle permet de conclure et d’émettre un avis sur le produit développé et sa mise en production : adéquation entre produit et spécifications fonctionnelles et techniques.



o o

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 après la définition et le schéma de chaque cycle.

•

1 – Cycle en Cascade

Il définit des phases séquentielles à l'issue de chacune desquelles des documents sont produits pour en vérifier la conformité avant de passer à la suivante. Dans le cas contraire, un « Feed Back » (Retour arrière) est opéré.

Analyse des besoins

Spécification

Conception

Réalisation

Validation


Maintenance

17

Source : Cours CNAM Génie Logiciel


Avantages : •

La qualité des livrables (Un livrable réalisé à 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 déroulent les unes après les autres – Un seul fil directeur).

Inconvénients : Difficulté de revenir en arrière en cas d’insatisfaction client.

•

Les modifications en amont ont un impact majeur sur les coûts (Plus le projet est avancé, plus un impact engendra un coût élevé – coût exponentiel).

•

Le temps de réaction est beaucoup plus long (Il est plus difficile de se rendre compte d’une erreur – Tests tardifs dans le projet)

•

Risque d’effet tunnel (Les jalons permettent de scinder le projet en phases clairement identifiées, évitant ainsi d'avoir une fin de projet à trop longue échéance. On parle généralement d'« effet tunnel » pour désigner un projet de longue durée sans échéance intermédiaire.)


•


18

•

2 – Cycle en V

Le modèle du cycle en V est un modèle conceptuel de gestion de projet imaginé suite au problème de réactivité du modèle en cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés, afin d'améliorer le logiciel. Le modèle de cycle de vie en V part du principe que les procédures de vérification de la conformité du logiciel aux spécifications doivent être élaborées dès les phases de conception. Ce cycle est utilisé lorsque l’environnement est stable et que le client connait son besoin dans le détail. Le cycle en V est devenu un standard de l'industrie logicielle depuis les années 1980.

Expression des besoins et faisabilité

Recette

Spécification Fonctionnelle et technique

Qualification

Conception globale

Conception détaillée

Intégration

Tests unitaires

Développement


Source : adaptée de http://fr.wikipedia.org/wiki/Cycle_de_développement

19


Avantages : •

Temps de réaction meilleur grâce à la transversalité (Grâce aux phases de tests transversales, les imperfections sont découvertes plus rapidement)

•

Anticipation des étapes suivantes (Dans chaque phase, il faut prévoir le déroulement de la suivante)

•

En cas de problème dans le projet, il permet de limiter le retour aux étapes précédentes.

Inconvénients : La phase de conception est fortement liée à la phase de réalisation. Le travail en équipe est OBLIGATOIRE.

•

Moins adapté au développement logiciel (C’est le temps qui nous le dit par comparaison au cycle itératif actuellement utilisé)

•

Risque d’effet tunnel (Les jalons permettent de scinder le projet en phases clairement identifiées, évitant ainsi d'avoir une fin de projet à trop longue échéance. On parle généralement d'« effet tunnel » pour désigner un projet de longue durée sans échéance intermédiaire.)


•


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 développer par prototype successif. Chaque prototype ayant son propre cycle de vie (Analyse, conception, réalisation, intégration, validation...) Il emprunte au prototypage incrémental mais lui adjoint une dimension relevant de la prise de décision managériale et non purement technique. Il couvre l'ensemble du cycle de développement 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), • développement d'un prototype (2), • tests du prototype (3), • détermination des besoins (4), • validation des besoins (5), • planification du prochain cycle (6). Ce cycle est utilisé dans le cas d’un environnement instable et dans lequel le client ne connait pas suffisamment son besoin.

Planification du prochain cycle

Analyse du risque 6

1

2 5 Développement d'un prototype


Validation des besoins

21

Détermination des besoins

4 3

Tests du prototype

Source : adaptée de http://fr.wikipedia.org/wiki/Cycle_de_développement


Avantages : •

Cahier des charges respecté au pied de la lettre (Cahier des charges réalisé au fur et à mesure)

•

Validité des besoins (A chaque cycle les besoins sont validés – Moins de risque d’erreurs)

Inconvénients : Calendrier et budget souvent irréalistes (Chaque cycle font habituellement l’objet de dépassements… - On ne sait chiffrer qu’un seul cycle à la fois)

•

Problème pour les composants externes (Difficulté d’anticiper les composants nécessaires dans les cycles ultérieurs)

•

Sa mise en œuvre demande de grandes compétences et devrait être limitée 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 présentes : • • • •

Phase Phase Phase Phase

d'analyse de conception d'intégration de validation

Par soucis de présentation et de compréhension, nous présentons ci dessous le cycle de vie en V dans lequel sont intégrés les tests. • • • •

A l'expression du besoin correspond les tests de recette. Aux spécifications correspondent les tests systèmes. A la conception globale correspond les tests d'intégration. A la conception détaillée et au développement correspondent les tests unitaires.

Expression des besoins et faisabilité

Tests de recette

Spécification

Tests de charge, tests de validation

Fonctionnelle, technique

Conception globale

Tests d’Intégration

Tests unitaires

Conception détaillée


Développement

23

Source : http://fr.wikipedia.org/wiki/Cycle_de_développement


2 – LES TESTS UNITAIRES

•

Définition

Le nom de test unitaire vient du fait qu'une partie de code est appelé « unit ». Ils sont aussi appelés test de composants. Ce type de test va donc vérifier un module du code et ainsi s'assurer qu'il fonctionne de manière indépendante du reste du programme. Il va aussi vérifier que ce module respecte les spécifications fonctionnelles et techniques du produit. Les tests unitaires sont habituellement à la charge de l'équipe de développement. Les tests unitaires peuvent être manuels (dans la plupart des cas) et/ou automatisés par des solutions logicielles (permet de s'assurer d’une non régression). •

Formalisme des tests unitaires : la fiche de test

Les tests unitaires sont formalisés par une fiche que l’on appel la fiche de test unitaire. Cette fiche est une liste (ou aide mémoire) qui doit permettre de rappeler les grandes actions d’une phase de tests. Elle permet également de préparer les tests en l’enrichissant tout au long des développements. Elle permet de stipuler que tous les points à contrôler ont été testés (tels que les tests d’instructions, de conditions, tests aux limites…). Dés le démarrage d’un développement ou affectation d’une nouvelle tâche, le chef de projet ou l'analyste initialise une fiche destinée au développeur. Au fur et à mesure des développements celle-ci peut être enrichie par des descriptions de contrôles ou de tests spécifiques.

Chaque analyste ou chef de projet responsable d'une phase de recette se doit de réclamer l'ensemble des fiches de tests d'un projet afin de cibler au mieux la phase de recette. C’est ainsi que les fiches de test assurent un passage en recette dans les meilleures conditions. Ces fiches s'inscrivent dans un objectif de qualité. Elles doivent être considérées comme un outil et non comme une contrainte.



Lors de la réalisation des tests unitaires, il s’agira de dérouler cette liste d'actions, de réaliser les actions et de les valider (OK ou non OK). Un "non OK" (souvent noté KO) doit toujours être justifié.

24

Voici un exemple de formalisme :

Entête : Nom de l’entité ou des entités : nom du programme (ou module) à tester (Ex : Facturation) Libellé : Résumé en une phrase ce que fait l’objet 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

Evénement

Déroulement du test

Résultats

l’objet

FAC001

OK/KO

attendus

Consultation facture

Rechercher la facture XXX Appuyer sur le bouton

Impression facture OK XXX

« Imprimer »


Bas de page :

25

Remarques : ………………………………………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………………………………………… ……………………………………………....


•

Les données

Afin de réaliser des tests unitaires, il est nécessaire d'élaborer au préalable des jeux de tests. Ces jeux de tests peuvent être : • • • •

des données fictives imaginées par le développeur pour valider un ensemble de cas de tests, des données de production : il s'agit de données réelles (extraites de la production), des anciens jeux de tests.

Les ressources

Les ressources nous permettent de réaliser les tests. On peut s'inspirer : • • • • •

des documents de spécifications, des spécifications de tests (Scénarios, jeux de tests…), de la fiche de test initialisée par le chef de projet, des tests précédents (suite à correction, test de non régression).

La démarche o

Analyse statique

La notion d'analyse statique de programmes couvre une variété de méthodes utilisées (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 exécution sans réellement l'exécuter. C'est cette dernière restriction qui distingue l'analyse statique des analyses dynamiques.

o

Analyse dynamique – Structurelle

La vérification de la structure du code correspond à une stratégie axée sur les flots de contrôles qui consistent à parcourir tous les nœuds, tous les arcs et tous les chemins du code. C'est de cette manière que l'on peut découvrir qu'un test de type SI …NON… ALORS (IF..THEN..ELSE) n'est pas utilisé. La vérification des variables consiste à contrôler leur affectation, leur utilisation dans des conditions et dans les traitements (calculs...).



L'analyse dynamique structurelle consiste à vérifier la structure du code ainsi que les variables.

26

o

Analyse dynamique – Fonctionnelle

L'analyse dynamique fonctionnelle consiste à vérifier le service rendu et non la façon dont il est rendu. En d'autres termes, il s'agit ici de valider les règles de gestions énoncées dans le cahier des charges. La difficulté de ce type de test réside dans le choix des données de tests afin d'obtenir les résultats attendus.

o

Boîte noire

Le test de la boîte noire est utilisé pour tester un programme en vérifiant que les sorties obtenues sont bien celles prévues pour des entrées données. Ce fonctionnement interne est soit inaccessible (cas le plus fréquent), soit omis délibérément (c'est alors un outil théorique qui permet de choisir d'étudier exclusivement les échanges d’entrée / sortie).

Ce type de test est couramment utilisé dans les tests de non régression, les tests de robustesse (fonctionnement en situation extrême : débranchement d'un équipement...) et les tests de charge.

o

Boîte blanche

Le test de la boîte blanche permet de tester le code. Le but est de valider qu’il n’y 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 D’INTEGRATION

•

Définition

Après que les développeurs (ou chacune des équipes) aient validés leurs développements, ils regroupent les différentes parties de programme à assembler. Ce regroupement, ou intégration, permet d'établir une nouvelle version du produit, souvent destinée à une livraison. Les tests d'intégration ont donc pour but de valider le fait que toutes les parties développées séparément fonctionnement ensemble, tant d'un point de vue du fonctionnement que des aspects techniques de l'assemblage. La phase d'intégration intervient après les tests unitaires des modules. •

Les objectifs

Les objectifs vont dépendre de la phase du projet. Le projet est presque terminé : Le test d'intégration aura pour but de vérifier la version finale du produit : vérifier que le logiciel correspond aux attentes du client et répond au cahier des charges. Il s’agit d’une Intégration GLOBALE. Le projet est en cours de développement : Il s'agit de déployer une nouvelle version du logiciel en y intégrant les corrections, les nouvelles fonctionnalités… Il s’agit d’une Intégration INCREMENTALE. Dans les deux cas, il sera opportun de valider les interfaçages de composants et l'interaction matérielle. •

Les périmètres couverts et exclus

Le périmètre exclus : o

Comme précisé précédemment, aucune vérification liée au fonctionnelle ne sera effectuée.

o o o o

Livraison des différents modules ou composants. Vérification du fonctionnement des composants. Vérification du dialogue entre les modules (compatibilité, appel, passage de paramètres…). Prévision et anticipation d’un retour à une version antérieur en cas d’incident.



Le périmètre couvert :

28

•

Les méthodes o

Big Bang

L’intégration « Big Bang » est aussi appelé non-incrémentale (globale). Le principe est d'intégrer tous les composants en une seule étape. L'intégration est certes rapide mais ne peux être envisagée que pour les petits projets. Dans le cas de projets importants, il y a trop de risques à implémenter un nombre important de composants (détection tardives des anomalies).

o

De haut en bas (Top down) – Descendante

L'approche en Top-down vient du fait que l'on déroule le programme de haut en bas : les modules viennent s'empiler les uns aux autres. Des bouchons sont utilisés pour simuler les traitements. Les bouchons doivent être vus comme des programmes renvoyant une ou plusieurs valeurs. Les différents modules doivent être les plus petits possible afin de comprendre aisément leur rôle. Avantages : • •

Détection précoce des défauts d'architecture. Facilité de compréhension.

Inconvénients : • • •

La création des bouchons est consommatrice de temps. L'effort de simulation des composants absents constituent une source d'erreurs. Tests tardifs des couches basses.

Unité testée

Bouchon de test

Dépendance Simulée

Dépendance Testée


1

29

2

3

2

3

Source : Réalisé par Eric LELEU pour illustration


o

De Bas en Haut (Bottom up) – Ascendante

A l'inverse de l’approche top-down, l'approche bottom-up part du bas vers le haut : Non pas que l'on démarre de la fin du programme mais plutôt des fonctionnalités qui sont considérées comme fondamentales. Elle nécessite donc le fait de bien décomposer les fonctionnalités du programme et ainsi de définir celles qui seront indispensables et prioritaires aux autres. Le développeur crée et utilise des bouchons pour simuler des composants non développés. Dans l’approche ascendante, les composants de bas niveaux sont réalisés et donc testés en premier.

Avantages : • • •

Faible effort de simulation. Définition des jeux d'essais plus facile. Les fonctionnalités basses sont plus souvent testées.

Inconvénients : •

Détection tardive des erreurs majeures.

Unité testée

Bouchon de test

Dépendance simulée

Dépendance testée

3

2

1

2

1




30

o

Mixte

L'approche mixte est une combinaison des approches ascendantes et descendantes. Il est parfois vu dans la littérature le concept de boîtes grises. Avantages : • •

Le planning de développement est géré de façon à intégrer les composants dans l'ordre de création (comparable à la méthode FiFo – First In / First Out). Prise en compte de la criticité des composants : les composants les plus critiques sont intégrés les premiers.

Inconvénients : •

Difficulté d'intégration du à la mixité des méthodes (Concilier les méthodes ascendantes et descendantes).

o

Par paquet


Cette approche repose sur une décomposition du programme en fonctionnalités et/ou par criticité (dépend de la taille du programme). Il est évident que l'on ne peut procéder à ce type d'approche qu'en présence de logiciel permettant le découpage en modules.

31


4 – LES TESTS DE CHARGE

•

Définition du test de charge

Les tests de charge consistent à exposer une application à des conditions d'exploitation et d'utilisation les plus proches de la réalité afin de valider le comportement du système. Les tests fonctionnels ne suffisent pas : l’application doit fonctionnellement répondre aux besoins mais doit aussi être performante (Temps de réponse…).

•

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 réponse) La montée en charge (Maintient des fonctionnalités sous la charge,…) La fiabilité (Détection des maillons faibles qu’il s’agisse de matériel ou de logiciel, valider les plateformes, identifier les contentions de base de données ou de réseau…)

Types de tests de charge

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 réponse utilisateurs, les temps de réponse réseau et les temps de traitement d’une requête sur le(s) serveur(s).

o

Test de Dégradations des Transactions : il s'agit d'un test technique primordial au cours duquel on ne va simuler que l'activité transactionnelle d'un seul scénario fonctionnel parmi tous les scénarii du périmètre des tests, de manière à déterminer quelle charge limite simultanée le système est capable de supporter pour chaque scénario fonctionnel et d'isoler éventuellement les transactions qui dégradent le plus l'ensemble du système.

o

Test de stress : il s'agit d'un test au cours duquel on va simuler l'activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l'application, pour voir comment le système réagit au maximum de l'activité attendue des utilisateurs.



Il existe plusieurs types de tests de charges permettant d’atteindre les objectifs cités précédemment :

32

o

Test d’endurance, de robustesse, de fiabilité : il s'agit de tests au cours duquel on va simuler une charge importante d'utilisateurs sur une durée relativement longue, pour voir si le système testé est capable de supporter une activité intense sur une longue période sans dégradations des performances et des ressources applicatives ou système.

o

Test de capacité, de montée en charge : il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs sans cesse croissant de manière à déterminer quelle charge limite le système est capable de supporter.

Il existe d'autres types de tests (test de tolérance aux pannes, tests de volumétrie…), plus ciblés 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 démarche (ou la stratégie de conduite des tests de charge)

La démarche consiste à : o o o o o o o

Préparer les tests (dossier de test, étude de faisabilité technique) Créer les scripts (QUOI) Créer les scénarios (COMMENT) Exécuter les scénarios Analyser les résultats Améliorer le système (Tuning système) Rédiger un rapport (préconisations)

La préparation des tests correspond à la phase primordiale. Elle consiste tout d’abord à réaliser un dossier de tests comprenant : La description de l’application Le descriptif des transactions Le descriptif des scripts Les scénarios Le planning Le plan de charge Les objectifs à atteindre La configuration Les jeux de données.

QUOI

COMMENT POURQUOI AVEC QUOI


o o o o o o o o o

33


−

Tests manuels : ont comme problème majeur leur organisation qui est une opération généralement inefficace en matière d'utilisation du temps, des budgets et des ressources. En outre les tests manuels ne permettent pas de générer des résultats productibles, ne fournissent aucun niveau quantifiable de stress des applications et ne peuvent pas être coordonnés dans des conditions satisfaisantes. Leur processus non extensible ne permet pas d'intégrer des outils de localisations de la cause source d'un problème de performance.

−

Applications développées en interne : permettent de répondre au budget trop serré qui ne permet pas de recourir à une solution extérieure trop coûteuse. Les problèmes sont d'ordres différents : par exemple la couverture applicative qui est souvent testé par des scripts très spécifiques à l'application. Lorsqu'ils sont correctement développés, ces scripts permettent de tester la capacité de l'application à gérer une action donnée mais pas de mesurer sa capacité à traiter un ensemble composite de transactions. L'obtention de résultats exploitables est quasiment impossible. Un autre souci avec ce type de tests est donc la spécificité des outils. Ils ne peuvent pas être utilisés pour d'autres applications au prix de changement du script : le processus de correction des scripts initiaux pour répondre à un nouveau besoin peut souvent s'avérer tout aussi long que d'en développer un nouveau en partant de zéro. La dernière difficulté rencontrée est que ce type de scripts (souvent développé par une seule personne) sont assez peu exploitables et compréhensibles par d'autres intervenants si le script n'est pas assez documenté (ou pire si l'auteur quitte la société en milieu de projet).

−

Outils Open Source : permettent de réaliser des tests élémentaires d'applications Web simples, des fonctionnalités essentielles leur font encore défaut 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 anticipés de montée en charge des composants des implémentations de middleware ou de base de données. De plus en raison de l'absence d'API de haut niveau, les scripts ont tendance à devenir extrêmement longs et d'autant plus difficiles à maintenir. La plus part des outils Open sources sont basés sur la technologie JAVA. Ces limitations ont souvent pour conséquence de multiplier les coûts matériels/ressources requis pour maintenir plusieurs machines de test de charge. Les outils Open Source sont généralement des solutions ponctuelles et ne proposant aucune intégration avec d'autres outils gérant les tests fonctionnels et de régression.

−

Framework de tests intégrés aux EDI : sont des outils nés d'une nouvelle tendance de l'industrie du développement logiciel. Ces outils consistent à concevoir des EDI très importants intégrant également des fonctions de test. Par exemple Microsoft Visual Studio Team System pour l'univers .NET est le plus révélateur. L'avantage de ce type de solution est de promouvoir un développement 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 inconvénient puisqu'il propose une vue entièrement tournée sur le développement, supposant que les développeurs réalisent toutes les activités (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 très rudimentaires pour tester la charge des applications Web et ne supportent pas d'autres environnements de



La préparation des tests a aussi pour but de réaliser une étude de faisabilité technique sur les outils et leur environnement :

34


développement. Elles se révèlent efficaces aux petits projets mais insuffisantes pour tester des applications stratégiques complexes. De plus, aucun de ces Frameworks ne couvre tous les aspects des tests fonctionnels aux tests de performance.

35

−

Outils dédiés au Web : utilisent tous la même approche qui est de piloter Internet Explorer pour lui faire réaliser des scripts de tests en tant qu'utilisateur virtuel. Ces outils sont précis ou extensibles mais pas les deux à la fois en raison de leurs limitations techniques. Ce n'est donc pas la solution idéale pour construire des tests de charges. Pour progresser en extensibilité, il est nécessaire de réduire la consommation de ressources par utilisateurs virtuel. Cependant la précision 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 représentation réaliste d'un contexte de production. Les outils dédiés 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 inconvénients de ce type d'outil réside dans les limites des fonctionnalités de leur langage de script. Ils ignorent les principes élémentaires de tout langage de programmation. La réalisation de scripts pour d'autres projets est donc très difficile voir impossible.

−

Service de tests hébergés : sont généralement réalisés depuis un service Internet distant. Cette approche ne nécessite aucun matériel, logiciel ni expertise du coté client et peut présenter des avantages pour découvrir les premiers bénéfices de tests de montées en charges. Le seul inconvénient est que les tests doivent être réalisés de façon régulière tout au long du cycle de développement (aussi bien de façon méthodes que dans sa globalité). Certains composants applicatifs ne sont pas accessibles sur les réseaux publics et leur test avec une solution hébergée devient difficile. Le comportement d'Internet étant largement imprévisible, ces tests hébergés ne sont pas reproductibles. Ils sont donc utiles pour tester un concept et doivent être réalisés suffisamment tôt.

−

Plateformes d'entreprise : sont les seules qui répondent à l'intégralité des besoins de test de charge. Ces solutions sont suffisamment extensibles pour tester des environnements applicatifs hétérogènes pour un coût raisonnable. En assurant également les tests de stress des composants, elles permettent de détecter les enjeux de performance en amont du cycle. Leur capacité à contrôler intégralement les flux d'activité des utilisateurs virtuels et un langage de script avancé et flexible permettent de facilement réutiliser les scripts dans différents scénarios d'utilisation. Des API de haut niveau pour les environnements applicatifs supportés simplifient grandement la maintenance des scripts de tests. Des outils de « reporting » permettent également d'analyser rapidement les résultats des tests de charge à travers des outils de diagnostic localisant la cause source des éventuels problèmes pour en accélérer la résolution. La problématique qualité est traitée dans une approche globale. Des éditeurs proposent généralement des prestations de support, de formations pour garantir une implémentation optimisée et réussie. Il existe bien entendue de notables différences entre les différentes offres du marché mais elles sont dans tous les cas bien plus performantes que les différentes alternatives que nous avons vu précédemment évoquées.


−

Quand mener les tests de charge

Plus les tests de charge débutent tôt dans le processus de développement, plus ils permettent de mettre rapidement en évidence les possibles défauts du logiciel ou de son infrastructure sous-jacente. Si l'on sait que le coût des corrections des défauts non découverts progresse exponentiellement à chaque phase suivante du cycle de développement, il n'en est que plus essentiel de débuter les tests de montée en charge le plus tôt possible. Compte tenu de la structure multi-niveau des applications existantes, les différentes phases du processus de développement ont été synthétisées dans la figure ci dessous avec les tests correspondants à chaque phase.

Phases au cours desquelles des activités de test de charge peuvent être intégrés

Pour les tests de composants, on procède à des tests de stress qui permettent de localiser simplement et économiquement les problèmes potentiels tels que les situations d'inter-blocage (deadlock), les problèmes de synchronisation, des fuites mémoires, des enjeux de performance... Le diagnostic de ces problèmes immédiatement avant le déploiement avec une solution classique de test de « bout en bout » est généralement trop complexe, et dans tous les cas, leur résolution est infiniment plus coûteuse que s'ils avaient été détectés en amont. Cette phase de test est unique dans la mesure où elle est généralement réalisée avant qu'il n'existe de véritables clients permettant d'enregistrer un script de test; ces derniers doivent donc être réutilisés (en tests unitaires) ou développés manuellement.



Source : Livre Blanc « Choisir une stratégie de test de montée en charge » de Borland

36

Pour les tests de charge de l'infrastructure (ou benchmark), les décisions concernant celle ci sont généralement prise assez tôt. Cependant, l'infrastructure retenue peut intégrer un système d'équilibrage de charge, des serveurs d'applications, des serveurs web..., jouera un rôle clé dans la performance de l'application. Les résultats officiels aux benchmarks standard ne sont généralement pas d'une grande aide et ne peuvent pas prendre en compte l'architecture complète de l'application. Une bonne compréhension des effets des différents paramètres de configuration système permet de disposer suffisamment tôt de données utiles pour l'optimisation ultérieure des performances. La connaissance des indicateurs clés de performance fournit un benchmark significatif pour les tests ultérieurs de montée en charge de bout en bout et de monitoring applicatif. En réalisant assez tôt les tests de charge de l'infrastructure, il est possible de vérifier que les composants résidant dans les différentes couches collaborent comme prévu. L'utilisation d'un prototype « tous niveaux » incluant un sous ensemble de la fonctionnalité complète touchant tous les niveaux de l'architecture permet de réaliser les tests suffisamment tôt dans le processus de développement pour détecter rapidement les potentiels défauts de conception. Il est également possible d'évaluer différentes alternatives de conception comme la distribution et la réplication des couches de présentation/métier/données. Les tests de charge de bout en bout permettent d'analyser le fonctionnement de l'ensemble de l'application dans différents scénarios réalistes d'utilisation et de charge. Ils peuvent durer quelques heures ou plusieurs jours. Ces tests sont généralement conduits dans un environnement temporaire de pré production et leurs résultats permettent de répondre aux questions suivantes : o o o o o


o

Des erreurs se produisent-elles dans des conditions particulières de charge ? Quelle est la capacité système requise pour les couches de l'application ? L'application pourra-t-elle satisfaire les niveaux de services requis ? L'application est elle optimisée pour offrir les meilleurs performances ? Les activités de résolution des erreurs, d'optimisation et de réglage ou l'introduction de nouvelles fonctionnalités ont elles eu des effets négatifs sur les performances ? L'application est elle prête pour un déploiement intégral ?

37


5 – LES TESTS DE VALIDATION

PREAMBULE Les tests de validation ont pour objectif de vérifier que toutes les exigences du cahier des charges soient respectées. Ces tests sont effectués immédiatement après les tests d'intégration. Il existe deux stratégies ou approches pour les tests de validation : -

La première consiste à identifier toutes les fonctions du logiciel et de les tester de façon séquentielle.

-

La deuxième approche est de tester les caractéristiques du logiciel (interface, ergonomie, performance…).

Dans la pratique, les deux sont utilisés. Les tests de validation font partie de la stratégie de tests (Stratégie de tests). A ce titre, l'organisation de la recette doit respecter les consignes décrites dans le dossier de stratégie de tests, à savoir :

-

Vérification et respect du périmètre défini. Validation de toutes les fonctionnalités inventoriées. Utilisation des jeux de tests définis (idéalement, le jeu d'essai doit être le plus proche possible de la réalité. Dans la plupart des cas, on prendra des données réelles) et de la plateforme de recette associée. La plateforme de test doit être la plus proche possible de celle où sera déployé le logiciel. Exécution de l'ensemble des scénarios élaborés. Suivi et synthèse des fiches de recettes. ….


-


38

LES PRINCIPALES TECHNIQUES DE VALIDATION APPROCHE FONCTIONNELLE (BOITE NOIRE) Les tests fonctionnels ne permettent pas d'accéder au code source. Il est donc plus difficile par ces techniques de détecter des défauts 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 (Règles de gestion précisée dans la documentation de spécifications ou le cahier des charges) sans se soucier de la structure interne du programme. Cette approche se fait donc en « boîte noire ». C'est l'approche privilégiée à ce jour.

ANALYSE PARTITIONNELLE L'analyse partitionnelle se base sur le domaine de variation des données en entrée du composant logiciel. Dans la pratique, on segmente les cas fonctionnels (réalisation 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 données équivalentes du même ensemble. On choisira une donnée de test égale au moins à un choix quelconque d'un représentant de chaque classe.

1 Valeur Comportement 1


Comportement 1

39

Ensemble de toutes les valeurs possibles

1 Valeur limite

Comportement 2 1 Valeur Comportement 2 Source : Réalisé par Eric LELEU pour illustration


Exemple : Soit la fonction qui calcule les frais de port : frais de 10€ si montant d’achat inférieur à 100€ (on suppose qu’un montant d’achat ne peut pas être négatif). Il existe 2 comportements : le montant d’achat peut être inférieur ou supérieur à 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€ d’achat. Ne pas oublier de tester les valeurs limites : 100€ dans notre cas !

TESTS AUX LIMITES L'expérience prouve que les erreurs se situent très souvent à la frontière de comportements différents (« les bugs se cachent dans les coins »). Ces tests aux limites sont souvent utilisés avec la technique de partitionnement : les valeurs aux limites peuvent être des valeurs aux frontières des partitions. Exemple de bugs aux limites : -

L'indice de tableau est dépassé. Une comparaison stricte au lieu d'une avec égalité. Oublie de traitement du premier ou du dernier record d'un fichier.

Exemple : En général, pour un paramètre appartenant à un intervalle, il y a génération de 6 données de test.


Pour tester si P est compris entre [0,100], nous sélectionnerons six valeurs (données de test) de manière à tester chacune des bornes (limites) : -1, 0, 1, 99, 100, 101.


40

TESTS COMBINATOIRES (PAIRWISE)

L'approche Pairwise fait que l'on sélectionne les données 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 défaut de cette technique est qu'il n'y a aucune chance de détecter les erreurs demandant des combinaisons de deux valeurs et plus. Exemple 1 : imaginons une boîte de dialogue composée de 4 listes avec 3 valeurs possibles. Il existe donc 81 combinaisons possibles (34). En réalité, dans l'approche PairWise seul 9 cas (ou paires) seront testés : Chacune des valeurs de la première liste combinée avec une seule valeur de chacune des autres listes. Exemple 2 : imaginons 3 variables booléennes 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 donnée de test (A=1, B=1, C=1) couvre 3 paires : (A=1,B=1),(A=1,C=1),(B=1,C=1) La donnée de test (A=0, B=0, C=0) couvre 3 paires : (A=0,B=0),(A=0,C=0),(B=0,C=0) La donnée de test (A=1, B=0, C=0) couvre 2 paires : (A=1,B=0),(A=1,C=0) La donnée 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 nécessaires pour couvrir l’ensemble des cas.

41


TESTS SYNTAXIQUES

Cette technique de test est peu utilisée. Elle peut cependant se révéler utile pour des applications qui nécessitent des données d'entrée respectant une syntaxe rigide et bien définie. C'est le cas des applications qui autorisent un lancement direct par ligne de commande (Exemple : l’utilitaire d’archivage Winzip). Afin de réaliser les tests, il convient : -

De définir la grammaire (la syntaxe de la ligne de commande). De construire un arbre répertoriant l'ensemble des cas possibles. De construire les jeux de tests nécessaires à partir de cet arbre.

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

Logiciel Archivage

Créer une archive

1 Fichier

Plusieurs Fichiers

Ajouter fichier(s) à une archive existante

1 Fichier

Plusieurs Fichiers




42

TESTS ALEATOIRES Les tests aléatoires se différencient des autres tests par leur approche probabiliste. En effet, les jeux de tests sont réalisés de manière automatique et aléatoire 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 générer un ensemble de données aléatoires totalement cohérent.

Satisfaction

Test Déterministe

Test Aléatoire

Effort



43


COUVERTURE GRAPHE FONCTIONNEL La couverture du graphe fonctionnel est comme son nom l'indique le parcours complet de tous les nœuds, de tous les arcs, de tous les chemins. Tous les éléments de l'arborescence du programme doivent être exécutés au moins une fois. C'est une technique qui est très utile pour les tests IHM (Interface Homme Machine) mais sa modélisation est très vite complexe.


Source : Cours Test et validation CNAM


44

GRAPHES CAUSE-EFFET Cette méthode, concept élaboré par G.J. Myers, relie les effets d'un programme (les sorties) aux causes (entrées). Les causes sont des entrées possibles (variables d'entrée, actions utilisateurs etc.) et les effets sont les sorties du système (variable de retour, modification de la base de données etc.). Il faut donc identifier les causes et les effets du système à partir des spécifications puis élaborer un graphe de cause à effet. L'élaboration de ce graphe est l'étape la plus difficile : une mauvaise interprétation aurait des conséquences directes sur les cas à tester. On cherchera si possible à réduire ou à simplifier ce graphe de cause à effet. On pourra ainsi générer les données de tests pour le couvrir. Exemple de représentation :

A1

A2

A3

B1

B2

C1

B3


« C1 » dépend de « B2 », de « B3 » mais aussi de « A1 », « A2 » et « A3 ».


Le nombre de données de test augmente très rapidement (il est utile d’utiliser un tableau de vérité pour représenter et tenter de simplifier les cas à tester) !

45


APPROCHE STRUCTURELLE (BOITE BLANCHE) Les tests « boite blanche » sont utilisés lorsque les jeux d'essais dépendent 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 prévoit pas d’exécution de code. On passe en revue le code, on estime la complexité de celui-ci. L'exécution reste symbolique et l'interprétation abstraite : On s’attarde sur la structure du programme. L'approche dynamique est de produire un jeu de données de tests en fonction du code source. Ces données exécuteront un ensemble de comportements et de résultats qui seront comparés avec ceux du cahier des charges. Cette approche est limitée par l'exécution partielle du programme et de son comportement. L’approche structurelle permet la détection d'erreurs indépendantes de l'application et d’avoir une vue globales des algorithmes. Les tests structurels font une utilisation importante de la théorie des graphes. Elle reste cependant limitée du fait de la non exécution réelle du programme et donc le fait que l'on ne test pas les fonctionnalités.

LES TESTS STRUCTURELS STATIQUES -

Revue de codes

Une revue de code consiste en un examen détaillé d’une spécification, d’une conception par une personne ou un groupe de personnes, afin de déceler des fautes, des violations de normes de développement ou d’autres problèmes. Il s’agit d’une TECHNIQUE DE CONTROLE plutôt que de test.

o o o o o o o o o

Taux de commentaires Intérêt des commentaires Variables non initialisées Gestion des indices de tableau Conversion de types Division par zéro Terminaison des boucles Sortie d’une procédure ou fonction …



Exemple de contrôle :

46

-

Estimation de la complexité

Statistiquement, la complexité d’un programme est corrélée avec le nombre de ses défauts : en d’autres termes, plus un programme comporte de lignes, plus il a de pourcentage d’erreurs. Il existe plusieurs façons d’appréhender cette notion de complexité.

Les métriques d’HALSTEAD

Les métriques d’HALSTEAD évaluent la complexité liée à la distribution des variables et des instructions. La base des mesures est fournie par le vocabulaire utilisé : les opérateurs et les opérandes. Formulation : n1 = nombre d’opérateurs uniques n2 = nombre d’opérandes uniques (termes, constantes, variables) N1 = nombre total d’apparition des opérateurs N2 = nombre total d’apparition des opérandes l = n1 + n2 L = N1 + N2 Taille estimée du programme = n1(Log2 n1) + n2(Log2 n2) Volume du programme = L Log2 (n1 + n2) Difficulté du programme = (n1/2) (N2/2) Nombre d’erreurs = Volume du programme / 3000

Les métriques de Mc CABE

Mac CABE étudie le logiciel en analysant le graphe de contrôle du programme et calcule la complexité structurelle ou nombre cyclomatique de ce graphe. Le nombre cyclomatique donne une évaluation du nombre de chemins indépendants dans le graphe et donc une indication sur le nombre de tests nécessaires.


Cette mesure indique la borne supérieure du nombre de tests à effectuer pour que tous les arcs soient couverts au moins une fois.

47

Dans la pratique, on admet que la limite supérieure du nombre cyclomatique soit de 30. Cette valeur est définie comme un critère de qualité dans le plan qualité (PAQ).


Formulation : n = nombre de nœuds (blocs d’instructions séquentielles) e = nombre d’arcs (branches suivies par le programme) v = nombre cyclomatique o

Dans le cas d’une entrée et d’une sortie v = e-n+2

o

Dans le cas de « i » points d’entrée et de « s » points de sortie v = e-n+i+s

Exemple : Voici un exemple simplifié d’un graphe de flot de contrôle.

A

B

C

D

E

F Source : Réalisé par Eric LELEU pour illustration

En théorie, il existe 4 cas pour tester l’ensemble des solutions : ABCDF, ABCEF, ACDF et ACEF.

V=7 arcs – 6 nœuds + 2 = 3 En effet, un seul des 2 cas sera utile parmi ACDF et ACEF (AC, CDF et/ou CEF ayant déjà été parcourus).



Or selon Mc CABE, il existe 3 chemins :

48

LES TESTS STRUCTURELS DYNAMIQUES

Les tests structurels sont basés sur le graphe de flot de contrôle (couverture de toutes les nœuds-instructions, de toutes les branches, de tous les chemins). L’objectif est de produire les données de test qui exécuteront un certain ensemble de comportements du programme (chemin dans le graphe de contrôle).

Exemple : Voici un exemple simplifié d’un graphe de flot de contrôle.

A

B

C

D

E

F Source : Réalisé par Eric LELEU pour illustration

En théorie, il existe 4 cas pour tester l’ensemble des solutions :


ABCDF, ABCEF, ACDF et ACEF.

49


IV – LES TESTS ET LA QUALITE Le coût des tests est évalué lors de l’estimation du projet global et est souvent sous estimé par rapport à l’organisation mis en place sur le projet. En conséquence les projets dépassent le budget en ce qui concerne les coûts et la durée (les deux étant plus ou moins liés). Des enquêtes ont été effectuées et révèlent une tendance par rapport aux différentes phases d’un projet. En exemple aux USA en 1986 une étude menée auprès de 55 entreprises révèle que 53% du budget total d'un logiciel est affecté à la maintenance. Ce coût est réparti comme suit : • • • • • • • •

34% maintenance évolutive : modification des spécifications initiales ; 10% maintenance adaptative : nouvel environnement, nouveaux utilisateurs ; 17% maintenance corrective : correction des bogues ; 16% maintenance perfective : améliorer les performances sans changer les spécifications ; 6% assistance aux utilisateurs ; 6% contrôle qualité ; 7% organisation/suivi ; 4% divers.

On s’aperçoit que le coût des corrections de bug se situe en second position après la maintenance évolutive et quel représente une part non négligeable du budget d’un logiciel. Pour faciliter et fiabiliser l’estimation des projets des méthodologies ont été développés pour évaluer la complexité de l’environnement et du logiciel. C’est le cas du modèle COCOMO pour COnstructive COst Model estime qu’un projet est réparti comme suit : • • •

15 à 20% programmation 40% spécification et conception 40% validation et vérification

Cette méthode définit des métriques et des règles afin d’évaluer de manière plus fiable le coût d’un logiciel. Nous constatons que l’estimation d’un logiciel et tout aussi difficile que celle de le tester et nécessite tout comme les tests des méthodes et des outils logiciels permettant d’aider à la décision finale. Ceci s'explique par l'augmentation de la complexité des logiciels avec la montée en puissance des performances du matériel.



Ce n’est pas comme il est souvent constaté la programmation qui requière le plus d’énergie mais bien la définition du produit et son contrôle.

50

LES CONSEQUENCES DE CET ETAT DE FAIT Face au bug le client a un choix restreint d’action selon la provenance du bug : matériel, logiciel, performance… Il peut faire appel à son service informatique ou à la société éditrice de logiciel ou la société de service. Dans le cas d’un contrat, une question se pose immédiatement qui va supporter le coût de correction de l’anomalie ? La législation est peu développée sur le sujet. C’est le contenu du contrat qui fait force le loi.

LES EDITEURS Les éditeurs fournissent des logiciels dont ils ont définies les fonctionnalités au préalable qui s’avèrent figés dans le temps jusqu’à la version suivante. L’achat doit donc se faire en connaissant les limites du produit tant fonctionnel qu’au niveau fiabilité. Le fournisseur délivre dans ce cas une licence qui donne le droit d’utiliser le produit en l’état. Il se décharge de toutes responsabilités liées à l’utilisation de son produit et de ces conséquences. L’éditeur n’ayant pas connaissant du contexte de déploiement de son produit. Exemple de garanties et responsabilité des éditeurs :

« Le logiciel » et la documentation qui l’accompagne sont fournis dans l’état où ils se trouvent et sans aucune garantie. En cas de support défectueux, un autre exemplaire sera délivré par « la société » sur demande. « La société » décline toute responsabilité découlant d’un dommage direct ou indirect en relation avec l’utilisation ou l’impossibilité d’utilisation de « le logiciel », y compris les dommages entraînés par la perte de bénéfices, l’interruption des activités, la perte d’informations et autres, et ce même si « la société » a été informé de la survenance ou de l’éventualité de tels dommages.


Comme l’acheteur n’achète pas le logiciel, mais une licence d’utilisation, l’éditeur retire sa responsabilité sur son exploitation.

51


LES SOCIETES DE SERVICES Le cas d’une société de service d’ingénierie informatique est différent puisqu’elle offre un service à son client de type clé en main. Elle est pour des raisons marketing, stratégique et économique dans le devoir de fournir une prestation qui répond aux besoins du client. Elle a connaissance du contexte de déploiement du produit puisque c’est l’une des contraintes incontournables pour répondre au mieux à la définition des besoins élaborés par le client. Elle ne peut donc pas, comme l’éditeur, se décharger de sa responsabilité de qualité du produit mais aussi de qualité de la réponse donnée au cahier des charges émis par son client. Elle va donc émettre un contrat allant dans ce sens et définissant les actes auxquels elle s’engage ainsi que les limites de sa prestation. Elle va donc par ce contrat se protéger face aux exigences évolutives du client mais aussi permettre au client d’exiger la prestation et la qualité qu’elle met en avant. Le client va donc s’appuyer sur une norme ou des méthodologies, 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 d’avoir un recours en cas de litige. Elle définit tous les états du processus de conception mais aussi l’assurance que l’entreprise répond à une politique qualité en ce qui concerne son organisation. Deux parties sont donc définies : • •

le produit fabriqué. l'organisation et le management.

Cette norme définie une qualité de travail, une méthode, une traçabilité ainsi que des métriques 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 s’appuyer sur un autre le PAQ : Plan d’Assurance Qualité fourni par le prestataire. Ce PAQ définit précisément le périmètre d’intervention du fournisseur et leurs délais mais aussi les obligations et les devoirs de chaque partenaire et les limites de l’intervention de l’une ou l’autre des parties.

La société de service peut par exemple fournir une prestation supplémentaire d’accompagnement à l’élaboration d’une plate-forme de tests client ou au déploiement et formation des utilisateurs du client dans les cas les plus complexe ou si le client ne l’a pas insérer dans son contrat. Certains PAQ définissent des métriques sur la base des quels le client peut exiger en accord avec son fournisseur de définir des pénalités en cas de dépassement de seuils préalablement définis.



Et permet donc de justifier les surcoûts ou les actions à mener pour les éviter.

52

EXEMPLE: INDICATEURS QUALITE

Indicateur

RDL – RESPECT DES DELAIS DE LIVRAISON DES LIVRABLES

Objectif

Respecter les délais de livraison des livrables (documentaires, logiciels).

Mode de calcul

RDL – Ecart dates réelles / prévues doit être inférieur ou égal à 5j

Action

Analyse des causes et actions correctives

Pénalité

Indicateur

RCM – RESPECT DES CONTRAINTES ET DES METHODES

Objectif

Respecter les méthodes et outils de gestion de projet du logiciel de développement utilisé et les contraintes du produit

Mode de calcul

RCM - Pour chaque thème, respect O/N

Action

Prise en compte des remarques par les Prestataires, avec correction sous un délai de 5 jours

Pénalité


Indicateur

53

RDC – RESPECT DES DELAIS DE CORRECTION

Objectif

Respecter les délais de correction des anomalies logicielles

Mode de calcul

RDC - Anomalie bloquante corrigée sous 24h , les autres types d’anomalies sous 48h

Action

Analyse des causes et actions correctives

Pénalité


La négociation et la mise au point du contrat est, comme on vient de le voir, primordiale et nécessite de passer un temps important pour le bon déroulement du projet. Dans cette exemple la mise en œuvre des pénalités applicables par le maître d’œuvre dans le cas de non – respect des facteurs qualité, dans le cas où le Prestataire est seul responsable, reste à préciser par rapport au contrat négocié. L’ensemble des 5 critères suivant donne l’assurance qualité : • • • • •

la confiance du client, répondre exactement à ses besoins et attentes, améliorer la performance, obtention d’une meilleure rentabilité de l'entreprise Améliorer l'accès au marché.

La norme ISO définit la qualité comme étant les exigences du client en terme de service et de normes de produit. Elle incite donc les entreprises à répondre aux exigences du client pour obtenir cette certification. Elle représente un gage de qualité obligatoire et une méthodologie de l’organisation auquel tendent toutes les sociétés commerciales et industrielles.

• • • • • • • • • • • • • • • • • • • •

Responsabilité de la direction Système Qualité Revue de contrat Maîtrise de la conception Maîtrise des documents Achats Maîtrise du produit fourni par le client Identification et traçabilité Maîtrise du processus Contrôle et essais Maîtrise des équipements de contrôle, de mesure et d'essai Etat des contrôles et essais Maîtrise du produit non conforme Actions correctives et préventives Manutention, stockage, ... Enregistrements relatifs à: la qualité Audits qualité internes Formation Prestations associées Techniques statistiques

Ces 20 conditions montrent l’impact psychologique et la qualité du travail qu’est en droit d’attendre le client. Il démontre le degré d’organisation d’une entreprise certifié. D’autres méthodologies sont aujourd’hui utilisées pour atteindre le zéro défaut : CMMI, ITIL.



Cette certification ISO 9000 est obtenue, par une entreprise, si elle répond aux 20 conditions suivantes :

54

Le but de ce dossier n’est pas de décrire ces différentes méthodes ou normes. Ce paragraphe montre l’importance des tests et des outils qui les accompagnes face aux exigences du client qui utilise ces méthodes ou ces normes pour obtenir ce qui lui est dû. La norme ISO9000 et les méthodes CMMI ou ITIL sont les moteurs de la qualité et incitent à contrôler, à tester. L’environnement de plus en plus complexe du système d’information contribue à chercher des solutions pour augmenter la qualité, la fiabilité et la robustesse du système d’information.


Elles ont donc contribuées aux développements des outils de tests.

55


V – LES OUTILS DE TEST Les outils de tests que l’on trouve sur le marché peuvent être classés en cinq groupes : •

•

•

•

•

Le premier concerne les outils d’aide à la réalisation des tests. o Capture et ré exécution des scripts réalisés via une IHM. o Sauvegarde des tests et des résultats associés. o Génération 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 à définir, organiser et conduire les campagnes de tests. Ils doivent donc s'interfacer avec tous les outils qui interviennent dans les tests. Le troisième groupe concerne les tests fonctionnels (boite noire). Les tests concernent l'analyse des spécifications du logiciel, sans tenir compte du code source. Le périmètre des contrôles englobe les interfaces utilisateurs, les API, la gestion des bases de données, la sécurité et le réseau. Il vérifie la conformité du fonctionnement d’un système vis-à-vis des exigences de l’utilisateur (se réfère au cahier des charges). Le quatrième groupe concerne les tests structurels (boite blanche). Ces outils permettent de valider ce que fait le logiciel testé. Ils sont donc complémentaires aux outils de tests fonctionnels qui vérifient, eux, ce que doit faire le logiciel. Ces pourquoi des éditeurs ont créé des suites comprenant ces deux types de tests. Le cinquième groupe concerne la performance des logiciels développés, quelque soit l’environnement : applications Web, intranet ou des Web services.

LES OUTILS D’AIDE A LA REALISATION DES TESTS

Appelés "automates de tests", ces outils présentent des fonctionnalités communes : •


• •

Capture et ré exécution des scripts réalisés via une IHM (=Interface homme machine). Sauvegarde des tests et des résultats associés. Génération de scripts de tests en fonction des langages et des plateformes.


56

MERCURY WINRUNNER ET QUICKTEST PRO DE MERCURY QUALITY CENTER Mercury Quality Center fournit un ensemble d'outils Web permettant de gérer 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 génération. Cette suite permet de créer un ensemble de tests, de le gérer en testant l'application tout au long du cycle de développement et de coordonner les résultats. Pour définir un test, Mercury WinRunner enregistre simplement les actions de l'utilisateur sur l'interface du programme à traiter (processus métier type : commande d'un article saisi d'un client...). Les scripts générés peuvent être modifiés pour répondre aux besoins de tests les plus complexes. Ensuite, les testeurs peuvent ajouter des points de contrôle, qui comparent les résultats attendus et réels obtenus lors de l'exécution du test. Il est même possible de vérifier les valeurs des bases de données afin de garantir la précision des transactions et l'intégrité des bases de données, en mettant en évidence les enregistrements qui ont été mis à jour, modifiés, supprimés et insérés. Lors de l'exécution des tests, Mercury WinRunner fait fonctionner l'application automatiquement, simulant un utilisateur réel exécutant chaque étape du processus métier. Cet outil fonctionne exclusivement sur plateforme Microsoft Windows. Pourquoi deux versions d'un même type d'outil chez le même editeur ? WinRunner existe depuis 1995. La premiere version de QuickTest Pro date de 2002. Ce dernier a été réalisé comme la suite logique du premier englobant ses fonctionnalités et rajoutant les siennes. A la base QuickTest Pro avait été crée parce que WinRunner gérait les environnements Web.


WinRunner a fondamentalement été supplanté par QuickTest Pro.

57

WinRunner est plus complexe à mettre en oeuvre, son langage de script (TSL) est propriétaire. QuickTest Pro utilise le même langage (par souci de compatibilité) mais aussi VBScript largement plus répandu. L'interface de QuickTest Pro est plus ergonomique à utiliser, facilement manipulable par « point and click » et donc ainsi plus accessible à un novice.


Mercury Interactive a été racheté en juillet 2006 par HP afin de consolider son offre de logiciels. HP espère ainsi concurrencer IBM et Computer Associates (CA). HP acquière 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 intégrée de logiciels de gestion des infrastructures informatique et réseaux. Cette acquisition lui permet de rivaliser, en termes d'offre produits, avec des acteurs comme Computer Associates (CA) ou IBM. Le chiffre d’affaire du logiciel chez HP atteint 2 milliards de dollars par cet achat. HP réalise toutefois la majeure partie de son chiffre d’affaire dans la vente de matériel avec 87 milliards de dollars en 2005. Mercury Interactive représente un chiffre d’affaire de 686 millions de dollars pour 3000 salariés. HP a déboursé 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 réaliser des tests de performances cohérents et fiables. Grâce à QARun, les programmeurs obtiennent les fonctionnalités d'automatisation dont ils ont besoin pour créer et exécuter des scripts de tests rapidement et de façon productive ainsi que pour vérifier les tests et analyser les résultats. Compuware s’est séparé de la partie solution de qualité que gére Micro Focus. L’accord de désinvestissement comprend certains produits de qualité et d’essai distribués, y compris : Tests fonctionnels (QARun, TestPartner, QADirector)

•

Gestion des exigences (Reconcile, Optimal Trace)

•

Suivi de défauts (TrackRecord)

•

Test de performance (QALoad)

•

Qualité de code (Gamme de produits DevPartner)


•


58

ABBOT (OPEN SOURCE) http://abbot.sourceforge.net/doc/overview.shtml Spécifique aux IHM réalisés en Java (Abbot signifie "A Better Bot"), cette application permet d'enregistrer des actions via une interface (Costello) sur l'application testée. Ces scenarios de tests peuvent ensuite être rejoués à 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 précédents, il permet d'automatiser les tests de fonctionnalité et de régression 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 fonctionnalités, de régression et de configuration polyvalent adapté aux environnements où les applications sont développées dans plusieurs environnements intégrés et/ou langages de programmation.

•

Automatisation aisée des tests manuels : La réalisation de tests de régression avec IBM Rational Robot constitue une bonne introduction à l'automatisation, car l'outil est simple à utiliser et permet aux testeurs de découvrir les processus d'automatisation à mesure qu'ils évoluent dans leur travail.

•

Détection d'un plus grand nombre d'erreurs : Les ingénieurs spécialisés dans l'automatisation des tests peuvent détecter un plus grand nombre d'erreurs en ajoutant à leurs scripts de test des opérateurs logiques conditionnels pour couvrir davantage l'application et définir des scénarios de test pour appeler des fichiers exécutables ou des bibliothèques DLL externes.

•

Mise à disposition de scénarios de test adaptés aux objets communs (menus, listes et images bitmap) et de scénarios de test spécialisés adaptés aux objets spécifiques à l'environnement de développement.

•

Intégration d'un outil de gestion des tests et compatibilité avec les outils de la plateforme IBM Rational Team Unifying Platform dédiés au suivi des erreurs, à la gestion des modifications et à la traçabilité des exigences.

•

Prise en charge de plusieurs technologies variées.

IRISE STUDIO DE IRISE

Plateforme permettant la définition, les tests et la validation des fonctionnalités de solutions Web avant tout développement. iRise propose une approche différente de la phase de test : on simule avant de livrer le produit ce qui permet de mieux coller au résultat attendu.



http://www.irise.com/products/studio.php

60

LES OUTILS DE CAMPAGNE DE TEST

Les principales fonctionnalités de ce type d’outils sont : •

La définition de campagnes de test.

•

L’historisation des résultats.

•

La gestion des tests de non-régression.

Les outils de gestion des plans et campagnes de test servent à définir, 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 intégrées comprenant outil de gestion de test et automates afin d’éviter l’interfaçage entre des outils d’éditeurs différents.

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'intégralité de la procédure de test : gestion des besoins, planification, élaboration, organisation et exécution des tests, gestion des anomalies, analyse de l'état du projet… Dans cette suite, TestDirector est un outil de gestion intégré qui organise et gère 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 régression, de charge, dans le même plan hiérarchique et visuel, ce qui permet de bien analyser la portée de tous les tests.

61


Une fois le planning fait, TestDirector peut exécuter les tests manuels et automatiques, séparément ou groupés. Il organise lui-même des petites combinaisons de tests qui permettent plus de spécificité 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 réalisés, les résultats (succès ou échec) sont stockés dans la base de données de Testdirector, afin d'être étudiés et utilisés. Très évolué, TestDirector permet la gestion des défauts de l'application : l'analyse des défauts est ce qui aide essentiellement les intégrateurs à prendre la décision de "go/no-go" au sujet du déploiement de l'application. Le gestionnaire de défaut de TestDirector (Defect Management) supporte le cycle de vie entier d'un bug de conception de la détection initiale du problème à la correction. Ceci assure qu'aucun défaut n'est négligé ou n'est clôturé avant qu'il n'ait été corrigé et validé. La force de TestDirector est aussi qu'avant qu'un nouveau défaut soit soumis, une fonction examine la base de données pour déceler les défauts semblables ou les défauts doubles réduisants au minimum le besoin de contrôle 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 fonctionnalités de Salomé-TMF sont : •

Organisation du plan de tests sous forme d'arbre hiérarchique.

•

Organisation des tests en campagnes, pour l'exécution.

•

Possibilité d'intégrer et d'exécuter 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, grâce à 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 d’aider les managers responsables d’équipes de tests à créer, planifier et organiser leurs différentes sessions. C’est aussi une gestion documentaire et un apport méthodologique pour les équipes de tests. Liste des fonctions de Test Manager : 1. 2. 3. 4. 5. 6. 7. 8. 9.

Aide à la création et à l’organisation des documentations de test Aide à la création des plans et stratégies de tests Dimensionne, organise et créez les campagnes de tests Délivre des rapports précis 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 spécifications Donne un statut précis et en temps réel pour toutes les campagnes de tests Point d’intégration avec les demandes de fonctionnalités Point d’intégration avec les anomalies


Pour résumer, Test Manager aide les gestionnaires de projets de tests à planifier et à assurer le suivi de leurs sessions de tests. Test Manager, au sein d’une gestion documentaire, aide aussi les équipes de tests à créer rapidement et efficacement tous les documents de tests dont elles ont besoin. Test Manager permet de mieux tester le logiciel et accélérera 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 supérieur. 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 catégorie, QADirector vous donne un environnement de travail pour gérer le processus de test dans sa globalité, de la conception à l'exécution et l'analyse. QADirector est une solution de gestion des tests efficace et extensible pour des tests complets du cycle de vie des applications distribuées étendues. D'un seul point de contrôle : •

Planification des tests

•

Exécution des tests

•

Variation des environnements de test

•

Analyse dynamique de l'application testée

•

Analyse des résultats des tests

•

Soumettre les problèmes


Une architecture ouverte intègre un large éventail d'outils de développement et de test automatisés requis pour tester complètement les applications tout en préservant les investissements existants. QADirector permet aux testeurs, aux développeurs et aux managers de tester complètement une application avec une réutilisation des tests, un partage des informations et une facilité d’utilisation améliorée.

65


LES OUTILS DE TESTS FONCTIONNELS

L’objectif des outils de génération de tests fonctionnels est de vérifier la conformité du fonctionnement d’un système vis-à-vis des exigences de l’utilisateur (plus globalement du cahier des charges). Ces outils évitent la création "manuelle" de scripts de tests, qui prend du temps et qui n’est pas forcément parfaite. Les éditeurs proposent donc des outils les plus complets possibles, en offrant un maximum de fonctionnalités automatiques (génération de scripts de tests, de rapports des résultats attendus et atteints ou non, etc.) et d’indicateurs graphiques pour une utilisation conviviale, aisée et rapide. Les outils de génération automatique de tests nécessitent une modélisation fonctionnelle (notation B, Statecharts Statemate et/ou UML selon l’outil). Dans le cas d’UML il s’agit de diagrammes de classe, d’activité et d’états / transitions avec expressions OCL. A partir de là, le modèle est analysé et, grâce à un moteur algorithmique propre à chaque éditeur, des scripts de tests sont générés, pour une couverture maximale des cas possibles. Ces scripts – scénarios – sont exécutés dans un environnement dédiés et les résultats analysés avec tableaux de résultats, etc. Ces scénarios peuvent être sauvegardés, modifiés et rejouer à volonté. Les outils de génération automatique de tests sont donc véritablement une valeur ajoutée pour les projets de grande taille où la complexité des fonctionnalités grèverait 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 génération automatique de tests. Prix de la meilleure innovation technologique de Capital-IT 2007 et Prix de l’Entreprise d’Avenir 2006 pour la Région Est, Leirios est un essaimage du Laboratoire Informatique (CNRS/INRIA) de l’Université de Franche-Comté.

Leirios, soutenu par OSEO/ANVAR, emploie 30 personnes entre Paris, Munich et Besançon, où sont implantés son siège social et sa R&D. LEIRIOS fait également partie des deux pôles de compétitivité TES (Transactions Electroniques Sécurisées) à Caen et Microtechniques à Besançon. Leirios développe des solutions permettant d'automatiser la conception des tests pour les applications et systèmes 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'améliorer fortement les processus de validation de systèmes.



Leirios Smart Testing est aujourd’hui utilisée par des grands industriels de la carte à puce ou de la monétique comme Austria Card, Gemalto, Giesecke & Devrient, Ingenico, Parkeon ou Sagem (SESAM VITALE 2)…

66

La société Leirios répond aux besoins de validation des systèmes logiciels par une offre en génération automatique de tests. Au coeur des activités de validation figure la conception des tests fonctionnels. Ces tests permettent de garantir la conformité d'une application, d'un système logiciel par rapport à ses spécifications initiales. Les pratiques actuelles, essentiellement manuelles et empiriques, constituent un facteur de non-qualité important pour les systèmes logiciels. Les solutions Leirios Test Generator intègrent cette technologie Smart Testing, technologie mise en œuvre depuis 1999 pour Schlumberger (dans les départements cartes à puces et terminaux urbains) et pour PSA Peugeot Citroën sur plusieurs projets d'envergure. Un transfert de propriété exclusif et complet de la technologie a été réalisé début 2003 entre l'Université de Franche-Comté et Leirios Technologies. Leirios Test Generator permet une réduction de plus de 30% de l'effort de conception des tests fonctionnels, avec une couverture des tests 2 à 5 fois supérieure. Les solutions de Leirios en génération automatique de tests permettent ainsi une meilleure maîtrise de la fiabilité des systèmes logiciels, une réduction des coûts de validation et une accélération du "time to market" des produits. Voici une présentation de l’utilisation de Leirios Test Generator (LTG) : 1. Une modélisation fonctionnelle est effectuée à partir des Spécifications Techniques de Besoins par l’utilisateur. 2. Le modèle fonctionnel résultant (B, Statecharts ou UML) est utilisé par le "générateur de tests LTG" pour créer les cas de tests. L’utilisateur paramètre simplement ses critères de couverture. 3. Le

"générateur

de

scripts

LTG"

compose

alors

les

scénarios

de

tests.


4. Les scripts ainsi créés sont exécutés dans l’environnement dédié (banc de test).

67


Exemples d’applications : •GSM 11-11 –gestion puce SIM •Java Card–JCVM mécanisme de transaction •Gestion des clés, des identités et de la sécurité •Fonctions visibilité générique –essuyage, dégivrage, lavage •Contrôleur 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 société Finlandaise Conformiq Software Ltd créée 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 : •

Test de fonction, de système et d'acceptance

•

Test de régression (tests quotidiens automatiques des structures)

•

Test d'intégration (simulation de parties du système)

•

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 modélisation

•

Support pour les modèles systèmes

•

Support pour les données structurelles de modèles de systèmes

•

Support simultané dans des modèles de systèmes

•

Support pour les communications temps réel

•

script de test par le biais d’interfaces « plug-in »

•

Livré avec la génération d’exemple de scripts « backends »

•

Construction de modèle d'analyse statique et débogueur

•

Support de la traçabilité et de la cartographie à des exigences élevées

•

Support des scénarios de tests et de cas d'utilisation de modèles pour d'autres modèles de conception axée sur la génération de tests

•

Support d’analyse de la valeur limite

•

Couverture générale des heuristiques de conception de tests

•

Transition UML au niveau de couverture et de l'état de conception de tests


heuristiques

69

•

Facilement paramétrable 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 modèles, des plug-ins et des testables systèmes


Avantages de Conformiq Test Generator •

Conformiq Test Generator est le seul outil qui permet d'effectuer des tests qui sont normalement très difficiles à tester, comme par exemple les problèmes de synchronisation.

•

Conformiq Test Generator garantit une meilleure efficacité de test, une baisse de la durée de phase de test et une plus grande couverture de test.

•

Supprime le risque d’erreur dans la conception des tests.

•

Support de développement pour l'ensemble des phases du projet et, en outre, pour tous les cycles de vie du logiciel.

•

Création 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 - modèles de test graphiques sont plus simples et plus rapides à entretenir et à réutiliser que les scripts de test.

•

Applique les exigences de la qualité de la documentation.

•

Résultats des tests et des couvertures de tests automatisés : les données formulées clairement facilitent la gestion des erreurs et aident à la correction des erreurs.

En plus de l'exécution des tests en ligne, Conformiq Test Generator peut également générer des scripts de test hors ligne qui pourront être utilisés plus tard. Conformiq Test Generator peut être intégré 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 complète du marché en matière d'automatisation des tests fonctionnels, d'interface utilisateur graphique et de nonrégression. 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 ingénieurs qualité peuvent utiliser Mercury Functional Testing pour créer des "scripts composés" qui comportent des tests élaborés dans WinRunner et QuickTest Professional. Mercury Functional Testing tire en effet profit de l'interopérabilité de WinRunner et de QuickTest Professional : chaque produit peut appeler les scripts de l'autre produit et les résultats des tests apparaissent dans une interface commune. La SOA est le moteur des résultats métier. La SOA augmente la complexité informatique et elle peut compromettre l'activité si elle n'est pas correctement mise en œuvre. Les décideurs informatiques prévoyants 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 réduit considérablement les durées de test et permet de s'assurer que les services répondront aux exigences de fonctionnement et de performances de l'entreprise avant de les déployer en production. Grâce à Mercury Service Test, vous pouvez : •

Réduire la durée des cycles d'assurance qualité en automatisant les tests fonctionnels, de non-régression et de performance des services qui ne sont pas dotés d'une interface graphique utilisateur.

•

Simuler

des

environnements

client

J2EE,

AXIS

et

.NET

pour

évaluer

l'interopérabilité des services. •

Simuler des environnements de production via la simulation des souches serveur

•

Tester différences interfaces SOA.

•

Créer et suivre les appels serveur pour garantir la réussite des tests de performances asynchrones.

•

Offrir des fonctionnalités d'émulation des services permettant aux testeurs de commencer très tôt, avant même la construction effective des services.



et les tests asynchrones.

72


HP est devenu un concurrent sérieux pour IBM avec l’outil Functional testing en comparaison avec Rational. Voici le résultat d’une étude de comparaison entre les deux outils :

73

S.NO

Criteria

1

Generation of Scripts

2

Rational Functional Tester *****

Mercury Quick Test Professional

Reason

***

Scripts

**

*****

3

Playback of the scripts

*

*****

4

Feature generate different cases

***

*****

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.

to test

5

Cost

*****

**

6

Accommodation of new versions of applications

*****

***

7

Script Reuse

*****

*****

8

Test Results

***

*****


Cette étude a été menée par l’université de l’Arizona Polytechnique. (Division of Computing Studies Arizona State University, Polytechnic [email protected]) Les environnements utilisés pour l’étude 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 d’automatiser la génération de vecteurs de test à partir d’outils de développement basés sur un modèle guidé par les exigences et la conception. Les solutions T-VEC permettent aux organisations de faire correspondre les cycles de vie des produits, des systèmes et du développement de logiciels aux objectifs commerciaux et aux besoins des clients afin d’améliorer de manière considérable la qualité et la prévisibilité, tout en réduisant de manière importante les délais de commercialisation et les coûts généraux. T-VEC a son siège social à Herndon, en Virginie (USA), et compte des clients dans des domaines variés tels que l’électronique aéronautique, l’aérospatial, l’automobile, la médecine et d’autres industries utilisant des produits intégrés. Test Driver Generation permet d’étendre à d’autre 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 propriétaires, plus….


Reactis de Reactive Systems - www.reactive-systems.com

75

Il s’agit d’un outil américain.


Le s Tests : L’état de l’Art Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information

76

• AutoTester ONE de AutoTester http://www.autotester.com/content/soft_at1.htm

Offre des tests fonctionnels, de régression 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 régression, 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 définition, les tests et la validation des fonctionnalités de solutions Web avant tout développement. • Mercury Business Process Testing de Mercury Interactive http://www.mercury.com/fr/products/quality-center/business-process-testing

Permet aux spécialistes "métier" et aux équipes "assurance qualité" de valider les processus métier automatisés. • TestView, WebFT de Radview http://www.radview.com/products/Index.asp

Solution permettant de définir des plans de tests automatisés d'applications Web tout en centralisant les scripts de ces tests. • Seapine SQA de Seapine http://www.ideotechnologies.com

Suite logicielle composée de trois outils permettant d'automatiser les tests fonctionnels, de gérer les défauts et les changements de configurations. • SilkTest de Segue http://www.borland.com/us/products/silk/silktest/index.html

Tests fonctionnels et de régression automatisés. 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 automatisés : tests fonctionnels, de régression et d'usabilité pour applications Web. • eValid de Software Research


http://www.soft.com/eValid

77

Vérifie la conformité aux spécifications fonctionnelles des sites Web. Multiples modes de synchronization possibles. HTTP/HTTPS, JavaScript, XML, Applets Java, Flash, ASP, JSP et ActiveX supportés. • Quality Forge de TestSmith http://qualityforge.com/testsmith/index.html

Automatisation de tests fonctionnels et de régression pour Windows. Les tests concernent les sites et des applications Web. Les langages supportés sont Java et C++.


• 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 complémentaires aux outils de tests fonctionnels qui vérifient, eux, ce que doit faire le logiciel. C’est 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

Société à capitaux privés fondée en 1987 par de jeunes diplômés de CALTECH (Institut de Technologie de Californie) ParaSoft Corporation a son siège en Californie avec des bureaux de distribution en Australie, en Inde, en Israël, en Chine, à Hong Kong, à Taiwan, au Brésil et au Japon. ParaSoft Europe, dont le siège social est en France, possède également des bureaux au Royaume-Uni et en Allemagne. Parmi les clients de ParaSoft, se retrouvent Nokia, Thomson, IBM, Ericsson, Alcatel, Philips, Cap Gémini et Boeing. ParaSoft développe et commercialise des outils de développement qui apporte une aide à la détection des erreurs dans les logiciels. En renforçant les standards de programmation et en automatisant le test unitaire, les technologies ParaSoft, uniques et très souvent primées, aident les utilisateurs à améliorer la qualité de leur logiciel, à accélérer la mise sur le marché et réduit considérablement les dépenses de développement. Depuis ses débuts, la société a été largement reconnue pour développer des technologies innovatrices en matière de logiciels et d'outils de programmation de haute productivité. ParaSoft a développé plusieurs produits liés au développement orienté objet et web.


Les technologies d’automatisation des tests de ParaSoft sont le résultat de 20 ans de R&D sur les erreurs logicielles et prouvent qu’améliorer la qualité permet de réduire les dépenses tout en augmentant la productivité.

79

Basées sur la méthodologie AEP (Automated Error Prevention), les outils ParaSoft mettent en œuvre une démarche de prévention, d’une part pour éliminer des erreurs avant qu’elles ne se manifestent dans les applications en production, et d’autre part pour éviter que les erreurs identifiées et corrigées suite à un dysfonctionnement ne se reproduisent. En pistant et simulant les chemins d’exécution automatiquement, la technologie Bug Detective révèle les bugs à l’exécution qui seraient difficilement détectables lors de tests ou inspections de code manuels. Les utilisateurs peuvent ainsi trouver, diagnostiquer et Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information

corriger les catégories d’erreurs logicielles qui échappent à l’analyse basée 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'exécution du code C, C++, Java et Ada.

•

Produit particulièrement adapté aux individus, qui écrivent du code pour les applications embarquées ou les autres types de produits informatiques nomades.

•

Prise en charge des applications critiques et confidentielles embarquées.

•

Proactivité extrême pour déboguer, détecter et corriger les erreurs avant qu'elles n'affectent le code de production.

•

Totalement compatible avec les autres solutions IBM Rational (développement piloté par modèles, 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 scène par le succès de l'Extreme Programming (XP), le développement 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 possibilités d'erreur. Le principe du TDD est donc, avant même 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.

C'est ici qu'entre en jeu l'architecture de test JUnit, destinée à tester le code Java. Plus largement, tous les langages activement utilisés disposent de leur équivalent xUnit : PHPUnit pour PHP, nUnit pour les langages .NET, ou AS2Unit pour ActionScript 2.0. Tous dérivent de SUnit pour Smalltalk, conçu 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.



Chaque fonctionnalité peut donc se retrouver avec plusieurs tests sur le dos, chacun vérifiant d'une manière différente le bon fonctionnement d'une petite partie de l'application. Parce qu'une application complète peut disposer de plusieurs milliers de tests, l'automatisation devient nécessaire.

80

La mise en place d'un test sur une méthode 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 prévoir, ou vérifiant le bon résultat d'un traitement. Les méthodes de test sont toutes précédées du marqueur @Test, ce qui permet à JUnit de les reconnaître et de les exécuter automatiquement. Chaque classe de test doit importer les paquetages org.junit.Test et org.junit.Test, JUnit étant installé et configuré pour le système ou l'outil de développement. JUnit 4.0 teste le code au moyen d'assertions, simulant diverses situations possibles. Ces assertions sont placées au cœur même des méthodes de la classe, aux côtés du code de l'application. Chaque assert*** placée 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 montée en charge.

•

La simulation d'un environnement spécifique.

•

L’évolution agressive de l'accès aux ressources.

Les tests de performances d'une application sont souvent menés pour des sites Web ou Intranet. En effet, lors du développement de sites Web il y a souvent des exigences quant aux performances d’accès au site (afin d’éviter des temps d’accès 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 scénarios 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 avancées 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 différents venant d’adresses IP hétéroclites ; chacune avec ses propres paramètres : cookies, données d'entrée pour différentes pages, nom et mot de passe, vitesse de connexion et son propre "chemin" dans l'application. WAPT peut même simuler un temps aléatoire entre les "clics d'utilisateurs" afin de rendre les actions de ces "utilisateurs virtuels" aussi réalistes que possible, proches de celles de véritables utilisateurs.

Par exemple, des utilisateurs d'un magasin en ligne peuvent être divisés entre ceux qui passent en revue le catalogue, et ceux connectés à une certaine page, ajoutant une charge spécifique. Pour chaque type vous créez un profil séparé ou toutes ses données peuvent être indiquées. A chaque test vous pouvez employer autant d'utilisateurs virtuels de chaque type que vous avez besoin. Les demandes HTTP peuvent inclure des paramètres spécifiques à chaque utilisateur. Les valeurs de tels paramètres peuvent même être différentes pour chaque utilisateur du même type et peuvent changer dans toute la session. Par exemple, le serveur peut Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information


Si vous voulez simuler des milliers d'utilisateurs, vous n'avez pas besoin d'indiquer le comportement séparé pour chacun d'eux. La pratique prouve qu'habituellement les visiteurs d'un site peuvent être divisés en plusieurs catégories – cette approche est employée par WAPT. Il suffit d’indiquer le comportement pour chaque type d'utilisateurs désiré, et vous ajoutez dans la campagne de tests autant de ces types d'utilisateurs dont vous avez besoin.

82

envoyer une variable de session en réponse à la première demande d'un nouvel utilisateur. Cette variable est ajoutée aux demandes suivantes de cet utilisateur afin de les identifier. Vous pouvez indiquer comment employer ces paramètres 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 période globale du test et le nombre d'utilisateurs virtuels pour chaque profil. La charge globale dépend également des types d'utilisateurs, ainsi les profils connectés peuvent varier au cour du test. Les résultats du test sont visualisés sous forme de rapports et de graphiques descriptifs. Ils sont disponibles à chaud pendant le déroulement du test. Ainsi vous pouvez surveiller les paramètres principaux de l'exécution des enchaînements en marches et suivre la réponse 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 montée en charge. L'avantage de LoadRunner par rapport a ses concurrents réside dans la multitude de types d'applications gérées. De plus, grâce à la précision des données obtenues, chaque test de charge fournit au développeur des résultats pouvant donner lieu à une action. Exemple : lors d'une transaction lente au niveau de l'utilisateur final, le développeur peut accéder à la méthode ou à l'instruction SQL présentant un goulet d'étranglement qui provoque le ralentissement.


LoadRunner évite les problèmes de performances coûteux rencontrés en production en détectant les goulets d'étranglement avant le déploiement d'un nouveau système ou d'une mise à niveau. Vous pouvez vous assurer que des applications nouvelles ou mises à niveau fourniront les résultats métier recherchés avant le déploiement, et ainsi éviter des dépenses excessives sur le matériel et l'infrastructure. Véritable référence du secteur en matière de prévision du comportement et des performances du système, ce produit constitue la seule solution intégrée de tests de charge, d'optimisation et de diagnostic proposée aujourd'hui sur le marché. Avec Loadrunner, vous pouvez évaluer les performances, les applications de diagnostic et les goulets d'étranglement sur le système du début à la fin et les régler pour obtenir une meilleure performance ; tout cela à partir d'un seul point de contrôle. Il prend en charge de nombreux environnements d'entreprise, notamment Web Services, J2EE et .NET.

83

Avec LoadRunner, vous pouvez : •

Obtenir un tableau précis des performances système de bout en bout.

•

Vérifier que les applications nouvelles ou mises à niveau répondent aux besoins de performances spécifiés.

•

Identifier et éliminer les goulets d'étranglement des performances pendant le cycle de vie du développement.


LoadRunner comprend désormais une technologie avec changement des jeux qui réduit le processus de création de scripts à quelques clics de souris. Web (Click and Script) for LoadRunner vous permet d'enregistrer des scripts sur une couche de présentation plus élevée. Il identifie automatiquement les meilleurs scripts et crée des scripts autoexplicatifs courts et intuitifs qui réduisent de 80 % la maintenance et le temps de création des scripts. Ces scripts sont également beaucoup plus simples à gérer puisque tout le monde a accès au script et peut rapidement en visualiser l'évolution à chaque message. Web (Click and Script) for LoadRunner diminue en plus les qualifications techniques nécessaires à 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 désavantage par rapport a un outil comme WAPT réside dans le fait qu'il ne dispose pas d'une interface utilisateur. Il peut jouer un scénario en lisant une liste d'URL à partir d'un fichier ou stresser une seule URL avec un nombre défini d'utilisateur. Ces URL peuvent être capturées et modifiées en fonction des besoins et pour faire varier les profils de test en utilisant Sproxy, un utilitaire de capture de trafic du même 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 décembre 1998 par Stefano Mazzocchi. Il est hébergé sur le site du Projet Jakarta. JMeter peut simuler de lourdes montées en charge sur une application serveur ou sur un réseau. Codé 100% en Java, interface graphique en Swing. JMeter permet de mesurer les performances de : Sites Internet

•

Serveurs FTP

•

Bases de données (via les drivers JDBC)

•

Scripts Perl

•

Objets JAVA (applets) Le s Tests : L’état de l’Art

•


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


C’est un portail de qualité industrielle de suivi et de reporting des performances de bases de données. En proposant une détection automatique des problèmes qui menacent la disponibilité et performance des bases supervisées par cet outil, l'administrateur de la base est informé de problèmes potentiels et peut ainsi agir d'une façon 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 effectués avec des utilisateurs virtuels en nombre important (plusieurs milliers) afin de mettre en évidence la capacité de charge du site web testé. Les caractéristiques :

Caractéristique

Description

Enregistrement &

temps de réponse et les tailles pour toutes les pages Web et leur contenu.

Analyse des pages

Tous les aspects des pages Web peuvent être examinés, dont les en-têtes de

Free Pro

Capturez des pages Web complexes lors de la navigation, en visualisant les Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

requête et de réponse, les cookies, les erreurs et le contenu. Les pages peuvent également être visualisées dans un navigateur intégré à Web Performance Analyzer. Spécifiez vos critères de performance et Web Performance Analyzer Détection des pages

marquera alors les pages trop lentes.

Web lentes

La plupart des erreurs dans le code HTML ou JavaScript ne sont pas Détection des erreurs

détectées par les navigateurs, et pourtant elles sont une cause de mauvais

d'Enregistrement

fonctionnement des applications Web. Déterminez exactement où vos pages Web sont cassées avant que cela ne devienne un véritable problème pour vos visiteurs.

Les Cas-Tests peuvent être personnalisés pour permettre à chaque rejeu Personnalisation de Cas- d'effectuer une variation de l'enregistrement original. Des valeurs de Tests remplacement peuvent être substituées pour les champs de formulaire, ce qui permet, par exemple, à chaque Rejeu successif de mesurer les performances d'un terme de recherche différent.

Les transactions individuelles peuvent être éditées pour personnaliser le comportement du Cas-Test. Chaque en-tête et chaque partie de l'URL peuvent être édités. Les transactions peuvent également être configurées avec les Modificateurs, qui changent la valeur de la requête dynamiquement pendant le rejeu.

Les champs de formulaires et les paramètres de requête d'URL peuvent être dynamiquement changés par les données saisies par l'utilisateur pour simuler des variations du Cas-Test initial, comme la recherche pour différents mots clés ou l'ajout de différents produits dans un panier d'achat.

bouton. Pendant le rejeu, chaque page peut être visualisée dans un navigateur pour observer l'impact visuel subjectif des changements et des optimisations. Le rejeu terminé, les changements sont comparés pour des changements objectifs cette fois-ci, comme la taille de la page, la comptabilisation des ressources, les temps de réponse, etc. Vos pages Web gagnent-t-elles ou perdent-elles en rapidité ? Web

Suivi des performances

Performance Analyzer archive les mesures de performance, et vous permet

dans le temps

de les suivre dans le temps. Alors que le projet passe par les étapes de développement, de test, puis de maintenance, les concepteurs peuvent s'assurer qu'aucun impact sur les performances de l'application ne passe



Tout enregistrement peut être rejoué en appuyant simplement sur un Rejeu de Session

86

inaperçu. Les pages Web qui ne répondent pas aux critères de performance sont alors marquées. En dehors de l'environnement de développement, les utilisateurs peuvent Voir avec les yeux de

faire l'expérience de performances moindres dues à des connexions réseau

l'utilisateur

avec des bandes passantes plus faibles, une congestion du réseau, aux

Oui

Oui

Non

Oui

serveurs proxy, etc. Enregistrez et rejouez avec un simulateur de modem pour vous retrouver dans les mêmes conditions que l'utilisateur disposant d'une faible bande passante.

Le rapport Bande Passante produit également des estimations de performance pour tous les niveaux de bande passante. -


Support SSL

87


Le coût d’une telle solution version professionnelle :

REF. PRIX €UROS H.T. PRODUIT

Licence Perpétuelle Fixe Web Performance Analyzer Pro 3.6 Version Française 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 Perpétuelle Fixe Web Performance Load Tester 100 VU - Version 3.6 Française sans WPLT3SSPL-100 maintenance - Livraison électronique

1.995,95

Licence Perpétuelle Fixe Web Performance Load Tester 100 VU - Version 3.6 Française 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 Perpétuelle Flottante Web Performance Load Tester 100 VU - Version 3.6 Française sans maintenance - Livraison électronique

WPLT3FPL-100

2.992,50

Licence Perpétuelle Flottante Web Performance Load Tester 100 VU - Version 3.6 Française 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 Perpétuelle Fixe Web Performance Advanced Server Analysis 100 VU - Version 3.6 Française sans maintenance - Livraison électronique

WPASA3SSPL-100

500,00

Module Optionnel - Licence Perpétuelle Fixe Web Performance Advanced Server Analysis 100 VU - Version 3.6 Française 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


DESIGNATION


88

VI - BILAN ET PERSPECTIVES

Les tests ont évolué au fil des années : -

de 1960 à 1980, il s’agissait d’une mise au point.

-

De 1980 à 1990, on a utilisé les tests afin de chercher et de trouver uniquement des erreurs. On réalisait des tests et cela fonctionnait plutôt bien.

-

Depuis 1990, les tests se veulent préventifs.

Longtemps abandonnés ou tout au moins minimisés, les tests sont aujourd’hui au centre de tous les intérêts : de nombreux progiciels ont vu le jour pour tester, gérer les versions… Des sociétés ont investi dans la création d’un service interne, véritable 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 données sont de plus en plus grands… Il était obligé que les tests occupent à nouveau au devant de la scène. Même 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 inégalé pour délocaliser l’utilisation de services informatiques. Réservé aujourd’hui aux applications (SaaS), au développement (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 ! L’Extreme Programming (Méthode agile de gestion de projets) a compris et intégré elle aussi les tests dans son cycle itératif de développement. L’Internet mobile, nouveau mode d’information et nouveau challenge pour les entreprises, est un support graphique différent nécessitant une programmation adaptée et donc des tests complémentaires.


Il semble bien que les tests sont aujourd’hui revenus sur le devant de la scène…

89


VII – CONCLUSION

Nous avons tenté de présenter le plus simplement possible l’intérêt des tests dans un projet de développement informatique. Nous espérons toutefois que ce document est suffisamment complet pour vous permettre d’avoir une connaissance globale sur les différentes techniques de tests. Il n’existe pas de techniques meilleures que d’autres : Tout dépend de nos besoins, de nos objectifs… Cependant, rien n’empêche de combiner plusieurs techniques. C’est d’ailleurs ce que nous préconisons. Avec l’importance croissante des projets informatiques, les risques de dysfonctionnement, de retards ou de pertes financières augmentent. La réussite et la rentabilité d’un projet passent par un suivi rigoureux, tout au long du processus, de la qualité de la réalisation. Il ne fait aucun doute que la politique de tests est aujourd’hui une dimension incontournable de la gestion de projet. Nous avons vu que les tests faisaient l’objet d’une pratique encore trop souvent artisanale mais que demain, dans un futur proche, les tests seront une activité rigoureuse fondée sur des modèles et des théories et qu’elle sera de plus en plus automatisée. C’est 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 nécessite une réactivité accrue des sociétés pour défendre leur place de marché.


Les tests sont aujourd’hui revenus sur le devant de la scène…


90

REFERENCES : BIBLIOGRAPHIE / « WEBOGRAPHIE » « Programmer » N°109 – 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 stratégie de test de montée 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é d’une suite d’opérations permettant de donner la réponse à un problème. Si ces opérations s’exécutent en séquence, on parle d’algorithme séquentiel. Si les opérations s’exécutent sur plusieurs processeurs en parallèle, on parle d’algorithme parallèle. API : Une interface de programmation (Application Programming Interface) est un ensemble de fonctions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logicielle, un système d'exploitation ou un service Benchmark : Un benchmark, en anglais, est un point de référence servant à effectuer une mesure. En informatique, il s’agit d’un banc d'essai permettant de mesurer les performances d'un système pour le comparer à d'autres. Bug : Un bug informatique (anglicisme) ou bogue informatique (francisation) est une déficience dans un programme informatique l’empêchant de fonctionner correctement. Sa gravité peut aller de bénigne (défauts d’affichage mineurs) à majeure. Les bugs résultent le plus souvent d’erreurs de programmation. Composant : Un composant est un élément d'un système rendant un service prédéfini et capable de communiquer avec d'autres composants. La programmation orientée composant a pris de l'ampleur avec l'avènement de l'objet. Cycle de vie : Il existe différents types de cycles de développement entrant dans la réalisation 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 phénomène qui peut survenir en programmation concurrente. L'inter blocage se produit lorsque deux processus légers (thread) concurrents s'attendent mutuellement. Les processus bloqués dans cet état le sont définitivement, il s'agit donc d'une situation catastrophique.

Effet tunnel : L’effet tunnel consiste en gestion de projet à gérer des phases longues dépourvues de points intermédiaires de contrôle. FIFO : L'acronyme FIFO est l'abréviation de l'expression anglaise First In, first Out, que l'on peut traduire par « premier arrivé, premier servi » (littéralement « premier entré, premier sorti »). Ce terme est employé en informatique pour décrire une méthode de traitement des données.



EDI : L'Échange de Données Informatisées (EDI) ou en version originale « Electronic Data Interchange », est le terme générique définissant un échange d'informations automatiques entre deux entités à l'aide de messages standardisés, de machine à machine. Dans la pratique, l'EDI permet de réduire notablement les interventions humaines dans le traitement de l'information, et donc de le rendre effectivement plus rapide et plus fiable.

92

Framework : En informatique, un framework est un ensemble de bibliothèques, d'outils et de conventions permettant le développement d'applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et dont la maintenance est aisée. Ces composants sont organisés pour être utilisés en interaction les uns avec les autres. Fuite mémoire :

GUI : En anglais, GUI est l’abréviation de « Graphical User Interface », soit « interface utilisateur graphique ». Elle s’oppose à CLI pour Command Line Interface, soit « interface en ligne de commande ». En France on peut parler d’IHM ou « interface homme-machine » ; par extension en anglais continental européen, on parle d’IHM et d’HCI. Historisation : En informatique, l’historisation est très souvent associée à la gestion des versions développées. Jalon : Un jalon correspond à une balise, un repère dans le projet qui est incontournable. Un jalon peut correspondre à une date de remise d’un livrable (document, produit logiciel…). Livrable : En informatique, un livrable correspond à une production. Il peut s’agir d’un document écrit, d’un composant informatique, d’un logiciel… Métrique : Une métrique logicielle est une mesure d'une propriété d'une partie d'un logiciel ou de ses spécifications (Exemple : « Combien d'instructions comporte ce module ? », « Quel pourcentage des spécifications client ont été traités ? »). Open source : La désignation Open Source s'applique aux logiciels dont la licence respecte des critères précisément établis par l'Open Source Initiative, c'est-à-dire la possibilité de libre redistribution, d'accès au code source, et de travaux dérivés. Processus : Un processus est une tâche en train de s'exécuter. On appelle processus l'image de l'état du processeur et de la mémoire au cours de l'exécution d'un programme. Un processus métier (ou procédure d'entreprise) est une suite d'opérations normalisées effectuées par toute ou partie des employés pour effectuer une tâche donnée. Prototype : Un prototype désigne le premier ou l'un des premiers exemplaires d'un produit.


Reporting : Le terme désigne une technique informatique consistant à extraire des données pour les présenter dans un rapport lisible (affichable ou imprimable).

93

Ressources informatiques : En informatique, les ressources sont des composants, matériels ou logiciels, connectés à un ordinateur. En gestion de projet, il n’est pas rare d’associer les intervenants à des ressources. Revue de code : La revue de code est un examen du code source d’un développement informatique. Risque : Le risque est la prise en compte par une personne de la possibilité de réalisation d'un évènement contraire à ses attentes ou à son intérêt. Lorsque la personne Dossier réalisé par Stéphane CALIMET, Philippe FIRMIN et Eric LELEU CNAM 2008 / 2009 – NFE209 – Audit et gouvernance des systèmes d’information

concernée agit malgré cette possibilité et s'expose ainsi à cette réalisation, on dit qu'elle prend un risque. La gestion du risque consiste en l’évaluation et l’anticipation des risques, et à mettre en place un système de surveillance et de collecte systématique des données pour déclencher les alertes. Scenario de test : Un scénario de test consiste en une procédure détaillée que le testeur doit suivre pour exécuter le cas de test (manipulations, saisie, résultat attendus…). Script : Un script est un programme en langage interprété. Spécifications fonctionnelles : Les spécifications fonctionnelles décrivent les processus métier auxquels le produit informatique devra répondre. Spécifications techniques : Les spécifications techniques décrivent le système informatique dans lequel le produit sera implanté, son interaction avec les autres composants du système informatique (Base de sonnées…). Tableau de bord : Regroupement d’indicateurs permettant la prise de décision.


Temps de réponse : Temps écoulé entre l'instruction donnée par l'utilisateur et la réalisation de cet ordre.


94

Tests_V10.00

Recommend Documents