Précédent : Filtrage de programmes (slicing) Remonter : Analyse dynamique Suivant : Les langages de programmation logique

Génération de jeux de tests

Participants : Daniel Le Métayer, Valérie-Anne Nicolas, Olivier Ridoux, Lionel Van Aertryck

Le test représente une part importante de l'activité de développement et de maintenance des logiciels. La systématisation des différentes étapes du cycle de test permettrait d'en réduire considérablement le coût et offrirait des moyens de gérer l'évolution conjointe des logiciels et de leurs jeux de tests. L'une des étapes de l'activité de test est la génération des jeux (ou données d'entrée) adéquats. Les techniques de génération proposées se classent en deux familles. Celles qui reposent sur une analyse du texte du programme sont appelées tests en boî te blanche (ou structurels) et celles qui testent les fonctionnalités d'un programme sans disposer de son code sont appelées tests en boî te noire (ou fonctionnels).

Nous avons abordé le problème de la systématisation de la génération de jeux de tests en tentant d'abolir la dichotomie boî te noire/boî te blanche. Pour ce faire, nous décomposons le processus de production des données de tests en trois étapes:

1. L'acquisition des critères de tests et la production des hypothèses de test associées, à partir de différents supports d'entrée.
2. La décomposition des opérations en classes d'opérations et la génération d'un arbre d'accessibilité symbolique.
3. La génération des jeux de tests par parcours de l'arbre en assurant un critère de couverture donné.

Les supports d'entrée peuvent être constitués de spécifications formelles ou informelles, de programmes sources ou de propriétés fournies directement par l'utilisateur. Dans tous les cas, les critères de tests se traduisent in fine par des propriétés appelées hypothèses d'uniformité et hypothèses de régularité. Ces hypothèses permettent de préciser le sens (et les limites) des jeux de tests qui seront engendrés. Nous nous intéressons maintenant à la manière d'assurer que des programmes sont conformes à ces hypothèses: cette assurance peut être obtenue par construction (contrôle a priori), ou par vérification (contrôle a posteriori) quand il s'agit de code existant.

Précédent : Filtrage de programmes (slicing) Suivant : Les langages de programmation logique Remonter : Analyse dynamique