• Aucun résultat trouvé

2.4 Une approche BDD pour les tests d’int´ egration syst` eme

3.1.2 Conception du langage pivot

Les proc´edures d’essai automatis´ees de l’ATA 21 fournies par l’un des partenaires du projet ACOVAS prennent la forme de tableaux. Ces tableaux listent les actions d’affectation sur les param`etres avioniques manipul´es et les assertions du test. Les actions d’affectation stimulent le SUT alors que les assertions v´erifient les r´eponses qu’il produit. Ces tableaux sont transform´es en code ex´ecutable par des programmes sp´ecifiquement d´evelopp´es pour ces besoins. La figure 3.2 est un extrait d’une proc´edure tabulaire. La premi`ere colonne (Task description) d´ecrit l’intention de la liste des affectations ou d’assertions contenues dans le bloc de test. La deuxi`eme colonne (Time) d´ecrit le temps ´ecoul´e depuis le d´ebut de l’ex´ecution de la proc´edure. Le nom de l’outil ou de l’interface utilisateur permettant de r´ealiser les actions pour ce bloc de test est pr´ecis´e `a la troisi`eme colonne (Control desk screen). Les param`etres formels manipul´es sont sp´ecifi´es par la quatri`eme colonne (Item) ; chaque param`etre fait r´ef´erence `a un param`etre d’un outil, de l’interface utilisateur ou bien peut correspondre `a un param`etre r´eel du SUT. La colonne qui suit (Unit ) indique l’unit´e du param`etre utilis´e pour cette action. Enfin la derni`ere colonne (Value to be applied ) est la valeur `a appliquer au param`etre ou la valeur attendue.

La lecture et la compr´ehension des proc´edures tabulaires sont rendues complexes de par la prolif´eration des param`etres avioniques et des param`etres pour manipuler les outils et interfaces de contrˆole du test. Ces param`etres sont utilis´es pour d´ecrire la liste des actions `a r´ealiser lors d’un test. Des phrases sont appos´ees en regard de chaque bloc regroupant une liste d’affectations et d’assertions. Elles d´ecrivent succinctement l’intention des affectations et assertions r´ealis´ees par le bloc. Beaucoup de sigles sp´ecifiques au contexte sont utilis´es dans ces phrases, rendant la compr´ehension de la proc´edure complexe.

Nous avons reconsid´er´e ces proc´edures tabulaires en collaboration avec les experts de l’ATA 21 pour produire des proc´edures de test avec une syntaxe textuelle. Les proc´edures textuelles informelles produites avec les experts testeurs ont une syntaxe tr`es ´epur´ee : tr`es peu de mots-cl´es sont utilis´es et les diff´erents param`etres avioniques ne sont pas masqu´es dans la proc´edure. Elles ont ´et´e ´ecrites pour la d´emonstration finale du projet ACOVAS. Le niveau d’abstraction utilis´e pour ces proc´edures est assez fin pour permettre de les transformer ais´ement en code ex´ecutable : les param`etres avioniques r´eels sont visibles dans la syntaxe du langage. Nous avons donc choisi de concevoir un premier langage `a partir de cette syntaxe textuelle et de consid´erer ce langage comme niveau interm´ediaire de traduction des proc´edures formalis´ees par les DSTL de notre framework.

Ces proc´edures textuelles proposent un premier bloc (Initial conditions) permettant d’initialiser l’´etat du mod`ele d’environnement (Environment parameters) et les param`etres de test (Test parameters). La figure 3.3 montre un exemple d’un bloc d’initialisation pour ces proc´edures textuelles.

Figure 3.3 – Bloc d’initialisation

Ce bloc d’initialisation rejou´e entre chacun des tests permet de remettre le SUT dans l’´etat de d´epart ad´equat. Il est suivi de plusieurs blocs de test, correspondant chacun `a un comportement diff´erent `a tester. Les diff´erences entre les cas de test d’une mˆeme proc´edure peuvent ˆetre minimes. Un bloc de test est aussi caract´eris´e par un commentaire explicitant son intention. La figure 3.4 est un exemple de cas de test. Ce bloc de test v´erifie que le

syst`eme r´epond aux consignes de temp´erature pour les deux zones dans le temps imparti et que cette temp´erature est constante pendant un certain laps de temps. Il s’assure ensuite que le changement de la consigne de temp´erature pour une des deux zones est bien pris en compte par le syst`eme et que ce changement n’a pas d’impact sur la temp´erature de l’autre zone. Les deux zones ayant des temp´eratures diff´erentes, le syst`eme doit maintenant ˆ

etre capable de maintenir ces temp´eratures stables pendant une minute. Pour ce test, les vannes d’alimentation ont un d´ebit d’air de 0,2 Kg/s pour les deux zones de l’avion.

Figure 3.4 – Bloc de test

La structure du langage pivot reprend la structure des exemples de proc´edures propos´es par les figures 3.3 et 3.4 : un bloc d’initialisation est li´e `a plusieurs blocs de test. Les blocs de test sont compos´es de trois types d’instructions : l’affectation, le wait et le check. Nous avons formalis´e l’affectation par l’instruction set et n’autorisons que l’affectation d’un seul param`etre `a la fois, pour faciliter la lisibilit´e et le d´ebogage des tests avioniques. Plusieurs affectations peuvent ˆetre demand´ees en mˆeme temps dans les proc´edures ex´ecutables afin de rendre les tests plus rapides `a l’ex´ecution. L’instruction check during v´erifie l’´etat d’un ou plusieurs param`etres avioniques durant un certain temps. Les besoins couverts par la clause WAIT sur les exemples sont formalis´es dans le langage par l’instruction check until associ´ee `a une contrainte de temps.