CNAM 2008 / 2009 - CENTRE REGIONAL DE LILLE NFE209 – AUDIT ET GOUVERNANCE DES SYSTEMES
D’INFORMATION
Les Tests : L’état de l’Art
Tests et Validation du logiciel
rt
AUDITEURS
AUDITEUR NUMEROD’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 Introduction, Les tests et le cycle de vie
V_2.0 15/04/2009 S. CALIMET, E. LELEU Avantages inconvénients des
cycles
V_3.0 30/04/2009 S. CALIMET, E. LELEU Tests d’intégration V_4.0 19/05/2009 S. CALIMET, E. LELEU Tests de charge V_5.0 21/05/2009 S. CALIMET, E. LELEU Tests Validation (Fonctionnel) V_6.0 28/05/2009 S. CALIMET, E. LELEU Test Validation (Structurel) V_7.0
03/06/2009 S. CALIMET, E. LELEU 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
LES TESTS : L’ETAT DE L’ART
TESTS ET VALIDATION DU LOGICIEL
SOMMAIREPREAMBULE :NECESSITE DES TESTS ... 5
I-INTRODUCTION AUX TESTS LOGICIELS ... 6
1–QUELQUES EXEMPLES DE BUGS ... 6
2–LESDEFINITIONS DES TESTS ... 6
3–LES CLASSES DE DEFAUT ... 8
4–DIFFICULTES LIEES AUX TESTS ... 8
5–LES DIFFERENTES FACONS DE CLASSIFIER LES TESTS ... 10
LE MODE D’EXECUTION ... 10
LES MODALITES DE TEST ... 10
LES METHODES DE TEST ... 11
LES NIVEAUX DE TEST ... 11
LES CARACTERISTIQUES DE TEST ... 11
6–EXEMPLE DE CLASSEMENT SELON 3 AXES ... 12
7–QUELQUES PRINCIPES UTILES ... 12
II–LA STRATEGIE DE TESTS ... 13
1–GENERALITES ... 13
2–L’ACTIVITE TEST ... 15
III–TYPES DE TESTS DANS LE PROJET ... 17
1–LES TESTS ET LE CYCLE DE VIE ... 17
2–LES TESTS UNITAIRES ... 24
3–LES TESTS D’INTEGRATION ... 28
4–LES TESTS DE CHARGE ... 32
5–LES TESTS DE VALIDATION ... 38
rt
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 OUTILSD’AIDEALAREALISATIONDESTESTS ... 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 OUTILSDECAMPAGNEDETEST ... 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 OUTILSDETESTSFONCTIONNELS ... 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 OUTILSDETESTSSTRUCTURELS ... 79
C++TEST,.TEST,JTEST,SOATEST ET INSURE++ DE PARASOFT ... 79
Le s Tests : L’état de l’Art
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
rt
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.
Le s Tests : L’état de l’Art 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 :
« 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. »
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. »
rt
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. »
Le s Tests : L’état de l’Art 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.
rt
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...
Le s Tests : L’état de l’Art 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.
rt
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 :
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
Le s Tests : L’état de l’Art 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).
rt
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 :
- 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
Le s Tests : L’état de l’Art 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
rt
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 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…
o Définir les responsabilités et relations entre les différents intervenants.
o Définir les types et les objectifs de tests pour chacun des niveaux (tests unitaires, tests d’intégration, tests de validation).
o Définir les outils qui seront utilisés.
o 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 Maximisant les chances de détecter les erreurs.
o Tentant de trouver le plus d’erreurs possibles, le plus rapidement possible.
o 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.
o Au dossier de SPECIFICATION correspond le plan de tests de VALIDATION.
o Au dossier de CONCEPTION GENERALE correspond le plan de tests
Le s Tests : L’état de l’Art Un plan de test doit :
o Définir les éléments à tester et l’ordre dans lequel ils doivent être testés (planifier les tests).
o Décrire l’environnement de tests.
o 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.
o 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 ».
o 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 Exécution des fiches de tests (effectuer les actions décrites).
o Analyser les résultats obtenus : comparer les résultats attendus avec les résultats obtenus. Les éléments de mesure sont très importants !
o 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.
o Consigner tous les résultats d’exécution de tests.
o 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.
rt
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
Le s Tests : L’état de l’Art 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.)
rt
• 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.
Source : adaptée de http://fr.wikipedia.org/wiki/Cycle_de_développement Expression des
besoins et faisabilité
Spécification Fonctionnelle et
technique
Conception globale
Conception détaillée
Développement
Recette
Qualification
Intégration
Tests unitaires
Le s Tests : L’état de l’Art 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.)
rt
• 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.
Développement d'un prototype Validation des
besoins
Analyse du risque Planification du
prochain cycle
1
2 5
6
Le s Tests : L’état de l’Art 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.
rt
• 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 d'analyse
• Phase de conception
• Phase d'intégration
• Phase 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.
Source : http://fr.wikipedia.org/wiki/Cycle_de_développement Expression des
besoins et faisabilité
Spécification Fonctionnelle, technique
Conception globale
Conception détaillée
Développement
Tests de recette
Tests de charge, tests de validation
Tests d’Intégration
Tests unitaires
Le s Tests : L’état de l’Art 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.
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é.
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.
rt
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 l’objet
Evénement Déroulement du test Résultats attendus
OK/KO
FAC001 Consultation facture
Rechercher la facture XXX Appuyer sur le bouton
« Imprimer »
Impression facture XXX
OK
Bas de page : Remarques :
………
………
………....
Le s Tests : L’état de l’Art
• 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
L'analyse dynamique structurelle consiste à vérifier la structure du code ainsi que les variables.
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...).
rt
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.
Le s Tests : L’état de l’Art 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.
Le périmètre couvert :
o Livraison des différents modules ou composants.
o Vérification du fonctionnement des composants.
o Vérification du dialogue entre les modules (compatibilité, appel, passage de paramètres…).
o Prévision et anticipation d’un retour à une version antérieur en cas d’incident.
rt
• 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
2 2
Le s Tests : L’état de l’Art 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
Source : Réalisé par Eric LELEU pour illustration 3
2 2
1 1
rt
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.
Le s Tests : L’état de l’Art 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 La performance (au travers essentiellement des temps de réponse) o La montée en charge (Maintient des fonctionnalités sous la charge,…)
o 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
Il existe plusieurs types de tests de charges permettant d’atteindre les objectifs cités précédemment :
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.
rt
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 Préparer les tests (dossier de test, étude de faisabilité technique) o Créer les scripts (QUOI)
o Créer les scénarios (COMMENT) o Exécuter les scénarios
o Analyser les résultats
o Améliorer le système (Tuning système) o 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 :
o La description de l’application
o Le descriptif des transactions QUOI o Le descriptif des scripts
o Les scénarios
o Le planning COMMENT
o Le plan de charge
o Les objectifs à atteindre POURQUOI o La configuration
o Les jeux de données. AVEC QUOI
Le s Tests : L’état de l’Art La préparation des tests a aussi pour but de réaliser une étude de faisabilité
technique sur les outils et leur environnement :
− 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
rt
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.
− 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
Le s Tests : L’état de l’Art
− 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 Source : Livre Blanc « Choisir une stratégie de test de montée en charge » de Borland
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.
rt
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 Des erreurs se produisent-elles dans des conditions particulières de charge ? o Quelle est la capacité système requise pour les couches de l'application ? o L'application pourra-t-elle satisfaire les niveaux de services requis ? o L'application est elle optimisée pour offrir les meilleurs performances ?
o 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 ?
o L'application est elle prête pour un déploiement intégral ?
Le s Tests : L’état de l’Art 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.
- ….
rt
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 Ensemble de
toutes les valeurs possibles Comportement 1
1 Valeur limite
Le s Tests : L’état de l’Art 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.
rt
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, B=1), (A=1, B=0), (A=1, C=1), (A=1, C=0) (A=0, B=1), (A=0, B=0), (A=0, C=1), (A=0, C=0) (B=1, C=1), (B=1, C=0)
(B=0, C=1), (B=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.
Le s Tests : L’état de l’Art 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).
Source : Réalisé par Eric LELEU pour illustration Logiciel Archivage
Créer une archive Ajouter fichier(s) à une archive existante
1 Fichier Plusieurs Fichiers 1 Fichier Plusieurs Fichiers
rt
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.
Source : Réalisé par Eric LELEU pour illustration Satisfaction
Effort Test Déterministe
Test Aléatoire
Le s Tests : L’état de l’Art 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
rt
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 :
Source : Réalisé par Eric LELEU pour illustration
« 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) !
A1
A2
A3
B1
B2 C1
B3
Le s Tests : L’état de l’Art 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.
Exemple de contrôle :
o Taux de commentaires o Intérêt des commentaires o Variables non initialisées o Gestion des indices de tableau o Conversion de types
o Division par zéro
o Terminaison des boucles
o Sortie d’une procédure ou fonction o …
