FR2921170A1

FR2921170A1 - Procede de generation automatique de programmes de test d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre

Info

Publication number: FR2921170A1
Application number: FR0757615A
Authority: FR
Inventors: Famantanantsoa Randimbivololona
Original assignee: Airbus Operations SAS
Current assignee: Airbus Operations SAS
Priority date: 2007-09-14
Filing date: 2007-09-14
Publication date: 2009-03-20
Anticipated expiration: 2027-09-14
Also published as: RU2010114709A; WO2009047430A3; CN101802792A; CA2696020A1; RU2473115C2; WO2009047430A2; FR2921170B1; JP2010539576A; EP2188723A2; CN101802792B; US20110047529A1; BRPI0817102A2

Abstract

L'invention concerne un procédé pour générer des programmes de test d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte les étapes suivantes :- a) identification (20) de cas de test valides par un utilisateur, de manière interactive, en positionnant un point d'entrée et un point d'arrêt, respectivement, au début et à la fin d'une fonction du logiciel de fonctionnement en cours de test.- b) observation et enregistrement (22) des états de variables de ladite fonction par l'intermédiaire de la position du point d'arrêt et du point d'entrée,- c) génération automatique (26) d'un programme de test, en analysant dans un premier temps, les états des variables observés à l'étape a) et en générant ,dans un deuxième temps, un programme de test sous la forme d'un code source (13) ,- d) exécution automatique (30) dans un environnement d'exécution des tests du programme de test généré.

Description

Procédé de génération automatique de programmes de test d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre Domaine de l'invention La présente invention appartient au domaine de la sécurité de fonctionnement des systèmes lorsque le fonctionnement de ces systèmes dépend de l'exécution, dans un calculateur, de suites d'instructions logiques. En particulier, l'invention a pour objet un procédé de génération io automatique de programmes de test d'un logiciel de fonctionnement d'un système devant exécuter des suites d'instructions logiques, notamment d'un système ayant des exigences de sécurité élevées tel qu'un système électronique destiné à être embarqué à bord d'un aéronef. Le procédé permet, à un utilisateur, de pouvoir générer 15 automatiquement des programmes pour tester des suites d'instructions logiques de logiciels de fonctionnement de systèmes destinés à être embarqués à bord d'un aéronef. La présente invention trouve des applications particulièrement avantageuses, mais non exclusives, dans le domaine de l'aéronautique et, plus particulièrement, dans le domaine de la 20 réalisation de tests de logiciels de fonctionnement de systèmes destinés à être embarqués. Etat de la technique Pour des raisons de sécurité, les systèmes destinés à être embarqués à bord d'un aéronef sont soumis à des vérifications de bon fonctionnement 25 au cours desquels il doit être démontré que lesdits systèmes répondent à des exigences de certification, avant qu'un aéronef équipé de tels systèmes soit autorisé à voler et, plus encore, à entrer en service commercial. Actuellement, avant leur implantation, ces systèmes subissent de nombreux tests pour vérifier qu'ils répondent aux exigences d'intégrité et de 30 sécurité, entre autres, émises par les autorités de certification. Ces systèmes embarqués peuvent être, notamment, des calculateurs spécialisés destinés à réaliser des fonctions pouvant être importantes pour l'aéronef, par exemples des fonctions de pilotage. Ces systèmes seront appelés par la suite calculateurs.

Le plus souvent, dans les architectures des systèmes actuels, chaque calculateur est dédié à une application ou à plusieurs applications de même nature, par exemple des applications de commande de vol. Chaque calculateur comprend une partie matérielle et une partie logicielle. La partie matérielle comporte au moins une unité de traitement central (CPU: Central Processing Unit en anglais) et au moins une unité d'entrées/sorties par laquelle le calculateur est connecté à un réseau de calculateurs, à des périphériques externes, etc.... Une caractéristique essentielle des systèmes embarqués, souvent mis io en oeuvre dans le domaine aéronautique, est liée à une architecture, tant matérielle que logicielle, qui évite l'introduction, autant que possible, de tout moyen non nécessaire pour exécuter les fonctions dédiées aux dits systèmes. Ainsi, contrairement aux systèmes généralement rencontrés dans des 15 applications répandues, en aéronautique, le calculateur n'est pas pourvu d'un système d'exploitation complexe. De plus, le logiciel est réalisé dans un langage aussi proche que possible du langage compris par l'unité de traitement central et les seules entrées/sorties disponibles sont celles nécessaires au fonctionnement du système, par exemple des informations 20 provenant de capteurs ou d'autres éléments de l'aéronef ou des informations à destination d'actionneurs ou d'autres éléments. L'avantage de ce type d'architecture tient au fait que le fonctionnement d'un tel système est beaucoup mieux maîtrisé. Il n'est pas dépendant d'un système d'exploitation complexe dont certains aspects du 25 fonctionnement sont fonction de paramètres non maîtrisés et qui devrait, sinon, faire l'objet des mêmes démonstrations de sécurité que les logiciels d'application. Le système est plus simple et moins vulnérable car il ne comporte que les moyens strictement nécessaires à l'exécution des fonctions confiées audit système. 30 En contrepartie, le fonctionnement d'un tel système est beaucoup plus difficile à observer. Par exemple, le système ne dispose pas des interfaces homme/machine conventionnelles, comme les claviers et écrans, permettant de vérifier le déroulement correct des suites d'instructions et d'interagir sur ce déroulement, ce qui rend difficile les vérifications indispensables pendant 35 le développement, la vérification et la qualification des logiciels.

La partie logicielle du calculateur comprend un logiciel spécifique à l'application considérée et qui assure le fonctionnement du calculateur, dont les instructions logiques correspondent aux algorithmes qui déterminent le fonctionnement du système.

Pour obtenir la certification du système, préalable à sa mise en service et à celle de l'aéronef, une phase de validation du calculateur est effectuée. De façon connue, la phase de validation consiste, en général, à vérifier, à chaque étape du processus de réalisation du calculateur, que celui-ci est conforme aux spécifications qui ont été établies pour que ledit io calculateur réponde au fonctionnement attendu du système. Cette conformité aux spécifications est réalisée, en particulier pour les logiciels, par étapes successives depuis la vérification des composants les plus simples du logiciel jusqu'au logiciel complet intégrant tous les composants devant être intégrés dans le calculateur cible. 15 Dans une première étape de vérification, les éléments de logiciel les plus simples pouvant être testés sont soumis à des tests, dits tests unitaires. Au cours de ces tests, il est vérifié que les instructions logiques, c'est-à-dire le code, des dits éléments de logiciel ont été, pris individuellement, réalisés conformément aux exigences de conception. 20 Dans une deuxième étape, dite étape d'intégration, différents composants logiciels, ayant été soumis individuellement à une vérification isolée, sont intégrés pour constituer un ensemble dans lequel les composants logiciels interagissent. Ces différents composants logiciels sont soumis à des tests d'intégration destinés à vérifier que les composants 25 logiciels sont compatibles, en particulier au niveau des interfaces fonctionnelles entre lesdits composants. Dans une troisième étape, l'ensemble des composants logiciels est intégré dans le calculateur auquel ils sont destinés. Des essais de validation sont alors réalisés pour démontrer que le logiciel, formé par l'ensemble des 30 composants intégrés dans le calculateur, est conforme à la spécification, c'est-à-dire qu'il réalise les fonctions attendues, et que son fonctionnement est fiable et sûr. Pour garantir qu'un logiciel est sûr, et pour satisfaire aux exigences de certification, il est également nécessaire, au cours de cette phase de 35 validation, de démontrer que l'ensemble des tests auxquels le logiciel a été soumis permet de conclure, avec un niveau d'assurance adéquat, que le logiciel est conforme aux exigences de sûreté requises du système où il est incorporé. Les différents tests effectués, pendant la phase de validation, sur le logiciel, permettent de s'assurer qu'aucun dysfonctionnement du dit logiciel (qui pourrait avoir un impact sur le bon fonctionnement des calculateurs, et par suite sur l'aéronef et sa sécurité) ne peut se produire ou que, si un dysfonctionnement se produit, le logiciel est apte à le maîtriser. Toutefois, pendant la phase de validation, et surtout pour les io opérations d'investigation lorsque des anomalies sont constatées, il est souvent nécessaire de s'assurer que, non seulement, les paramètres d'entrée et de sortie du calculateur sur lequel est implanté le logiciel sont conformes aux attentes mais, également, que certains comportements internes du logiciel sont corrects. 15 Dans ce cas, en raison de l'architecture spécifique des calculateurs spécialisés pour les applications embarquées, il est généralement très difficile d'observer le fonctionnement du logiciel sans mettre en oeuvre des dispositifs et des méthodes particulières. Une première méthode connue consiste à mettre en place un 20 système de distribution de fichiers entre le calculateur en test avec le logiciel implanté et une plate-forme associée, en utilisant des émulateurs. On entend, par émulateur, un dispositif permettant de simuler, sur la plate-forme associée, le fonctionnement logique d'une unité de calcul, d'un processeur du calculateur. 25 Dans un tel mode de fonctionnement avec un émulateur, le processeur du calculateur est remplacé par une sonde qui assure l'interface avec la plate-forme associée portant l'émulation du processeur. Ainsi, il est possible de faire exécuter le logiciel à tester sur le calculateur, sauf pour la partie processeur et, par des fonctions propres de la 30 plate-forme associée, d'observer le fonctionnement ou certains dysfonctionnements internes du logiciel, par exemple, en réponse à des stimulations des entrées des unités d'entrée/sortie, en plus de l'observation des sorties des dites unités d'entrée/sortie. Une deuxième méthode consiste à simuler, sur une plate-forme hôte, 35 le fonctionnement du calculateur devant exécuter le programme à tester.

Dans ce cas, les logiciels sous test doivent accéder à des fichiers de la plate-forme hôte, soit pour lire les vecteurs de tests, soit pour enregistrer des résultats de tests. Comme le logiciel à tester ne comporte pas naturellement les fonctions pour de tels accès aux fichiers de la plate-forme hôte, il est nécessaire de modifier le logiciel à tester pour intégrer ces fonctions d'accès. Pour transférer les informations, on utilise généralement des instructions d'appels système qui sont émises par l'environnement de test simulé. Les instructions d'appels système peuvent être, par exemple, io l'ouverture d'un fichier, l'écriture d'un fichier ou encore la lecture d'un fichier. Les instructions d'appels système sont interceptées par le système d'exploitation de la plate-forme hôte qui les convertit en appels système de la plate-forme hôte. Durant la phase de validation du calculateur, et surtout pour les 15 opérations d'investigation lorsque des anomalies sont constatées, il peut être nécessaire de s'assurer que, non seulement, les paramètres d'entrée et de sortie du calculateur sur lequel est implanté le logiciel sont conformes aux attentes mais, également, que certains comportements internes du logiciel sont corrects. 20 Pour cela, un environnement d'exécution de tests des logiciels de fonctionnement des calculateurs génère plusieurs programmes de test or, les programmes de test représentent souvent un volume de codes instructions important, souvent plus important que le volume des codes instructions du logiciel que l'on veut tester. 25 Actuellement, le développement des programmes de test est réalisé cas de test par cas de test. On entend par cas de test le chemin fonctionnel à mettre en oeuvre pour atteindre un objectif de test. Autrement dit, un cas de test se définit par un jeu de test à mettre en oeuvre, un scénario de test à exécuter et les résultats attendus. Ainsi, à chaque cas de test du logiciel de 30 fonctionnement destiné à être chargé dans le calculateur, est associé un programme qui va simuler le cas de test. Ces programmes de test sont réalisés par des développeurs qui maîtrisent parfaitement les fonctions des logiciels à tester, leur contexte et leurs conditions d'exécution. Le développement des programmes de test passe par deux étapes 35 essentielles : une première étape qui concerne la conception de données de tests et une deuxième étape qui concerne l'écriture des chaînes d'instructions des programmes de test. Le développement de programmes de test fait l'objet d'un enchaînement répétitif de tâches manuelles, effectué par le développeur.

Cet enchaînement répétitif de tâches manuelles est une source importante d'introduction d'erreurs. Pour résoudre ce problème, des générateurs automatiques de tests ont été développés pour permettre de générer les données des cas de test. Avec une telle génération de données de cas de test, le développeur doit io formuler chaque objectif de test dans un langage formel puis traduire ces objectifs en langage de programmation. Chaque objectif ainsi modélisé constitue un cas de test. Cependant, cette formulation de chaque objectif de test n'est praticable que pour des objectifs simples sur des fonctions simples et une 15 automatisation de cette formulation est difficile à mettre en oeuvre à l'échelle industrielle. Exposé de l'invention La présente invention a pour but de remédier aux inconvénients des techniques exposées précédemment. Pour cela, l'invention propose un 20 procédé qui permet de générer automatiquement des programmes de test et de contrôler la validité des tests effectués. La mise en oeuvre du procédé selon l'invention permet de réduire le coût de la phase de test, en évitant le recours au développement manuel des programmes de test. L'invention permet ainsi de gagner en souplesse de 25 développement des programmes de test, puisque le développement du logiciel de fonctionnement est effectué de façon incrémentale en fonction des évolutions des tests effectués. En effet, les programmes de test sont développés parallèlement aux tests du logiciel de fonctionnement, ce qui implique que, chaque fois qu'il y a une évolution d'au moins un test, les 30 programmes de test évoluent en même temps que le logiciel de fonctionnement testé. L'invention permet aussi d'améliorer la fiabilité des programmes de test puisque la synthèse de ces programmes de test est faite automatiquement à partir de scripts déroulés et validés de façon interactive 35 par le développeur.

Plus précisément l'invention a pour objet un procédé pour générer des programmes de test d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte les étapes suivantes : - a) identification de cas de test valides par un utilisateur, de manière interactive, en positionnant un point d'entrée et un point d'arrêt, respectivement, au début et à la fin d'une fonction du logiciel de fonctionnement en cours de test. - b) observation et enregistrement des états de variables de ladite io fonction par l'intermédiaire de la position du point d'arrêt et du point d'entrée, - c) génération automatique d'un programme de test, en analysant dans un premier temps, les états des variables observés à l'étape a) et en générant ,dans un deuxième temps, un programme de test sous la forme d'un code source, 15 -d) exécution automatique dans un environnement d'exécution des tests d'un programme de test généré. L'invention peut comporter aussi une ou plusieurs des caractéristiques suivantes : - entre l'étape b) et l'étape c), est effectuée une étape de vérification 20 de la validité des cas de test permettant à l'utilisateur de décider si l'exécution de la fonction testée est valide par rapport aux états de variables observés. - la génération d'un programme de test est effectuée cas de test par cas de test. 25 - entre l'étape c) et l'étape d), est effectuée une compilation du code source pour traduire automatiquement ledit code source du programme de test en un programme équivalent en langage machine. - la compilation est suivie d'une édition de liens du programme de test fournissant un code binaire exécutable et utilisable dans l'environnement 30 d'exécution des tests sélectionné par l'utilisateur. - des résultats de tests sont générés sous une forme directement compatible avec le type d'environnement d'exécution des tests sélectionné.

L'invention a également pour objet dispositif simulant le fonctionnement d'un calculateur embarqué à bord d'un aéronef, caractérisé en ce qu'il met en oeuvre le procédé tel que défini précédemment. L'invention peut comporter aussi la caractéristique suivante : Le dispositif est simulé virtuellement sur une plate-forme hôte de test et de débogage. L'invention à également pour objet un programme de test chargeable sur une unité de commande comprenant des séquences d'instructions pour mettre en oeuvre le procédé tel que défini précédemment, lorsque le io programme est chargé sur l'unité et y est exécuté. Brève description des dessins L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention. 15 La figure 1 illustre le diagramme fonctionnel du procédé de l'invention. La figure 2 est une représentation schématique d'une unité de commande de l'environnement d'exécution des tests, permettant la génération de programmes de test d'un logiciel de fonctionnement. Description détaillée de modes de réalisation de l'invention 20 La présente invention propose un procédé permettant de générer automatiquement des programmes de test tout au long du développement du logiciel de fonctionnement. Ce procédé permet de prendre en compte chaque modification apportée audit logiciel tout au long de son développement. 25 Le procédé de l'invention permet également, par l'intermédiaire d'une succession d'étapes, de contrôler la validité de chaque test effectué sur le logiciel de fonctionnement au fur et à mesure de son développement. La figure 1 représente un diagramme fonctionnel du procédé de l'invention. Ce diagramme fonctionnel correspond à un mode de réalisation 30 de l'invention. Ce diagramme fonctionnel comporte une étape 20 dans laquelle une identification des cas de test est effectuée par un utilisateur de manière interactive. Cet utilisateur dispose des fonctionnalités d'un débogueur lui permettant, notamment, de rechercher les erreurs éventuelles dans des chaînes d'instructions. Ce débogueur permet aussi de contrôler 35 l'exécution des tests en positionnant un point d'entrée et un point d'arrêt, respectivement, au début et à la fin de la fonction du logiciel de fonctionnement testée. Le contrôle de l'exécution des tests comporte, notamment, une observation de l'état des variables sélectionnées par l'utilisateur, appelées variables significatives.

Une vérification de la validité du test est effectuée à l'étape 21 permettant de décider si oui ou non l'exécution de la fonction est valide par rapport aux états des variables observés. Dans le cas où le test est valide, une étape 22 offre à l'utilisateur une interface de validation pour enregistrer les tests valides en conservant l'ensemble des états de variables observés. io Dans le cas où le test n'est pas valide, le procédé est réitéré à partir de l'étape 20. Lorsque l'étape 22 d'enregistrement des tests valides est appliquée, une vérification de nouveaux cas de test est effectuée à l'étape 23 sous l'action et la décision de l'utilisateur. Si un nouveau cas de tests est détecté, 15 alors le procédé est réitéré à partir de l'étape 20. Si aucun nouveau cas n'est détecté, une étape 26 de génération d'un programme de test est appliquée. Cette étape 26 est précédée par deux étapes intermédiaires 24 et 25. L'étape 24 a pour but de détecter si des paramètres de l'environnement d'exécution des tests ont été indiqués par l'utilisateur. Ces paramètres 20 permettent de sélectionner le type d'environnement d'exécution de tests pour lequel les programmes de test doivent être générés. Si des paramètres ont été détectés, l'étape 25 consiste à prendre ces paramètres en compte pour la génération du programme de test. L'étape 26 de génération du programme de test est effectuée de 25 manière automatique par un générateur de progammes. Ce générateur de programmes analyse, dans un premier temps, les états des variables contrôlés qui ont été enregistrés après l'étape 20 d'identification des cas de test valides et, dans un deuxième temps, génère un code source du programme de test (étape 27). 30 Cette génération du code source est effectuée cas de test par cas de test. Le code source est présenté directement dans un langage de programmation habituel, ce qui facilite sa compréhension par la plupart des développeurs de logiciels. A l'étape 28, une compilation du code source est effectuée permettant 35 de traduire automatiquement le code source du programme de test en un programme équivalent en langage machine. Cette compilation est suivie d'une édition des liens du programme de test fournissant à l'étape 29 un code binaire exécutable et utilisable dans l'environnement d'exécution des tests sélectionné.

A l'étape 30, le code binaire du programme de test est exécuté automatiquement dans l'environnement d'exécution des tests. A l'étape 31, les résultats de tests sont générés sous une forme directement compatible avec le type d'environnement d'exécution des tests sélectionné dans l'étape 26 de génération de programme. io Le procédé présente l'avantage de pouvoir s'adapter à tout type d'environnement d'exécution de tests de logiciels de fonctionnement. Il peut donc s'adapter à tout type d'environnement virtuel ou réel. Avec le procédé de l'invention, les programmes de test générés sont directement valides et exempts d'erreurs. En effet, durant la phase de 15 validation des programmes de test, la non validation d'un desdits programmes correspond à la découverte d'une erreur, ce qui entraîne implicitement une correction de la fonction testée du logiciel de fonctionnement. La figure 2 est une représentation schématique de l'unité de 20 commande 1 de l'environnement d'exécution des tests, permettant la génération de programmes de test du logiciel de fonctionnement destiné à être chargé dans un système embarqué (non représenté). La figure 2 montre un exemple d'unité de commande 1 d'un environnement d'exécution des tests. L'environnement d'exécution des tests peut être, selon des variantes 25 de réalisation, soit simulé virtuellement sur une plateforme hôte, telle qu'une station de travail, soit basé sur un équipement matériel de type émulateur. On entend par environnement d'exécution des tests un environnement permettant de vérifier, corriger, effectuer un rodage fonctionnel et tester un logiciel de fonctionnement d'un système embarqué. L'unité de commande 1 30 de l'environnement de test comporte, de manière non exhaustive, un processeur 2, une mémoire programme 3, une mémoire de données 4, et une interface d'entrée/sortie 5. Le processeur 2, la mémoire programme 3, la mémoire de données 4, et l'interface entrée/sortie 5 sont connectés les uns aux autres par un bus de communication 6 bidirectionnel.

Le processeur 2 est commandé par des codes instructions enregistrés dans une mémoire programme 3 de l'unité de commande 1. La mémoire programme 3 comporte, dans une zone 7, des instructions pour effectuer une identification des cas de tests valides. Cette identification permet l'interaction de l'utilisateur par l'intermédiaire d'une interface, à divers fonctionnalités que l'on retrouve dans un débogueur classique. Parmi ces fonctionnalités existe notamment la possibilité de positionner un point de contrôle d'exécution à l'entrée de la fonction du logiciel de fonctionnement qui est sous test. Une autre fonctionnalité permet io de positionner un point d'arrêt à la sortie de la fonction. Cette interaction de l'utilisateur permet audit utilisateur de contrôler les états de variables afin de déterminer si l'exécution de la fonction s'est déroulée correctement. La mémoire programme 3 comporte, dans une zone 8, des instructions pour effectuer une validation. Cette validation consiste à 15 enregistrer de manière automatique l'ensemble des états de variables contrôlés. Ces états constituent un enregistrement 12 des cas de tests valides. Cette validation permet également d'éditer l'ensemble des états contrôlés. Ces états contrôlés deviennent la valeur de référence des cas de tests validés.

20 La mémoire programme 3 comporte, dans une zone 9, des instructions pour effectuer une génération des programmes de test. Cette génération de programmes de tests découle d'une analyse des états des variables de l'enregistrement 12. Cette génération de programmes de test se présente sous la forme d'un code source 13. Elle se présente cas de test par 25 cas de test. La mémoire programme 3 comporte, dans une zone 10, des instructions pour effectuer une compilation du code source 13 afin de le traduire dans le langage machine. Suite à cette compilation, une édition des liens est effectuée pour transformer le code source 13 (qui se trouve en 30 langage machine) en un code binaire 14 exécutable. La mémoire programme 3 comporte, dans une zone 11, des instructions pour effectuer une exécution du programme de test pour générer en sortie des résultats de tests 15.

Claims

REVENDICATIONS

1 ù Procédé pour générer des programmes de test d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en ce qu'il comporte les étapes suivantes : - a) identification (20) de cas de test valides par un utilisateur, de manière interactive, en positionnant un point d'entrée et un point d'arrêt, respectivement, au début et à la fin d'une fonction du logiciel de fonctionnement en cours de test. io - b) observation et enregistrement (22) des états de variables de ladite fonction par l'intermédiaire de la position du point d'arrêt et du point d'entrée, - c) génération automatique (26) d'un programme de test, en analysant dans un premier temps, les états des variables observés à l'étape a) et en générant ,dans un deuxième temps, un programme de test sous la 15 forme d'un code source(13), - d) exécution automatique (30) dans un environnement d'exécution des tests du programme de test généré.

2 ù Procédé selon la revendication 1 caractérisé en ce qu'entre l'étape b) et l'étape c), est effectuée une étape de vérification de la validité des cas 20 de test permettant à l'utilisateur de décider si l'exécution de la fonction testée est valide par rapport aux états de variables observés.

3 ù Procédé selon l'une quelconque des revendications 1 à 2 caractérisé en ce que la génération du programme de test est effectuée cas de test par cas de test. 25 4 ù Procédé selon l'une quelconque des revendications 1 à 3 caractérisé en ce qu'entre l'étape c) et l'étape d), est effectuée une compilation du code source pour traduire automatiquement ledit code source du programme de test en un programme équivalent en langage machine. 5 ù Procédé selon la revendication 4 caractérisé en ce que la 30 compilation est suivie d'une édition de liens du programme de test fournissant un code binaire exécutable et utilisable dans l'environnement d'exécution des tests sélectionné par l'utilisateur. 6 ù Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que des résultats de tests sont générés sous une formedirectement compatible avec le type d'environnement d'exécution des tests sélectionné. 7 ù Dispositif simulant le fonctionnement d'un calculateur embarqué à bord d'un aéronef, caractérisé en ce qu'il met en oeuvre le procédé selon 5 l'une quelconque des revendications 1 à 6. 8 ù Dispositif selon la revendication 7 caractérisé en ce qu'il est simulé virtuellement sur une plate-forme hôte de test et de débogage. 9 ù Programme de test chargeable sur une unité de commande 1 comprenant des séquences d'instructions pour mettre en oeuvre le procédé io selon l'une des revendications 1 à 6, lorsque le programme est chargé sur l'unité et y est exécuté.