FR 2795538 A1 20001229 FR 9907961 A 19990622 PROCEDE UNIVERSEL DE TEST DE LOGICIELS La présente invention se rapporte aux procédés universels de test de logiciels. Le temps passé pour tester de manière exhaustive des logiciels représente un des coûts les plus élevés parmi toutes les tâches de développement et de maintenance de ces logiciels, en particulier des logiciels dits safety critical (assurant des fonctions critiques pour la sécurité des systèmes pilotés ou surveillés par ces logiciels). II est donc nécessaire d'automatiser ces tests. Ainsi, par exemple, les logiciels temps réel embarqués sont souvent testés sur le calculateur cible qui, dans de nombreuses applications telles que des automatismes ou des contrôles commandes (pilotage et supervision d'appareillage), a une taille mémoire très réduite et est dépourvu de périphériques d'entrée/sortie tels que des claviers standard ou des écrans. De plus, ces logiciels sont souvent inscrits dans des mémoires programmables dont le chargement dans le calculateur doit être précédé d'une opération d'inscription dans une mémoire de type EPROM ou EEPROM.... II en résulte que le test d'un logiciel embarqué est très long, en particulier lorsque les résultats du test doivent être analysés sous forme symbolique et non binaire. Dans ce dernier cas, le test requiert des outils de test complémentaires (chaîne de mise au point croisée, émulateur, analyseur de résultats de test...) dont la mise en ceuvre est longue, et ralentit donc d'autant la durée des tests. En outre, les logiciels safety critical doivent subir des tests assurant 100 % de leur couverture structurelle et fonctionnelle, ce qui accroît encore le coût des tests, dont le nombre peut être très important. La présente invention a pour objet un procédé universel de test de logiciels, qui puisse tester automatiquement toutes sortes de logiciels, à diverses étapes d'intégration, avec une durée de test nettement plus courte qu'avec les outils connus, en garantissant que le comportement des logiciels testés sera semblable à celui obtenu sur le calculateur cible, qui soit aussi un outil puissant d'analyse des résultats de test et qui puisse fournir un document collationnant toutes les données nécessaires relatives aux tests (données d'entrée, de sortie, de référence, résultats des tests...) Le procédé conforme à l'invention, utilisant une machine de test, consiste à préparer les données relatives aux tests en les décrivant de façon mathématique formelle, à introduire dans un tableau de tableur des valeurs de ces données et leurs descriptions correspondantes, dans le langage de programmation qui code le logiciel à tester, à vérifier la cohérence entre les caractéristiques des données d'entrée et le type logiciel résultant en respectant la précision requise des données d'entrée, à traduire les données issues du tableur dans un format de fichier compatible avec celui de la machine de test, à effectuer les tests de façon classique avec la machine de test, et à exploiter les résultats des tests. De façon avantageuse, les résultats des tests sont exploités à l'aide du tableur et/ou d'un programme associé, en retraduisant les données de sortie de la machine de test en données dans un format compatible avec celui du tableur ou du programme associé, en respectant la précision requise des données. Lorsque les données d'entrée sont relatives à des dispositifs physiques, ces données, ainsi que celles résultant des tests sont présentées dans le tableau conformément à la représentaiton des données en physique théorique. La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de mise en oeuvre, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel - la figure 1 est un diagramme montrant les principales étapes de ce mode de mise en ceuvre ; et - la figure 2 est un exemple de classement d'informations dans un tableau, conformément à l'invention. L'invention est décrite ci-dessous en référence au test d'un logiciel de pilotage et de supervision d'un dispositif physique tel qu'un automatisme, mais il est bien entendu qu'elle n'est pas limitée à cette seule application, et qu'elle peut être mise en oeuvre pour les tests de logiciels très divers, et qu'elle est particulièrement avantageuse pour ceux devant subir des tests exhaustifs. Du fait que le mode de mise en oeuvre de l'invention décrit ci- dessous se réfère à un logiciel de pilotage et de supervision d'un automatisme, les grandeurs d'entrée (et de sortie) de ce logiciel sont des grandeurs physiques et doivent donc être décrites formellement comme telles (étape 1 du dessin) en tenant compte des caractéristiques des organes ou appareils qui les fournissent et qui les reçoivent. Cela veut dire qu'il faut préciser, pour chacune de ces grandeurs, ses valeurs minimale et maximale possibles et les valeurs de référence, ainsi que le type de sa précision absolue ou relative. Ces grandeurs sont généralement fournies sous forme décimale. Les grandeurs ainsi décrites sont numérisées en respectant les règles d'échantillonnage de Shannon, enregistrées et introduites dans un tableur (étape 2 du dessin), à raison d'une grandeur par cellule, et sont, bien entendu, classées de façon à être facilement exploitables, par exemple par ordre chronologique. Un classement possible (illustré en figure 2) consiste, par exemple, à réserver une première feuille 7 du tableur à l'inscription des valeurs de référence des grandeurs à traiter, une autre feuille 8 à l'inscription des résultats du traitement effectué par le logiciel, et une autre feuille 9 pour les comparaisons des résultats avec les valeurs de référence. Dans chacune de ces feuilles; on peut, par exemple, affecter chacune des colonnes successives de cellules à une donnée. Les en-têtes de ces feuilles peuvent, par exemple, mentionner leur type (valeurs de référence, résultats et comparaison, comme précisé ci-dessus), le nombre de leurs lignes et de leurs colonnes utilisées. Dans une première ligne, on peut inscrire les noms des données D1 à Dn (ou variables) affectées aux colonnes successives. Dans les lignes suivantes de la première feuille, on peut inscrire successivement, pour chacune des colonnes - pour les données qui sont fonction de l'application considérée ou d'une catégorie: les valeurs maximales, minimales et la précision ou la résolution notée Delta (ou erreur tolérable entre la valeur de référence et la valeur fournie en entrée); - en fonction du langage de programmation : le type de donnée, sa dimension et sa classe de précision, - la précision nécessaire et suffisante pour le résultat de la comparaison (notée P. Comp ), - les valeurs des données qui doivent être obtenues (chronologiquement le cas échéant, si elles sont amenées à évoluer). Pour la deuxième feuille, on inscrit dans les lignes successives les résultats obtenus, dans l'ordre chronologique, et dans la troisième feuille, on inscrit les résultats de calculs de comparaison avec les valeurs de référence correspondantes (notés AC ), ces résultats de comparaison pouvant aussi bien être des valeurs de référence, que des valeurs relatives, et/ou bien même des valeurs initiales, ou des gradients de dérives. Une fois les données d'entrée enregistrées dans le tableur, on les combine en un fichier de protocole de tests (étape 3) qui soit compatible avec les caractéristiques de la machine de test. Cette étape de combinaison est réalisée de façon connue en soi, et conduit à réaliser un fichier, par exemple de type DLL pour un calculateur de type P.C. Une fois le fichier de protocole compatible réalisé, et envoyé à la machine de test, cette dernière réalise les tests demandés de façon habituelle (étape 4). A la fin des tests, les résultats sont fournis par la machine également sous forme d'un fichier, qui est à son tour converti par un autre fichier DLL en un fichier exploitable par le tableur (étape 5) L'utilisateur peut alors mettre en oeuvre toute la puissance d'analyse du tableur pour exploiter les résultats des tests (étape 6). On notera que l'utilisateur peut, en outre, faire appel à d'autres programmes pour enrichir les fonctions mises à sa disposition par le tableur il peut saisir, et/ou visualiser, et/ou organiser, et/ou importer à partir de ces autres programmes, les données d'entrée et/ou de sortie des tests. Ces autres programmes sont, par exemple, des programmes tels que : un progiciel de pilotage de banc de test et de mesure (par exemple LABVIEW), et/ou un progiciel de traitement de signal et de simulation (par exemple MATHLAB), et/ou un progiciel de résolution formelle et/ou numérique d'équations (par exemple MATHEMATICA), et/ou des programmes de CAO (Conception Assistée par Ordinateur). Il peut également modifier partiellement ces données d'entrée et de sortie grâce aux commandes habituelles du tableur. Ainsi, grâce à l'utilisation combinée du tableur et de la machine de test, avec les conversions appropriées assurant la compatibilité entre eux, et après avoir caractérisé formellement les données, l'utilisateur peut savoir si la conversion entre le type formel et le type logiciel d'un ensemble de données est mathématiquement licite ou non, ce qui garantit la bonne conversion des données d'entrée du test depuis le type formel vers le type logiciel, en conservant les contraintes de précision imposées au type formel et en minimisant la sur-précision ou la sous-précision de la donnée logicielle, convertie au strict minimum imposé par le mode de représentation interne du type de langage choisi. Bien entendu, la conversion inverse de chaque donnée de sortie du test est garantie de la même façon. Les comparaisons entre les données de sortie de référence et celles de test sont effectuées en tenant compte d'une incertitude associée à chaque donnée et compatible de son type formel. En outre, le procédé de l'invention permet de générer, de façon connue en soi, un logiciel en code source (langage tel que C ou ADA, ... ) qui permet d'exécuter les tests soit sur le calculateur hôte (celui sur lequel est installé le tableur) ou sur le calculateur cible (celui de l'automatisme, pour l'exemple décrit ici), après téléchargement du logiciel source. Ce logiciel source, une fois compilé et édité avec le langage binaire du logiciel à tester, permet, sans intrusion dans le logiciel à tester, de lire un ensemble de données d'entrée dans le fichier des données d'entrée converties au format logiciel utilisé, de les transférer au logiciel à tester sous forme de paramètres ou de valeurs de données globales, d'exécuter le logiciel à tester, de collecter les résultats des tests (sous forme de paramètres de sortie, de résultats de fonctions ou de valeurs de données globales) pour les stocker dans le fichier de sortie sous format logiciel, puis d'itérer le processus pour les données de test suivantes, jusqu'à épuisement de ces données.. Ces données de test successives peuvent correspondre aux valeurs successives dans le temps des signaux d'entrée échantillonnés et traités par le logiciel temps réel testé. REVENDICATIONS 1. Procédé universel de test de logiciels, utilisant une machine de test, caractérisé par le fait qu'il consiste à numériser les grandeurs d'entrée des logiciels à tester, à les enregistrer, à préparer les données ainsi obtenues en les décrivant de façon mathématique formelle (1), à introduire dans un tableau de tableur (2) des valeurs de ces données et leurs descriptions correspondantes, dans le langage de programmation qui code le logiciel à tester, à vérifier la cohérence entre les caractéristiques des données d'entrée et le type logiciel résultant en respectant la précision requise des données d'entrée, à traduire (3) les données issues du tableau dans un format de fichier compatible avec celui de la machine de test, à effectuer les tests de façon classique avec la machine de test (4), et à exploiter les résultats des tests (6). 2. Procédé selon la revendication 1, caractérisé par le fait que lorsque les données d'entrée sont relatives à des dispositifs physiques, ces données, ainsi que les données résultant des tests sont converties pour être affichées dans le tableau conformément à la représentation des données en physique théorique. 3. Procédé selon la revendication 1 ou 2, caractérisé par le fait que les résultats des tests sont exploités à l'aide du tableur et/ou d'un programme associé, en retraduisant les données de sortie de la machine de test en données dans un format compatible avec celui du tableau ou du programme associé, en respectant la précision requise des données. 4. Procédé selon l'une des revendications précédentes, caractérisé par le fait que l'on fait appel à d'autres programmes pour enrichir les fonctions mises à disposition par le tableau. 5. Procédé selon la revendication 4, caractérisé par le fait que l'enrichissement des fonctions comporte l'une au moins des fonctions suivantes : saisie, visualisation, organisation, importation des données d'entrée et/ou de sortie des tests. 6. Procédé selon l'une des revendications 4 ou 5, caractérisé par le fait que lesdits autres programmes sont : un progiciel de pilotage de banc de test et de mesure et/ou un progiciel de traitement de signal et de simulation et/ou un progiciel de résolution formelle et/ou numérique d'équations et/ou un programme de CAO. 7. Procédé selon l'une des revendications précédentes, caractérisé par le fait que les tests sont exécutés sur le calculateur sur lequel est installé le tableur. 8. Procédé selon l'une des revendications 1 à 6, caractérisé par le fait que les tests sont exécutés sur un calculateur cible, après téléchargement du logiciel source.