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

120 Chapitre 4. Processus pour la validation de modèle AltaRica
4.4.3 Génération de cas de test pour la validation système
D’une manière générale, expliquer la raison d’être de cette étape de validation du modèle du
système est chose plus complexe que pour les précédentes. En effet, l’objectif n’est pas réellement
de tester le comportement du modèle dans les détails puisque cela a déjà été en théorie effectué
par la phase de validation de l’intégration. L’objectif est plutôt de s’assurer que les propriétés
tenues par le système réel sont elles aussi tenues par le modèle. Ces propriétés peuvent être :
– un ou plusieurs scénarios de test dont on connaît l’issue sur le système réel (par exemple, la
présence d’une barrière de sécurité limitant l’effet de certaines défaillances) ;
– une propriété générale que l’on sait vérifiée par le système réel (si le réservoir carburant est
vide, alors il n’y aura pas de carburant à la sortie des injecteurs).
Si la propriété est exprimée sous forme de scénario de test, la vérification sera fondée sur
la simulation de ce scénario sur le modèle. La sortie effectivement obtenue sera comparée à celle
attendue (souvent, cette valeur sera issue du retour d’expérience ou du jugement d’expert). Dans
le second cas, on parle par exemple de propriétés exprimées en logique temporelle et qui pourront
être vérifiées sur le modèle par model-checking [38].
Il existe une large littérature à ce sujet : le scénario « système » est encodé par un automate,
un observateur ou une formule de logique temporelle. Les model-checkers sont ensuite utilisés pour
obtenir des chemins qui rendent vrai l’observateur « objectif de test ». Sous Cecilia TM OCAS, l’outil
de génération de séquences rempli cette tâche. Il ne reste plus alors qu’à mesurer les chemins du
modèle couverts par les cas de test.
Des cas de test pour les différents niveaux de validation étant obtenus, il nous faut à présent
évaluer leurs qualités. Pour cela, deux possibilités peuvent être étudiées.
– Critères de couverture par rapport à la spécification de référence du modèle AltaRica. Cette
couverture varie en fonction du niveau de validation souhaité et en fonction de la forme
de la spécification présente en entrée. Ainsi, par exemple, une AMDE doit être couverte à
la fois pour la phase de validation unitaire (pour valider les effets locaux des défaillances)
et pour la phase de validation de l’intégration ou système (pour tester et valider les effets
globaux des défaillances).
– Critères de couverture par rapport au code AltaRica exercé. Ici, nous définissons des critères
de couverture directement applicable sur un modèle AltaRica, quelque soit le niveau de celuici.
Ainsi, les critères sont les mêmes pour les différentes phases de validation. La couverture
totale du modèle AltaRica devra être effective après la réalisation de l’ensemble des cas de
test.
Dans la suite de ce chapitre, nous détaillons la définition et la mise en place de critère de
couverture permettant de mesurer quelle portion de modèle AltaRica est testée par les différents
cas de test.