Eclipse Modeling Framework (EMF) Ecore

Télécharger le fichier pdf d’un mémoire de fin d’études

Methodologies de developpement de tests

Les methodologies de developpement de test donnent des lignes directrices que les ingenieurs de test utilisent quand ils developpent des tests. L’objectif est de delivrer du code de test de haute qualite (par exemple, annote avec des commentaires, structure, comprehensible, document et reutilisable). L’ouvrage [69] o re une vue d’ensemble des pratiques existantes, ainsi que des etudes sur des cas reels.
Cet ouvrage discute notamment des techniques d’ecriture de scripts de test. Cinq techniques de script sont presentees, chacune avec ses forces et ses faiblesses: lineaire, structuree, partagee, guidee par les donnees de script et guidee par des mots cles.
La comparaison de la sortie du systeme sous test avec la sortie attendue (probleme de l’oracle) est egalement discutee. En n, [69] se penche sur les questions concernant les outils de gestion de tests, l’organisation et la conduite des tests, ainsi que sur les parametres permettant la mesure de la qualite des tests.
Ces methodologies sont la plupart du temps informelles, se trouvant dans les doc-uments textuels que les ingenieurs de test sont censes lire et appliquer.

Formalismes de developpement de tests et outils as-socies

Les formalismes de developpement de tests et les outils associes sont des technologies qui permettent la production de cas de test qui sont automatiquement executables sur une plate-forme de test donnee. Trois grands types de solutions peuvent ^etre identi es: les outils de capture & rejeu, les frameworks de test, les langages de test et la modelisation des tests. Des exemples illustrant chaque type de solution sont discutes plus en detail dans la Section 2.4 du tome en anglais de ce memoire.
Modelisation de tests La modelisation de tests se base sur l’hypothese que les cas de test sont des logiciels, et en tant que tels peuvent bene cier des methodes et technologies avancees issues du genie logiciel, comme par exemple l’ingenierie dirigee par les modeles (MDE) [92]. L’utilisation des approches MDE dans le monde du test est un domaine de recherche actif, bien que les publications existantes ne soient pas nombreuses. Nous ne parlons pas ici des techniques de selection de test basees-modeles telles que celles deja discutees dans la Section 2.1. L’accent est ici sur l’implementation des tests.
La plupart des travaux existants sur l’implementation de tests utilisent le Uni ed Modeling Language (UML) [93] pour les modeles de test. Un pro l UML pour le test – UML Testing Pro le (UTP) [94] – a et standardise par le Object Management Group (OMG) [129]. Plusieurs projets ont porte sur l’integration de UTP et du langage de test Testing and Test Control Notation Version 3 (TTCN-3) [83], tels que [95]. Un meta-modele pour TTCN-3 peut ^etre trouve dans [96], plus tard encapsul dans la plate-forme TTworkbench [97]. Un projet similaire chez Motorola [98] utilise la suite d’outils TAU [99].
Certains auteurs ont propose leurs propres pro ls UML. Un pro l UML et des transformations de modeles pour le test d’applications Web sont discutes dans [100]. Dans l’avionique, la modelisation UML de logiciels de simulation pour le test modele-en-boucle est proposee dans [101]. Toujours dans l’avionique, [102] propose des modeles de test conformes a un meta-modele de test (integrant des formalismes basees-automates), pour la deuxieme generation de Integrated Modular Avionics (IMA) [103]. Des travaux anterieurs par les m^emes auteurs incluent la modelisation de tests basee sur des auto-mates pour leur plate-forme RT-Tester [104, 105].
Les meta-modeles de langages de l’ITU-T, tels que TTCN-3 ou Speci caton and Description Language (SDL), sont etudies dans [106]. L’objectif est de s’abstraire des grammaire concretes Backus{Naur Form (BNF) et utiliser un ensemble de concepts fondamentaux partages par une famille de langages. Des concepts identi es par des experts sont utilises comme support pour la construction de meta-modeles pour chaque langage.
D’autres artefacts utilises pendant les tests, en plus des cas de tests eux-m^emes, peuvent bene cier de l’ingenierie dirigee par les modeles. Par exemple, la modelisation de l’environnement du systeme sous test est discutee dans [107].
Dans le m^eme esprit que les di erents travaux ci-dessus, nous nous sommes con-centres sur l’utilisation de l’ingenierie dirigee par les modeles pour le developpement de tests. Le partenaire industriel de ce projet, Cassidian Test & Services, est un four-nisseur d’outils d’automatisation de l’execution des tests et de plates-formes de test pour des composants et systemes avioniques embarques.

La plateforme de test

Pour un systeme avionique embarque, une plate-forme de test a normalement les elements suivants :
un contr^oleur de test, des ressources de test, un reseau de test,
un langage du test.
Le traitement de la logique de test est centralise: le contr^oleur de test execute les tests ecrits dans un langage pris en charge par la plate-forme. Au cours de l’execution, des commandes sont envoyees aux ressources de test permettant d’e ectuer les interac-tions reelles avec le systeme sous test. Le reseau de test comporte deux parties, l’une reliant le contr^oleur de test aux ressources de test (reseau de commande de test) et l’autre reliant les ressources de test au systeme sous test (reseau d’interaction de test).

Intervenants et evolution des besoins

Le test d’integration des systemes avioniques inclut les types suivants d’intervenants : des fournisseurs de solutions de test, des utilisateurs de solutions de test :
{ avionneurs,
{ equipementiers, { systemiers.
Nous avons eu l’occasion de discuter et recueillir les besoins exprimes par des representants de tous ces types d’intervenants.
Historiquement, l’avionneur etait en charge de toute l’activite d’integration des systemes embarques avioniques. De nos jours, il y a un transfert de l’activite de l’avionneur vers les fournisseurs d’equipements et ceux-ci sont invites a participer a la premiere phase d’integration. Les equipementiers deviennent des systemiers, avec de nouveaux besoins en termes d’echanges de tests avec l’avionneur. Dans la pratique, la portabilite des tests d’un environnement a un autre ne peut pas ^etre facilement atteinte, ce qui freine ces echanges. Au fait de la multitude d’outils d’execution de test proprietaires, les fournisseurs de solutions de test ont de leur c^ote a tenir compte des di erentes habitudes de leurs clients. Des capacites de personnalisation sont donc exigees pour repondre aux demandes des utilisateurs.
Aucun langage de test standard n’existe ou emerge pour le test en-boucle de systemes avioniques embarques. Ceci contraste avec d’autres domaines qui utilisent des normes internationales, par exemple: Abbreviated Test Language for All Systems (ATLAS) [112] et Automatic Test Mark-up Language (ATML) [113] pour le test du materiel (phases de production et de maintenance du cycle de vie) ou TTCN-3 [82] dans le domaine du test des protocoles de telecommunication et des systemes distribues. Ces solutions standardisees ne sont pas concues pour repondre aux speci cites de notre contexte industriel et ne sont pas directement reutilisables en tant que telles.
D’autres besoins portent sur la lisibilite et la facilite d’ecriture des tests par les ingenieurs.
Toutes ces exigences ont motive notre orientation vers des descriptions de tests de haut-niveau, independantes des plate-formes de test, avec des fonctionnalites de generation automatique de code. Ce travail se concentre sur l’introduction d’une ap-proche dirigee par les modeles pour le developpement de tests pour le test en boucle de systemes avioniques embarques.

Analyse des langages de test

Nous presentons et analysons ici un echantillon de six langages de test. Nous avons choisi quatre langages de test proprietaires utilises dans notre contexte industriel, ainsi que deux langages de test supplementaires issus d’autres domaines. Cette analyse nous a permis d’identi er l’ensemble des concepts speci ques au domaine, qui ont par la suite et integrees dans le meta-modele de test sous-jacent a notre approche. En outre, cette analyse nous a egalement permis d’identi er les meilleures pratiques, ainsi que les pieges a eviter.
La Section 4.1 presente notre echantillon de six langages de test et decrit notre methode d’analyse. La Section 4.2 discute les fonctionnalites generiques presentees par les langages de test. Les Sections 4.3 a 4.6 discutent les fonctionnalites liees au test. Nous en avons identi quatre grandes categories :
l’organisation des tests (Section 4.3),
l’abstraction et l’acces aux interfaces du SUT (Section 4.4),
les instructions du langage pour piloter les tests et interagir avec le SUT (Section 4.5),
la gestion du temps (Section 4.6).
La Section 4.7 presente une liste de principes qui ont guide notre travail ulterieur de meta-modelisation, basee sur les resultats de l’analyse des langages de test. La Section 4.8 conclut ce chapitre.

Echantillon de langages de test

L’echantillon de langages de test comprend :
quatre langages de test propritaires du domaine avionique, qui seront nommes PL1, PL2, PL3 et PL4,
TestML [114] du domaine de l’automobile,
Testing and Test Control Notation Version 3 (TTCN-3) [82, 83] du domaine des reseaux et telecommunications.
Les quatre langages de test de proprietaires, de PL1 a PL4, sont des langages utilises de facon operationnelle dans l’industrie aeronautique. Le premier represente l’o re de Cassidian Test & Services sur la plate-forme de test d’integration U-TEST Real-Time System [3]. L’identit des trois autres ne peut pas ^etre divulguee.
TestML est issu d’un projet de recherche dans le domaine de l’automobile. Son objectif etait de concevoir un langage d’echange, dans le sens indique par la Figure 4.1. TestML represente une tentative pour synthetiser des preoccupations decoulant de la pratique des tests en boucle, son examen a donc et juge pertinent pour nous.
TTCN-3 est utilise dans le test de systemes distribues et des protocoles de communi-cation. Il est inclus dans notre echantillon, car les systemes embarques avioniques sont egalement des systemes distribues, et leur communication est basee sur des interfaces conformes a un large eventail de protocoles de communication.
Notre approche a consiste a identi er les fonctionnalites que les langages de test dans notre echantillon o rent, conjointement avec les ressemblances et les di erences sur la facon dont elles sont o ertes. Dans le cas ou une fonctionnalite n’est pas o erte par un langage de test ou est o erte de di erentes manieres, nous avons contacte les ingenieurs de test pour des clari cations.
Dans le tome en anglais de ce memoire, les caracteristiques que nous avons analysees sont synthetisees dans des vues schematiques puis discutees. Nous nous bornons ici a reprendre la liste des idees clefs qui conclut chaque discussion. Nous allons d’abord donner les caracteristiques generiques de l’echantillon de langages de test (Section 4.2), et par la suite continuer avec les fonctions liees au test (Sections 4.3 a 4.6).

Caracteristiques generiques Idees clefs

I Les langages de test speci ques o rent un vocabulaire personnalisable, concis et de haut-niveau, speci que au domaine.
I Les langages de test bases sur des langages generiques de programmation perme-ttent la reutilisation des fonctionnalites et des outils existants.
I Les langages de test interpretes ne necessitent pas une nouvelle etape de compi-lation chaque fois que le code est modi e.
I La pratique actuelle, parmi les partenaires de Cassidian Test & Services, favorise un paradigme de programmation imperatif.
I Une solution de test independante de la plateforme de test est souhaitable, avec une separation claire entre le noyau du langage de test et les adaptateurs de test speci ques a la plate-forme.

L’organisation des tests

L’organisation intra-test se refere a la description structuree d’un test. Nous nous concentrons ici sur les types d’organisation intra-test, parce que l’organisation inter-test est generalement geree par des outils externes.
Nous discutons des formes d’organisation intra-test telles que: l’organisation semantique des instructions (Sous-section 4.3.1) et l’organisation des ots de contr^ole paralleles (Sous-section 4.3.2).

Organisation semantique des instructions

Idees clefs
I Les sections de test sont utiles pour l’identi cation d’un test – en-t^ete de test, et pour l’organisation du comportement d’un test en parties distinctes.
I Des sections de test peuvent ^etre de nies suivant une methodologie basee sur des annotations ou en les integrant a l’interieur du langage de test.

L’organisation des ots de contr^ole paralleles

Idees clefs
I Deux types de ots de contr^ole ont et identi es: explicite (les ingenieurs de test de nissent le comportement parallele et contr^olent son execution, en employant des composants de test) et implicite (les ingenieurs de test utilisent des instruc-tions prede nies, comme une stimulation de rampe, qui s’executent en parallele).
I Des constructions de haut-niveau, telles que les composants de test, masquent les details d’implementation multi-t^ache.
I La communication entre composants de test peut utiliser des evenements ou des donnees partagees.
I Les interfaces formelles permettent la reutilisation et l’instanciation multiple de composants de test.
I Di erents types de composants de test sont utilises, tels que: des composants de test periodiques (pour l’elaboration de modeles d’environnement du SUT et de stimulations complexes) et des moniteurs de test (comportement condition ! action, pour une visibilite amelioree de la logique de test).
I Les concepts comportementaux et structurels peuvent ^etre separes, avec de la generation automatique de code pour les derniers.
I L’architecture des liens entre les composants de test est statique dans notre con-texte industriel.

Lien avec les interfaces du systeme sous test

Niveaux hierarchiques cibles et abstraction des interfaces du SUT

Idees clefs
I Les interfaces du SUT sont toujours abstraites par l’intermediaire d’identi ants derives de l’ICD.
I L’architecture des liens entre les interfaces des composants de test et les interfaces du SUT est statique dans notre contexte industriel.

Instructions des langages de test

Identi ants et acces aux interfaces du SUT

Idees clefs
I Les mecanismes d’acces aux interfaces du SUT sont heterogenes, d’un niveau hierarchique a l’autre, mais ainsi au sein d’un m^eme niveau hierarchique de l’ICD.
I La structure de l’ICD n’est que partiellement re etee par les langages de test.
I Passer l’identi ant d’un element ICD en parametre comme une cha^ne de car-acteres ne permet pas la veri cation statique des types.
I L’acces global aux elements de l’ICD est pratique.

Instructions des langages de test

Les principales categories des instructions liees au test sont les suivantes : l’interaction avec le systeme sous test (Sous-section 4.5.1) et la gestion du verdict (Sous-section 4.5.2).

Interaction avec le systeme sous test

Idees clefs
I Les langages de test pour le test en boucle o rent de nombreuses instructions d’interaction avec le systeme sous test, de di erents types.
I L’organisation des instructions a l’interieur des langages de test est heterogene.
I Une politique d’organisation coherente serait souhaitable, avec des points d’extension prede nis.
I Passer les actions de test comme parametres textuels a des instructions generiques ne permet pas la veri cation statique de type (par exemple, il est possible d’appeler une action de test incompatible avec le type de l’interface du SUT ciblee).
I Avoir des interfaces fortement-typees, auxquelles on attache les actions de test o ertes, est un principe interessant d’organisation.

Eclipse Modeling Framework (EMF) Ecore

Nous avons retenu EMF Ecore [119] comme langage de meta-modelisation. EMF per-met d’acceder a des outils associes pour produire des editeurs graphiques specialises (Graphical Modeling Framework (GMF) [121], Graphiti [122]), editeurs textuels (Xtext [123]), veri cateurs (Object Constraint Language (OCL) [124]), ainsi que des generateurs de code (Acceleo [125], Xpand [126]).

ProviderData et UserData

La racine du meta-modele de test est la Database. Elle contient deux parties: ProviderData et UserData. Il s’agit d’un premier choix important de meta-modelisation : l’utilisateur de la solution de test recoit un modele de test pre-instancie de la part du fournisseur de la solution de test, ou seule la partie ProviderData est remplie. Le fournisseur de la solution de test a la possibilite de creer di erentes variantes pour ses clients, ainsi que mettre a jour celles qui existent deja. La partie du fournisseur de la solution de test o re des points d’extension pour des types de SUT, des types d’interfaces, des bo^tes a outils et des actions de test associees.

TestContext

La partie UserData contient des elements TestContext. Le concept de contexte de test est inspire de celui propose dans le UML Testing Pro le (UTP) [94]. Il sert de conteneur pour une collection de cas de test appliques a un SUT, avec une architecture de composants de test.
Le SystemUnderTest decrit les interfaces de l’entit testee selon son ICD. Le Test-Case contr^ole l’execution parallele d’elements TestComponent. Un composant de test peut ^etre instancie plusieurs fois dans un cas de test, via des elements TestComponent-Instance. Les composants de test interagissent avec le SUT. Ils peuvent egalement in-teragir les uns avec les autres, par l’intermede d’elements SharedData et Event declares globalement dans le contexte de test. Pour l’architecture de test, nous avons de ni une politique avec un producteur et potentiellement plusieurs consommateurs. La Test-Architecture associee a un cas de test determine l’instance du composant de test qui produit une certaine donnee globale ou un evenement. Elle relie egalement les inter-faces formelles (le cas echeant) d’un composant de test avec les interfaces du SUT, les donnees partagees ou les evenements. Les cas de test peuvent ^etre regroupes au sein soit d’elements TestSuite (pour la de nition de l’ordre d’execution) soit TestGroup (pour grouper des tests qui partagent une propriet commune).
Sur le plan conceptuel, le contexte de test est en fait divise en trois niveaux hierarchiques : concepts structurels de haut-niveau (par exemple, TestCase, TestComponent), concepts structurels de bas-niveau (par exemple, la TestSection d’un TestCase), concepts comportementaux (par exemple, TestCaseStatement, TestComponent- Statement).

Concepts structurels de haut-niveau

Les diferents concepts structurels de haut-niveau de notre meta-modele sont:
SystemUnderTest, TestCase,
TestComponent et la gestion du verdict,
TestArchitecture,
TestGroupe et TestSuite.
Ces concepts sont decrits dans le tome en anglais de ce memoire, dans les Sous-sections 5.4.1 a 5.4.6.

Concepts structurels de bas-niveau

Tous les concepts structurels de haut-niveau (le cas de test et les types de composants de test) ont leur comportement organise en des concepts structurels de bas-niveau.
Un cas de test organise son comportement a l’interieur de conteneurs TestSection. Un composant de test organise son comportement a l’interieur de conteneurs Test-ComposantElement. Un moniteur de test a un TestMonitorPredicateElement et un TestMonitorContainerElement. Un composant de test sequentiel a un ensemble d’elements SequentialBlock.
En n, un composant de test cycle-par-cycle a un certain nombre de concepts struc-turels de bas-niveau qui permettent a un ingenieur de test de speci er des comporte-ments di erents pour chaque cycle ou sequence de cycles : Cycle, IteratedCycle et ConditionRepeatedCycle. En instanciant les elements decrits ci-dessus a plusieurs reprises, un ingenieur de test peut facilement speci er un comportement complexe, tel que celui present dans la Figure 5.2.

Table des matières

Glossaire
1 Introduction 
2 Etat de l’art – Le test 3 
2.1 S´election de test
2.2 Oracle de test
2.3 M´ethodologies de d´eveloppement de tests
2.4 Formalismes de d´eveloppement de tests et outils associ´es
2.5 Conclusion
3 Contexte industriel
3.1 Syst`eme avionique embarqu´e
3.1.1 Cycle de vie et activit´es de test
3.1.2 Document de contr^ole d’interface (ICD)
3.1.3 Comportement r´eactif
3.2 La plateforme de test
3.3 Intervenants et ´evolution des besoins
3.4 Conclusion
4 Analyse des langages de test 
4.1 Echantillon de langages de test
4.2 Caract´eristiques g´en´eriques
4.3 L’organisation des tests
4.3.1 Organisation s´emantique des instructions
4.3.2 L’organisation des flots de contr^ole parall`eles
4.4 Lien avec les interfaces du syst`eme sous test
4.4.1 Niveaux hi´erarchiques cibl´es et abstraction des interfaces du SUT
4.4.2 Identifiants et acc`es aux interfaces du SUT
4.5 Instructions des langages de test
4.5.1 Interaction avec le syst`eme sous test
4.5.2 Gestion du verdict
4.6 Gestion du temps
4.7 Principes guidant la m´eta-mod´elisation
4.8 Conclusion
5 M´eta-mod`ele de test 
5.1 Eclipse Modeling Framework (EMF) Ecore
5.2 ProviderData et UserData
5.3 TestContext
5.4 Concepts structurels de haut-niveau
5.5 Concepts structurels de bas-niveau
5.6 Concepts comportementaux
5.7 Environnement de d´eveloppement de mod`eles de test
5.8 Conclusion
6 Impl´ementation des mod`eles de test 
6.1 Outil mod`ele-vers-texte Acceleo
6.2 PL5: un langage de test bas´e sur Python
6.3 Architecture des modules/motifs Acceleo
6.4 Conclusion
7 Cas d’´etude 
7.1 FWS – Synth`ese d’alarme incendie moteur
7.2 ADIRS – Valeur consolid´ee de la vitesse de l’avion
7.3 Conclusion
8 Conclusion et perspectives 
Bibliographie 

Télécharger le rapport complet