Méthodes pour la validation de modèles formels pour la ... - ISAE

110 Chapitre 4. Processus pour la validation de modèle AltaRica
4.3.3 Test boîte noire - Test boîte blanche
4.3.3.1 Test boîte noire
L’approche de test de type « boîte noire » (aussi nommé test fonctionnel) est une des deux
principales approches de conception des tests appliqués aux logiciels pour vérifier la conformité
d’un logiciel par rapport à sa spécification. On cherche ainsi à détecter les différents cas où le
comportement du modèle est différent de celui attendu, i.e. dans quelles circonstances le comportement
du modèle est différent de celui prédit par sa spécification ?
En suivant cette approche, les différents cas de test sont construits à partir de l’examen de
la spécification, sans se référer à la structure du code testé. La spécification permet de déterminer
à la fois les cas importants à considérer et les valeurs attendues dans les cas sélectionnés.
Une préoccupation importante est alors celle de la complétude des cas de test considérés
par rapport à la spécification. Dans l’idéal, un test exhaustif de toutes les entrées du modèle
permettrait de s’assurer du bon comportement de celui-ci, quelles que soient les circonstances.
Bien souvent cependant et à cause de la complexité des modèles à éprouver, une telle exhaustivité
sera impossible à satisfaire. Pour répondre à cette question, on pourra établir des critères de
couverture de la spécification utilisée pour construire les tests.
La notion peut être facilement transposée aux tests de modèle si la spécification du modèle
est connue. L’approche consiste alors à considérer le modèle comme une boîte noire dont on ne
considère pas la structure interne : on soumet des entrées choisies à partir de la spécification du
modèle, on regarde la sortie (on ne sait pas comment celle-ci est obtenue) et la spécification du
modèle est à nouveau utilisée pour décider de l’acceptabilité de la sortie obtenue.
4.3.3.2 Test boîte blanche
L’autre approche de conception des tests est le test « boîte blanche » ou test structurel.
Dans ce cas, on suppose la structure interne du modèle connue et la sélection des jeux de tests
tient compte de la logique implémentée dans le modèle.
Cette approche permet, entre autre, d’affiner la définition des tests fonctionnels en leur
permettant d’explorer des parties relativement distinctes du programme/modèle évalué. La complétude
des parties du programme/modèle exercées par les tests peut alors être mesurée à l’aide
de critère de couverture structurelle de l’implémentation.
Dans notre cas, le but sera, par exemple, de passer par tous les chemins du modèle et permettra
par exemple, d’exécuter des scénarios improbables voire non souhaités (scénarios auxquels
potentiellement le programmeur ou l’utilisateur n’avait pas pensé). On parlera alors de critère de
couverture du modèle (Cf. section 4.3.4).
4.3.3.3 Exemple
En pratique, il est important de combiner les deux types d’approche de conception des
tests comme le montre l’exemple ci-dessous. Imaginons donc que l’on souhaite implémenter un
programme calculant la somme de deux entiers modulo 10000 et que nous l’implémentions de la
façon, fausse, suivante :