Editorial
Il est rare que la revue TSI publie un numéro thématique consacré au test de logiciel. Dans le secteur académique, l’importance de ce domaine a été clairement reconnue dès l’avènement du génie logiciel, mais il n’a fait l’objet de recherches en nombres et résultats significatifs que depuis une dizaine d’années. Cet intérêt tardif pour le test réside dans l’énergie consacrée à l’époque aux approches de vérification fondées sur les différentes formes de preuve jugées plus prometteuses. Une seconde explication tient à l’insuffisance dans cette période lointaine de formalismes permettant de donner au test des fondements théoriques, et à la nature essentiellement empirique des activités de test dont se satisfaisait le secteur industriel. Pourtant, le test a toujours constitué le moyen primordial d’assurance de la qualité et de validation du logiciel, et son coût n’a fait que croître.
Les avancées réalisées dans la définition et la mise en œuvre des méthodes formelles concourent maintenant à l’élaboration de méthodes de test plus pertinentes (aptitude à révéler des défauts ou des erreurs), plus performantes (moins de cas de test, problèmes plus complexes), plus automatisables (génération des cas de test, des oracles ou des bancs de test), et donc plus susceptibles de valorisation industrielle. Pourtant, comme en témoignent les cinq contributions de ce numéro, l’intérêt scientifique semble surtout concentré sur l’assistance à la génération de tests.
Les méthodes de test reposent toutes sur l’exécution d’un programme, que ce dernier soit le code ou la spécification d’un produit logiciel (quand cette spécification est exécutable) ; un cas de test est représenté par un couple constitué des données (les entrées), et des résultats attendus (les sorties). Le moyen par lequel sont déterminés les résultats attendus et le verdict sanctionnant la conformité des résultats obtenus reçoit le nom d’oracle. Les méthodes de test sont analysables sous divers angles :
– en matière d’objectifs, elles peuvent être conçues en priorité comme moyen de validation au sens où leur portée est limitée à la révélation de défauts par rapport à des attentes non exprimées dans les cahiers des charges ou à la détection d’erreurs vis-à-vis de spécifications ; elles peuvent aussi être destinées à la vérification, c’est- à-dire à garantir que le code est conforme à la spécification (« test de conformité ») ; – si une méthode nécessite une connaissance du texte ou de la structure du code, elle relève du test structurel (« en boîte de verre ») ; au contraire, si elle est applicable en ignorant tout de ce texte, le test est pratiqué « en boîte noire » ; le cas intermédiaire est qualifié de test « en boîte grise » ;
– comme il n’existe pas de méthode de test universelle, les caractéristiques du logiciel auxquelles on s’intéresse dans chaque méthode doivent être énoncées : il peut s’agir d’exercer les fonctions du logiciel (test fonctionnel) ou d’observer le
Cet article des Editions Lavoisier est disponible en acces libre et gratuit sur tsi.revuesonline.com
1162 RSTI - TSI – 21/2002. Test de logiciel
respect de certaines propriétés (sûreté, confidentialité, performances…), enfin de rechercher des erreurs liées à des anomalies du code (test structurel) ;
– il existe essentiellement deux modes de génération des données d’entrée : le premier repose sur l’existence d’un critère de sélection des entrées parmi toutes les valeurs possibles et correspond à la génération déterministe, sinon cette génération est aléatoire.
Le premier article de ce numéro est le seul traitant du test structurel. Il décrit les principes de l’outil INKA automatisant la génération de tests structurels pour des logiciels écrits en C. Les données d’entrée sont engendrées de manière à assurer la
« couverture des branches » du graphe de contrôle du code. Une interprétation du code en programmation logique contrainte permet de construire, puis de résoudre, le système de contraintes caractérisant les entrées atteignant la branche cible.
Le deuxième article décrit une méthode de test fonctionnel à partir de spécifications formelles en B. Des techniques de programmation logique contrainte ensembliste permettent d’interpréter la spécification afin d’en dériver automatiquement la caractérisation d’états limites à partir desquels sont exercés les différents comportements de chaque opération. Des séquences de test pour exercer et observer ces comportements sont obtenues par résolution des systèmes de contraintes correspondants. L’approche est évaluée sur un fragment de la norme GSM 11_11.
Dans l’article suivant, les auteurs décrivent un cadre formel pour le test de conformité à partir de spécifications algébriques, qui formalise l’ensemble des étapes du processus de test et des critères de sélection des données d’entrée. Il explicite aussi la transposition des cas de test abstraits en des exécutions du programme qui permettent d’affirmer le succès ou l’échec du test. Des exemples sont fournis pour les langages CASL (spécification) et ADA (programmation).
Le test fonctionnel et le test de propriétés de sûreté des logiciels spécifiés en Lustre sont présentés dans le quatrième article. Le test fonctionnel est ici fondé sur une simulation de l’environnement du logiciel à tester. Cette simulation consiste en une génération aléatoire de données d’entrée qui satisfont les spécifications de l’environnement. Le simulateur et l’oracle sont automatiquement construits à partir des spécifications par l’outil Lutess. Le test de propriétés est intégré comme une spécialisation de la simulation favorisant l’apparition de certains comportements.
Le dernier article traite de la génération automatique de cas de test pour la vérification de la conformité d’un code avec sa spécification, ces deux derniers étant modélisables sous la forme de systèmes de transitions. Cette génération est réalisée automatiquement par l’outil TGV à partir de la spécification et d’objectifs de test (représentés par des automates). Les fondations théoriques ainsi que les algorithmes de génération « à la volée » de l’outil TGV sont présentés en détail.
Bruno MARRE, CEA, Gif-sur-Yvette Farid OUABDESSELAM, LSR-IMAG, St Martin d’Hères
Cet article des Editions Lavoisier est disponible en acces libre et gratuit sur tsi.revuesonline.com
