FR2925966A1

FR2925966A1 - Procede de realisation d'un outil universel perenne de developpement de tests d'equipements et outil de mise en oeuvre

Info

Publication number: FR2925966A1
Application number: FR0709176A
Authority: FR
Inventors: Jean Pierre Melis
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2007-12-28
Filing date: 2007-12-28
Publication date: 2009-07-03
Anticipated expiration: 2027-12-28
Also published as: EP2225641A1; WO2009083574A1; US20100287415A1; FR2925966B1

Abstract

La présente invention a pour objet un outil universel pérenne de développement de tests d'équipements, cet outil et sa mise en oeuvre étant le moins onéreux possible. Cet outil comporte en particulier : une fonction de spécification d'exigences (2), une fonction de conception de tests (5), une bibliothèque de commandes génériques (11), des moteurs de génération de documents (3, 6, 9) et des bibliothèques d'aide à la conversion de programmes de test haut niveau en langage bas niveau (12, 13).

Description

PROCEDE DE REALISATION D'UN OUTIL UNIVERSEL PERENNE DE DEVELOPPEMENT DE TESTS D'EQUIPEMENTS ET OUTIL DE MISE EN OEUVRE La présente invention se rapporte à un procédé de réalisation d'un outil universel pérenne de développement de tests d'équipements ainsi qu'à un outil de mise en oeuvre de ce procédé. Le développement d'un banc de test, s'apparente au développement d'un système opérationnel avec ses contraintes, ses problématiques d'obsolescences, ses 10 exigences de traçabilité et de ré-utilisation. Aujourd'hui, le développement d'un programme de test se fait sans exigence de lien entre la spécification de test et le code Cette absence de lien est à l'origine de surcoûts que le client final ne peut plus supporter aujourd'hui: 15 - lors du développement des programmes de test (lourdeur des itérations successives spécification / documentation / code), - lors du maintien en condition opérationnel de ces programmes (correction logicielle, ré-utilisation, capitalisation amont / aval) et plus globalement lors du maintien en condition opérationnelle du banc de test (obsolescence 20 matérielle provoquant des évolutions de spécifications et donc de la chaîne complète). - d'autre part, tout traitement d'obsolescence (tant pour le logiciel que pour le matériel) associé à un manque de capitalisation, génère des coûts non justifiables aujourd'hui. 25 La présente invention a pour objet un procédé de réalisation d'un banc de test permettant le développement d'un programme de test au coût le plus faible possible. Elle a également pour objet un banc de test réalisé selon ce procédé. Le procédé conforme à l'invention est un procédé de réalisation d'un outil 30 universel pérenne de développement de programmes de tests d'équipements à l'aide d'un banc de test, et il est caractérisé en ce qu'il comporte les étapes suivantes, mises en oeuvre avec un outil de développement de tests comportant un calculateur, des moyens de saisie d'informations et de visualisation et au moins une mémoire : - un opérateur conçoit les différentes tâches et sous-tâches du programme de test sur un banc de test que l'outil mémorise, - il saisit les spécifications des exigences du programme de test, - il choisit les exigences du scénario à suivre en fonction des résultats du test, - lorsque l'opérateur a saisi les informations relatives aux tests, l'outil génère automatiquement la documentation relative aux tests ainsi conçus, - puis un opérateur de développement décrit le mode opératoire pour chacun des tests dont les exigences ont été formulées en utilisant les commandes fournies par une bibliothèque de commandes génériques de l'outil, - l'opérateur procède à la conception de chaque test élémentaire, - l'outil génère automatiquement un fichier exportable traduit en un langage approprié au banc de test utilisé lors des tests.

La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel : - la figure 1 est un bloc-diagramme d'un exemple de réalisation d'un outil de développement de tests mettant en oeuvre le procédé de l'invention, - les figures 2 à 7 sont des exemples de vues d'écran prises à différents stades de mise en oeuvre des étapes de conception du procédé conforme à la présente invention, - la figure 8 est une vue d'écran d'un exemple de documents correspondant à la spécification des exigences de test, - la figure 9 est une vue d'écran d'un exemple d'organigramme de test tel que pouvant être produit selon le procédé de l'invention, les figures 10 à 12 sont des exemples de vues d'écran prises à différents stades de mise en oeuvre des étapes de conception de tests selon le procédé conforme à la présente invention, et - la figure 13 est un diagramme servant à expliquer la génération, selon le procédé de l'invention, d'un code de test utilisable par un banc de test.

Le procédé de l'invention est essentiellement caractérisé par la mise en place d'un outil assurant un lien réel entre la spécification de test et le code, et il permet d'optimiser les phases de spécification, conception et codage d'un programme de test. On a schématisé sur le bloc-diagramme de la figure 1 un exemple de réalisation d'un outil 1 universel et pérenne de développement de tests d'équipements mettant en oeuvre le procédé de l'invention. Cet outil 1 comporte une fonction 2 de saisie de données. Cette fonction sert à saisir les spécifications des exigences relatives aux tests à réaliser, et en particulier la définition de l'arborescence de ces tests en modes GO et NO GO , c'est-à- dire en mode binaire BON ou MAUVAIS et des tolérances applicables aux résultats de ces tests. Cette fonction 2 est reliée à un moteur 3 de génération d'exigences produisant de la documentation relative à la spécification des exigences des tests logiciels, spécification répondant à une mise en forme particulière (4), et elle est suivie d'une fonction 5 de conception de tests. La fonction 5 consiste en particulier à définir des conditions d'entrée permettant de répondre aux exigences relatives aux tests à effectuer. La mise en oeuvre des fonctions 2 et 5 est expliquée en détail ci-dessous en référence aux figures 2 à 7. La fonction 5 est reliée à un moteur 6 de génération de tests de type connu en soi, produisant de la documentation 7 exposant les procédures de test conçues à l'aide de la fonction 5, et éventuellement de la documentation 8 exposant les procédés de validation des tests produits et la documentation prévue pour enregistrer les résultats de cette validation. D'autre part, la fonction 5 est reliée à un moteur 9 produisant un organigramme de test 10, et elle est reliée à une bibliothèque 11 de commandes 30 génériques pré-existante. Cette bibliothèque 11 est reliée à son tour à des bibliothèques de langages spécifiques. Dans le cas présent, on utilise deux bibliothèques de langages spécifiques, par exemple la bibliothèque 12 de langage Labview produisant des codes 12A de test en langage Labview et la bibliothèque 13 de langage ATEasy produisant des codes 13A de test en langage ATEasy , mais il est bien entendu que l'outil 1 peut comporter une seule bibliothèque de codes de langages de test ou bien une ou plusieurs autres bibliothèques produisant des codes de programmes de test appropriés aux bancs de test utilisés avec l'outil 1 de l'invention dans le présent ou dans le futur. En effet, les tests doivent pouvoir être menés sur des matériels pendant toute leur durée de vie, qui peut dépasser 20 ans, avec des bancs de test dont les programmes de test sont généralement renouvelés ou modifiés au bout d'un laps de temps nettement inférieur à la durée de vie des matériels à tester. Grâce à l'invention, on peut garder (dans la mémoire du calculateur de l'outil 1 et/ou sur des supports de mémoire amovibles) une trace des protocoles de test et de la façon dont ils ont été conçus au moins aussi longtemps que les matériels à tester sont utilisés. Du fait de la modularité de l'outil 1 (bibliothèques 12 et 13 indépendantes des autres fonctions de l'outil 1 ), il suffit de changer la bibliothèque de codes (bibliothèque telle que 12 ou 13) pour l'adapter aussitôt à un nouveau langage de test. Les figures 2 à 7, décrites ci-dessous, se rapportent à des vues d'écran d'un terminal de visualisation d'un calculateur, tel qu'un micro-ordinateur, utilisé par un opérateur (qui est, dans cette première phase de spécification des exigences, le spécialiste du matériel à tester) pour effectuer les spécifications d'exigences du programme de test et incorporant l'outil 1. La figure 2 représente une vue d'écran 14 s'ouvrant au lancement du processus PSE de spécification d'exigences de l'outil 1 (fonction 2). Cet écran affiche, dans le présent exemple, quatre fenêtres différentes référencées 15 à 18, la fenêtre 17 comportant trois sous-fenêtres 19 à 21. Ces fenêtres sont respectivement les suivantes : - Fenêtre 15 : fenêtre principale destinée à afficher les différentes tâches et sous-tâches du programme de test, utilisé ultérieurement sur un banc de test, 30 au fur et à mesure de leur conception. Au lancement du programme PSE, cette fenêtre ne contient qu'une ligne initiale PROGRAMME SANS TITRE , qui sera complétée par un premier opérateur qui est ici l'opérateur de spécification des exigences du processus PSE au cours de la mise en oeuvre de ce processus. - Fenêtre 16 : initialement intitulée PROGRAMME SANS TITRE , comme la seule ligne de la fenêtre 15, et comportant, dans le présent exemple, quatre onglets : Description (activé ici), Propriétés , Saut en fin de test 1/2 et Saut en fin de test 2/2 . Dans cette fenêtre 16, figure une légende Vous pouvez mettre ici une description , en vue de mettre une description du programme . - Fenêtre 17 : intitulée Liste des commandes . Elle comporte initialement, dans la sous-fenêtre 19, deux lignes : PROGRAMME et SYSTEME . Ses deux autres sous-fenêtres 20 ( Paramètre ) et 21 ( Valeur ) sont initialement vides. En outre, la fenêtre 17 comporte trois boutons 22 à 24. Ces trois boutons sont respectivement intitulés Créer Macro , Supprimer Macro et Ajouter . - Fenêtre 18 : en fait, elle se présente comme un onglet, intitulé Sélectionnez un test ... . Initialement, elle n'est pas activée, du fait qu'il n'existe encore aucun test.

La vue 14 comporte également un ensemble 25 de boutons. Cet ensemble de boutons comporte des boutons portant des symboles classiques tels que Ouvrir un dossier , Enregistrer , Couper , etc, ainsi que certains boutons qui sont spécifiques à l'invention, comme celui utilisé dans l'exemple illustré en figure 13. La vue 26 de la figure 3 montre le début de la phase de saisie des tâches et sous-tâches du processus PSE . A ce stade, des informations 27 ont été saisies seulement dans la fenêtre 15. Le programme de test s'appelle maintenant TEST DE MON EQUIPEMENT . Ce programme comporte plusieurs tâches, appelées ici FONCTION ALIMENTATION , FONCTION PRE-AMPLI , etc. Ces tâches se composent de sous-tâches. Par exemple, la fonction alimentation comporte des sous-tâches telles que TEST SECTEUR , TEST TENSION , etc.

Dans cette vue 26, on a cliqué, à titre d'exemple, sur la sous-fonction DEPANNAGE ALIMENTATION , qui s'affiche dans le titre de la fenêtre 16. La vue 28 de la figure 4 montre les détails relatifs à une sous-tâche. Dans cet exemple, cette sous-tâche est TEST -24V qui a été activée en cliquant sur la ligne correspondante de la fenêtre 15. Le nom de cette sous-tâche s'affiche alors en tant que titre des fenêtres 16 et 18.Dans la sous-fenêtre 19, s'affichent différentes commandes pouvant être intégrées au TEST -24V . La fenêtre 16 affiche la description, rédigée par l'opérateur, du test activé en question. La première étape de saisie d'informations, illustrée à la figure 5 par la vue 29, consiste à faire saisir par l'opérateur , pour chaque test élémentaire sélectionné, les exigences associées, telles que type de mesure, unités de mesure, tolérances applicables aux valeurs mesurées pour les reconnaître comme bonnes, etc. Pour cela, l'opérateur active l'onglet Propriétés de la fenêtre 16 se rapportant, dans le présent exemple, au test TEST -24V . Dans cet exemple, les différentes propriétés, qui sont sélectionnées dans des sous-fenêtres, sont : Min/max pour le type, J2-21 pour le nom du point de mesure de la tension, V (pour Volts ) pour l'unité de mesure, -25 pour la valeur minimale tolérable de la tension mesurée pour la reconnaître comme bonne, et -23 pour la valeur maximale tolérable. Le bandeau représenté tout en bas de la vue de cette figure 5 (de même que sur les figures 3 et 4 et les figures 6, 7, 10 et 11) fournit des indications complémentaires telles que le niveau du test dans l'arborescence du programme de test, l'index associé à ce test, l'identité du test et l'heure. Ensuite, comme représenté sur la vue 29A en figure 6, pour chaque test élémentaire sélectionné (il s'agit toujours ici du test -24V), l'opérateur choisit les exigences du scénario à suivre en fonction des résultats du test. Dans le cas présent, ces résultats sont soit réussi ( PASS ) soit non réussi ( FAIL ). Les intitulés de ces types de résultats figurent dans l'onglet activé Saut en fin de test 1/2 de la fenêtre 16. Pour chacun de ces types de résultats, il est prévu deux sous-fenêtres On saute vers et en exécutant avant le saut . Ainsi, l'opérateur peut facilement indiquer la suite du scénario de test quel que soit le résultat de ce test élémentaire, et éventuellement indiquer une procédure particulière (par exemple, comme représenté dans la deuxième sous-fenêtre du résultat FAIL , la procédure MSGOP ). En variante, comme représenté sur la vue 30 de la figure 7, dans la fenêtre de l'onglet Saut en fin de test 2/2 , au lieu d'indiquer la suite du scénario de ce programme automatique, l'opérateur de saisie peut faire apparaître un message à destination de l'opérateur effectuant le test. Dans l'exemple de la figure 7, si le test échoue, ce message est DEFAUT SUR LE -24V. COUPER LE DISJONCTEUR. PROCEDER AU DEMONTAGE DU BLOC ALIM (PS 1) . Une fois que l'ensemble des tâches et sous-tâches a été ainsi renseigné et les scénarii de test et de dépannage créés, l'outil 1 est en mesure de générer automatiquement un document (document imprimé, par exemple tel que le document 4 de la figure 1, ou bien un document visualisé sur un écran, tel que celui de la figure 8) correspondant à la spécification des exigences de test. Ce document est par exemple du type de celui représenté partiellement en figure 8, et éventuellement tout autre type de document utilisant les informations saisies par le premier opérateur. Ces autres documents ainsi générés sont, par exemple, des documents décrivant diverses phases de la conception des exigences, des procédures de validation, etc. La partie de gauche de la vue de la figure 8 montre quelques-unes des premières pages de la spécification des exigences de test. La partie de droite de la vue 31 de la figure 8 montre le détail d'une page sélectionnée dans la partie de gauche, et dans le cas présent la page 8 a été sélectionnée. Sur la figure 9, on a représenté un exemple d'organigramme de scénario de test 32 , tel que celui du document 10 de la figure 1. Une fois que les exigences des tests ont été formulées par le premier opérateur, un opérateur de développement (qui peut être le premier opérateur ou bien un programmeur) décrit le mode opératoire pour chacun des tests dont les exigences ont été formulées par le premier opérateur. A cet effet, il utilise les commandes fournies par la bibliothèque de l'outil, qui est la bibliothèque 11 de commandes génériques illustrée en figure 1. On a représenté dans la sous-fenêtre 19 de la vue 33 de la figure 10 quelques-unes des commandes génériques, qui sont disponibles pour tous les tests, et dans le cas présent, on a représenté celles relatives au test TEST + 24V et référencées 34 sur cette figure. A partir de ces commandes, l'opérateur procède à la conception de chaque test élémentaire. Ainsi, pour le test TEST + 24V en question, l'opérateur choisit dans la sous-fenêtre 19(vue 35 de la figure 11) la commande (mesurer) une tension continue . Les sous-fenêtres 20 et 21 indiquent pour cette commande les paramètres correspondants. Pour l'exemple représenté, il s'agit du paramètre d'affichage du résultat de la mesure de la tension (+ 24V). Ce paramètre est simplement dénommé RESULTAT et sa valeur est la variable résultat qui représente le résultat de la mesure effectuée en activant la sous-tâche de mesure de tension continue (apparaissant dans la fenêtre 19). La fenêtre 16 affiche le commentaire correspondant Test de la présence du +24V au point J2-19 du bloc alimentation dans l'onglet Description . L'onglet TEST +24V de la fenêtre 18 affiche, en langage dit de haut niveau , les différentes lignes du programme correspondant , dont les intitulés des routines visibles sur le dessin sont successivement : préparation opérateur , Mise en route du secteur , branchement automatique sur J2-19 et Mesure de la tension +24V . Comme représenté sur la vue 36 de la figure 12, lorsque des opérations doivent être répétées, l'opérateur peut créer des routines pouvant être appelées à tout moment. Pour l'exemple représenté, une routine (macro-commande) dénommée COUPURE SECTEUR , qui peut être appelée plusieurs fois au cours de la conception du programme, a été créée à cet effet et est accessible à partir d'un onglet supplémentaire de la fenêtre 18 dénomme COUPURE_ SECTEUR . En cliquant sur cet onglet, l'opérateur fait apparaître cette routine. Cette routine est insérable dans le programme : - soit grâce à une commande exécuter une procédure de la fenêtre 16 (et en la nommant dans ses paramètres), - soit en sélectionnant cette procédure dans la fenêtre 16. Lorsque l'opérateur a terminé l'ensemble de la conception des tests, l'outil 1 30 génère automatiquement un fichier exportable traduit en un langage approprié au banc de test utilisé lors des tests, par exemple l'un des deux langages disponibles de l'outil de la figure 1, à savoir ATEasy et Labview . Sur le diagramme de la figure 13 on a schématiquement illustré les dernières étapes de la conception des programmes de test. En cliquant sur le bouton 37 (vue d'écran 38) qui correspond à la conversion de programmes, on ouvre une fenêtre 39 dénommée Convertir et dans laquelle sont affichés les différents types de conversion disponibles dans l'outil 1. Dans le cas présent, on sélectionne la ligne Fichier de sauvegarde [*.ACP] <--> Programme de test ATEasy [*.PGT] , ce qui déclenche la conversion du programme de test ainsi conçu en langage de haut niveau vers un langage bas niveau , et on obtient le code (40) du programme de test en langage ATEasy qui peut ensuite être exploité par tout appareil de test approprié, par exemple un PC 41.

En conclusion, l'outil de l'invention permet, à partir des données saisies par 15 l'utilisateur, de générer automatiquement de la documentation et du code (avec choix du langage utilisé). Il permet grâce à des moteurs de génération automatique (comme illustré en figures 2 à 5), de gagner sur les temps de développement et donc sur les coûts. Les liens et la traçabilité (obtenue grâce à mémorisation de toutes les 20 exigences de test et des différents paramètres et procédures de test dans l'outil 1), déployés à travers les différentes phases de développement, permettent d'autre part, d'assurer la qualité du produit de sortie. L'architecture de l'outil, associée à l'architecture du processus de développement, permet une ré-utilisation maximum qui ne devient pas obsolète 25 dans le temps. Selon un exemple de réalisation, l'outil a été développé, dans un premier temps à l'aide d"Excel' puis en langage `cSharp'. Il permet à tout opérateur de spécification du programme de test : de spécifier aisément et structurellement ses besoins de test (mise à 30 disposition d'une méthode de spécification des test, voir figures 2 à 7), de produire et de mettre à jour automatiquement, les documents de spécifications ou de conception (mise à disposition d'un moteur de génération automatique de documents, voir figures 8 et 9), - de générer et de mettre à jour automatiquement, le logiciel de test dans un langage quelconque (mise à disposition d'une bibliothèque de commandes et d'un moteur de génération automatique de code, voir figures 10 à 13), - de pouvoir transmettre, tout au long des phases de développement du système opérationnel, les informations essentielles de soutien de ce système et ainsi accroître fortement le taux de ré-utilisation. Les informations saisies dans l'outil sont universelles et donc pérennes, tout au long des phases de vie du moyen de soutien, - de pouvoir traiter à moindre coût les obsolescences logicielles et matérielles survenues sur des bancs de test existants.

Cet exemple de réalisation a permis de constater : un gain en temps de développement sur les différentes phases (spécification, conception, codage, documentation, évolutions, traçabilité,... ), - une réduction des coûts de développement (réduction de 15 à 20%), - que l'utilisation de l'outil, a grandement aidé à la certification CMMI2, - la lisibilité des programmes obtenus : informations claires et compréhensibles (en langage haut niveau , comme précisé ci-dessus), garantissant ainsi leur pérennité.25

Claims

REVENDICATIONS

1. Procédé de réalisation d'un outil universel pérenne de développement de programmes de tests d'équipements à l'aide d'un banc de test, caractérisé en ce qu'il comporte les étapes suivantes, mises en oeuvre avec un outil de développement de tests comportant un calculateur, des moyens de saisie d'informations et de visualisation et au moins une mémoire : un opérateur conçoit les différentes tâches et sous-tâches du programme de test sur un banc de test que l'outil mémorise, il saisit à l'aide desdits moyens de saisie les spécifications des exigences du programme de test, il choisit les exigences du scénario à suivre en fonction des résultats du test, -lorsque l'opérateur a saisi les informations relatives aux tests, l'outil génère automatiquement la documentation relative aux tests ainsi conçus, -puis un opérateur de développement décrit le mode opératoire pour chacun des tests dont les exigences ont été formulées en utilisant les commandes fournies par une bibliothèque de commandes génériques de l'outil, l'opérateur procède à la conception de chaque test élémentaire, et l'outil génère automatiquement un fichier exportable traduit en un langage approprié au banc de test utilisé lors des tests.

2. Procédé selon la revendication 1, caractérisé en ce que la documentation produite par l'outil comporte au moins l'un des éléments suivants : documentation relative à la spécification des exigences des tests logiciels, spécification répondant à une mise en forme particulière (4), documentation (7) exposant les procédures de test conçues à l'aide de l'outil, documentation (8) exposant l'organisation de la validation des tests et documentation permettant l'enregistrement des résultats de cette validation.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que pour chaque test élémentaire sélectionné, l'opérateur choisit les exigences du scénario à suivre en fonction des résultats du test.

4. Procédé selon la revendication 3, caractérisé en ce que les exigences du scénario à suivre comportent au moins un saut vers une autre tâche. . Procédé selon l'une des revendications précédentes, caractérisé en ce que l'opérateur de développement fait appel à des routines mémorisées dans l'outil lorsque des opérations doivent être répétées. 6. Outil universel pérenne de développement de tests d'équipements pour la mise en oeuvre du procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il comporte une fonction de spécification d'exigences (2), une fonction de conception de tests (5), une bibliothèque de commandes génériques (11), des moteurs de génération de documents (3, 6, 9) et des bibliothèques d'aide à la conversion de programmes de test haut niveau en langage bas niveau (12, 13).