Développement de tests pour systèmes avioniques embarqués

Développement de tests pour systèmes avioniques
embarqués

Sélection de test 

A l’exception de cas triviaux, le test exhaustif de tous les comportements possibles que ` peut présenter un système n’est pas réalisable. Par conséquent, un petit nombre de cas de test qui couvrent un sous-ensemble du domaine d’entrée doit être identifié. La sélection peut être guidée par des critères liés à un modèle de la structure du système ou des fonctions qu’il offre. Ces deux catégories donnent lieu au test structurel  et fonctionnel. Le test structurel définit des éléments couvrir dans un modèle de type graphe de contrôle , éventuellement enrichi par des informations sur le flot des données . Pour le test fonctionnel, il n’existe pas de modèle standard (tel que le graphe de contrôle). Par conséquent, le test fonctionnel couvre un large éventail de méthodes et de techniques, qui dépendent du formalisme utilisé pour modéliser le comportement du système. Des approches bien connues incluent : • des décompositions du domaine d’entrée en classes de valeurs [28, 29], • des modélisations à états , • des spécifications algébriques , • des tables de décisions, • des profil d’utilisation probabilistes . Pour une présentation détaillée de la sélection de test, y compris des informations sur son industrialisation, le lecteur peut se référer aux ouvrages existants . 

Oracle de test

 L’analyse automatique des résultats de test est souhaitable et devient nécessaire quand un grand nombre d’entrées du système sous test ont été sélectionnées. Les solutions les plus satisfaisantes sont basées sur l’existence d’une spécification formelle du logiciel cible, utilisable pour déterminer les résultats attendus. Le test dos-à-dos représente une autre solution pour le problème de l’oracle de test, en particulier pour les systèmes qui ont de la diversification fonctionnelle à des fins de tolérance aux fautes. D’autres solutions d’oracles de test partiels peuvent être employées, en utilisant des contrôles de vraisemblance sur les résultats des tests. Des contrôles plus sophistiqués utilisent des invariants qui peuvent également prendre en compte des aspects temporels . Des assertions/contrats exécutables peuvent également être inclus dans le code logiciel 

Méthodologies de développement de tests 

Les méthodologies de développement de test donnent des lignes directrices que les ingénieurs de test utilisent quand ils développent des tests. L’objectif est de délivrer du code de test de haute qualité (par exemple, annoté avec des commentaires, structuré, compréhensible, documenté et réutilisable). L’ouvrage offre une vue d’ensemble des pratiques existantes, ainsi que des études sur des cas réels. Cet ouvrage discute notamment des techniques d’écriture de scripts de test. Cinq techniques de script sont présentées, chacune avec ses forces et ses faiblesses: linéaire, structurée, partagée, guidée par les données de script et guidée par des mots clés. La comparaison de la sortie du système sous test avec la sortie attendue (problème de l’oracle) est également discutée. Enfin, se penche sur les questions concernant les outils de gestion de tests, l’organisation et la conduite des tests, ainsi que sur les paramètres permettant la mesure de la qualité des tests. Ces méthodologies sont la plupart du temps informelles, se trouvant dans les documents textuels que les ingénieurs de test sont censés lire et appliquer. 2.4 Formalismes de développement de tests et outils associés Les formalismes de développement de tests et les outils associés sont des technologies qui permettent la production de cas de test qui sont automatiquement exécutables sur une plate-forme de test donnée. Trois grands types de solutions peuvent être identifiés: les outils de capture & rejeu, les frameworks de test, les langages de test et la modélisation des tests. Des exemples illustrant chaque type de solution sont discutés plus en détail dans la Section 2.4 du tome en anglais de ce mémoire. Modélisation de tests La modélisation de tests se base sur l’hypothèse que les cas de test sont des logiciels, et en tant que tels peuvent bénéficier des méthodes et technologies avancées issues du génie logiciel, comme par exemple l’ingénierie dirigée par les modèles (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 sélection de test basées-modèles telles que celles déjà discutées dans la Section 2.1. L’accent est ici sur l’implémentation des tests. La plupart des travaux existants sur l’implémentation de tests utilisent le Unified Modeling Language (UML)]pour les modèles de test. Un profil UML pour le test – UML Testing Profile (UTP) – a été standardisé par le Object Management Group (OMG) . Plusieurs projets ont porté sur l’intégration de UTP et du langage de test Testing and Test Control Notation Version 3 (TTCN-3) , tels que [95]. Un méta-modèle pour TTCN-3 peut être trouvé 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 proposé leurs propres profils UML. Un profil UML et des transformations de modèles pour le test d’applications Web sont discutés dans [100]. Dans l’avionique, la modélisation UML de logiciels de simulation pour le test modèle-enboucle est proposée dans [101]. Toujours dans l’avionique, [102] propose des modèles de test conformes à un méta-modèle de test (intégrant des formalismes basées-automates), pour la deuxième génération de Integrated Modular Avionics (IMA) [103]. Des travaux antérieurs par les mêmes auteurs incluent la modélisation de tests basée sur des automates pour leur plate-forme RT-Tester [104, 105]. Les méta-modèles de langages de l’ITU-T, tels que TTCN-3 ou Specificaton and Description Language (SDL), sont étudiés dans [106]. L’objectif est de s’abstraire des grammaire concrètes Backus–Naur Form (BNF) et utiliser un ensemble de concepts fondamentaux partagés par une famille de langages. Des concepts identifiés par des experts sont utilisés comme support pour la construction de méta-modèles pour chaque langage. D’autres artefacts utilisés pendant les tests, en plus des cas de tests eux-mêmes, peuvent bénéficier de l’ingénierie dirigée par les modèles. Par exemple, la modélisation de l’environnement du système sous test est discutée dans [107]. Dans le même esprit que les différents travaux ci-dessus, nous nous sommes concentrés sur l’utilisation de l’ingénierie dirigée par les modèles pour le développement de tests. Le partenaire industriel de ce projet, Cassidian Test & Services, est un fournisseur d’outils d’automatisation de l’exécution des tests et de plates-formes de test pour des composants et systèmes avioniques embarqués.

Table des matières

Liste des Figures
Liste des Tableaux
Glossaire v
1 Introduction
2 Etat de l’art – Le test
2.1 Sélection de test
2.2 Oracle de test
2.3 Méthodologies de développement de tests
2.4 Formalismes de développement de tests et outils associés
2.5 Conclusion
3 Contexte industriel
3.1 Système avionique embarqué
3.1.1 Cycle de vie et activités de test
3.1.2 Document de contrôle d’interface (ICD)
3.1.3 Comportement réactif
3.2 La plateforme de test
3.3 Intervenants et évolution des besoins
3.4 Conclusion
4 Analyse des langages de test
4.1 Echantillon de langages de test
4.2 Caractéristiques génériques
4.3 L’organisation des tests
4.3.1 Organisation sémantique des instructions
4.3.2 L’organisation des flots de contrôle parallèles
4.4 Lien avec les interfaces du système sous test
4.4.1 Niveaux hiérarchiques ciblés et abstraction des interfaces du SUT
4.4.2 Identifiants et accès aux interfaces du SUT
4.5 Instructions des langages de test
4.5.1 Interaction avec le système sous test
4.5.2 Gestion du verdict
4.6 Gestion du temps
4.7 Principes guidant la méta-modélisation
4.8 Conclusion
5 Méta-modèle 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éveloppement de modèles de test
5.8 Conclusion
6 Implémentation des modèles de test
6.1 Outil modèle-vers-texte Acceleo
6.2 PL5: un langage de test basé sur Python
6.3 Architecture des modules/motifs Acceleo
6.4 Conclusion
7 Cas d’étude
7.1 FWS – Synthèse d’alarme incendie moteur
7.2 ADIRS – Valeur consolidée de la vitesse de l’avion
7.3 Conclusion
8 Conclusion et perspectives
Bibliographie

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *