Projet : LANDE - lande

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00"> <h2><a name="SECTION00034000000000000000" id= "SECTION00034000000000000000">Test de logiciels</a></h2>  <a name="LANDE_fondements_module-6" id= "LANDE_fondements_module-6"></a> <p><a name="letest" id="letest"></a></p> <p><strong>Mots clés :</strong> <i>critère de test, hypothèse de test, test unitaire, test d'intégration, test fonctionnel, test système, test en boîte noire, test en boîte blanche, test structurel .</i></p> <div id="glossaire" style= "margin-left: 2em;margin-right: 2em;"> <hr /> <dl title="Glossaire"> <dt><b>Jeu de test</b></dt> <dd><i>Un jeu de test est un ensemble de données de test.</i></dd> <dt><b>Critère de test</b></dt> <dd><i>Un critère permet de spécifier formellement un objectif (informel) de test. Un critère de test peut, par exemple, indiquer le parcours de toutes les branches d'un programme, ou l'examen de certains sous-domaines d'une opération.</i></dd> <dt><b>Validité</b></dt> <dd><i>Un critère de test est dit valide si pour tout programme incorrect, il existe un jeu de test non réussi satisfaisant le critère.</i></dd> <dt><b>Fiabilité</b></dt> <dd><i>Un critère est dit fiable s'il produit uniquement des jeux de test réussis ou des jeux de test non réussis. Les jeux de test satisfaisant un critère fiable sont donc équivalents du point de vue du test.</i></dd> <dt><b>Complétude</b></dt> <dd><i>Un critère est dit complet pour un programme s'il produit uniquement des jeux de test qui suffisent à déterminer la correction du programme (pour lequel tout programme passant le jeu de test avec succès est correct) [<a href="bibliographie_Toc.html#Xantakis" target= "contents">XMd+94</a>]. Tout critère valide et fiable est complet.</i></dd> <dt><b>Hypothèse de test</b></dt> <dd><i>La complétude étant hors d'atteinte en général, on peut qualifier un jeu de test par des hypothèses de test qui caractérisent les propriétés qu'un programme doit satisfaire pour que la réussite du test entraîne sa correction</i></dd> </dl> <hr /> </div> <h3>Résumé :</h3> <div class="ABSTRACT"> <p><i>Le test comporte une grande variété de tâches qui comprend notamment la conception des jeux de test, leur instrumentation, leur exécution, le dépouillement des résultats et la sélection des tests de non-régression (en cas de modification des programmes). La plupart de ces étapes repose sur l'empirisme et l'aide fournie par les outils actuels reste insuffisante. Cependant, certaines de ces tâches peuvent être systématisées et même, dans une certaine mesure, mécanisées. La génération de jeux de test en fait partie et sa systématisation constitue l'objectif majeur des activités du projet Lande sur ce thème. Les principales difficultés à résoudre concernent la formalisation des critères de test et l'analyse des documents d'entrée (spécification ou code source) pour engendrer des données constituant un jeu de test satisfaisant. Le bénéfice d'une telle systématisation est double : d'une part les jeux de test ainsi produits sont de meilleure qualité que ceux que peut inventer un testeur (et justifiés par rapport à un critère précis) ; d'autre part, la possibilité de mécaniser le procédé (au moins partiellement) apporte des gains significatifs en terme de productivité.</i></p> </div> <p>On distingue généralement quatre types de tests, chacun étant lié à l'une des phases de conception des logiciels. Les premiers tests soumis au logiciel ont pour cible les composants élémentaires de l'application à tester. Pour cette raison, ils sont appelés <em>tests unitaires</em> (on trouve aussi le terme <em>test de composant</em>). La seconde phase de test, les <em>tests d'intégration</em>, correspond à la phase d'intégration progressive des différents composants élémentaires qui ont déjà passé avec succès l'épreuve des tests unitaires. L'objectif est de mettre en évidence les dysfonctionnements engendrés par leur assemblage. Les <em>tests fonctionnels</em> sont ensuite exécutés sur l'application dont tous les composants ont été assemblés et intégrés. Le dernier type de test s'applique à la version complète de l'application déployée dans son environnement d'exécution. Ces tests, que l'on nomme <em>tests système</em>, consistent à détecter des fautes ou des comportements incorrects de l'ensemble du système en situation réelle. Les <em>tests de recette</em> sont des tests système.</p> <p>Pour concevoir ces différents types de test, il existe un ensemble de techniques qui se décompose en deux familles [<a href="bibliographie_Toc.html#Xantakis" target= "contents">XMd+94</a>]. La première famille réunit les techniques de test dites en <em>boîte noire</em> qui reposent sur une spécification (informelle, semi-formelle ou formelle) du programme. Le code du programme est considéré inaccessible et n'est pas utilisé pour sélectionner les données de test. Les tests produits sont dits <em>fonctionnels</em>.</p> <p>La seconde famille est constituée des techniques de test dites en <em>boîte blanche</em> qui s'appuient exclusivement sur des analyses du code de l'application [<a href= "bibliographie_Toc.html#Beizer" target="contents">Bei90</a>]. Ces techniques reposent sur l'examen de la structure du programme et le calcul de flots de contrÔle ou de données. Les tests produits sont dits <em>structurels</em>.</p> <p>Le test comporte une grande variété de tâches qui comprend notamment la conception des jeux de test, leur instrumentation, leur exécution, le dépouillement des résultats et la sélection des tests de non-régression (en cas de modification des programmes). La plupart de ces étapes repose sur l'empirisme et l'aide fournie par les outils actuels reste insuffisante. Cependant, certaines de ces tâches peuvent être systématisées et même, dans une certaine mesure, mécanisées. La génération de jeux de test en fait partie et sa systématisation constitue l'objectif majeur des activités du projet Lande sur ce thème. Les principales difficultés à résoudre concernent la formalisation des critères de test et l'analyse des documents d'entrée (spécification ou code source) pour engendrer des données constituant un jeu de test satisfaisant. Le bénéfice d'une telle systématisation est double : d'une part les jeux de test ainsi produits sont de meilleure qualité que ceux que peut inventer un testeur (et justifiés par rapport à un critère précis) ; d'autre part, la possibilité de mécaniser le procédé (au moins partiellement) apporte des gains significatifs en terme de productivité.</p> </body>