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

118 Chapitre 4. Processus pour la validation de modèle AltaRica
spécification, elle ne remettent pas en causes l’utilisation et l’application de critère de couverture
sur le modèle AltaRica obtenu.
4.4.2 Génération de cas de test pour la validation de l’intégration
La validation de l’intégration est la phase de validation dans laquelle les composants unitaires
sont connectés (définition 4.5) et testés en tant qu’ensemble de composants. Brièvement,
on rappelle que connecter différents composants entre eux peut être vu comme un ajout d’un
certain nombre de contraintes dont il faudra tenir compte. Ainsi, après intégration, les possibilités
d’évolutions des composants sont réduites (par rapport à leurs évolutions possibles lorsqu’ils sont
considérés seuls) et avec elles le nombre de comportements possibles du composant. Sans développer
ici un processus pour cette phase de validation, nous nous permettons cependant quelques
mots à son sujet.
F out
A
Nous prendrons l’exemple de deux composants (deux automates de mode) A (FA
in = {i A},
= {o A}) et B (FB
in = {i B}, FB
out = {o B}) connectés de telle sorte que la sortie o A de A
soit reliée à l’entrée i B de B. On nomme C (noté C = A ↔ B) l’automate de mode résultat de
la connexion de A et B : FC
in = {i A}, FC
out = {o B}. On suppose la validation unitaire de A et
B réalisée et on souhaite tester le lien entre les deux composants.
Idée N°1 : Processus de validation unitaire sur A ↔ B
Cette première approche est fondée sur le fait que l’automate obtenu par composition de
deux automates de mode est un automate de mode (section 2.3.2). Ainsi, pour valider l’intégration
des composants A et B, on validera unitairement l’automate A ↔ B.
Cette approche, bien qu’ayant l’avantage de ne pas introduire de notions supplémentaires,
sera souvent difficilement applicable dans un cas réel. En particulier, l’automate A ↔ B devient
vite de taille importante et posséder une spécification d’un tel automate n’est pas chose aisée. La
génération de tests pourra souvent être compliquée à obtenir.
Idée N°2 : Faire du test fonctionnel
Le principe général proposé ici sera « d’oublier » le comportement interne au profit d’une
approche boîte noire (i.e. d’une approche fonctionnelle). Ce qui nous intéresse n’est alors pas
d’activer toutes les portions du modèle mais seulement les différentes interfaces que le composant
possède avec son environnement (on suppose que l’activation des parties internes a été obtenue
grâce à la validation unitaire).
Pour cela, nous souhaitons étudier la génération de scénarios de test pour l’automate A ↔ B
à partir des tests générés sur A et de ceux générés sur B (lors de la phase de validation unitaire
de A et B). Pour rappel et en commençant par considérer le composant A, un test est composé :
– d’un vecteur d’évènement v = (e i ) i≥0 où chaque e i est soit un évènement de A, soit une
déviation de la valeur d’entrée i A ;
– s l’évaluation attendue des variables d’état de A ;
– Φ A la variable de sortie de A ;
– ω A la valeur attendue de Φ A .
En ne s’intéressant pas au comportement interne de A, on obtient, pour la variable de sortie
Φ A , un ensemble de couples {scénario, valeur attendue} où les scénarios sont ceux obtenus de la
phase de génération de tests pour la validation unitaire (section 4.4.1). v Ai désigne le ième test
unitaire de l’automate de mode A.