Brevet FR2827975A1 — publié le 20030131

les opérations qui les suivent par les opérations spécialisées correspondantes. METHODE POUR TESTER UN LOGICIEL ET/OU UN SUPPORT DE DONNEES PORTABLE La présente invention concerne une méthode pour tester un logiciel. Plus s particulièrement, l'invention concerne le test de supports de données portables, surtout sous forme de cartes à puce. Les programmes pour cartes à puce se caractérisent en ce qu'on ne peut y accéder qu'à kavers une unique interface définie, plus précisément à travers ce que l ' on nomme ordres APDU (unité de données de protocole d ' application) et moyennant laquelle ils doivent également être testés. Les ordres APDU sont indépendants du protocole de transmission utilisé et servent de contenteur de données pour la transmission d'ordres à la carte à puce et pour les réponses correspondantes. Différents procédés connus permettent de tester le fonctionnement d'une carte à puce. Un concept connu de méthode de test comporte un test en deux phases. A cette occasion, on rédige durant la première phase un script de test sur la base duquel, pendant la deuxième phase, le dispositif de test ou le test est généré. La première phase est indépendante de la deuxième phase, si bien que le développement et l'exécution du test peuvent avoir lieu séparément. Ceci présente l'avantage d'avoir un test qui est réutilisable, facilement lisible et compréhensible dans sa totalité, étant donné que le script de test comprend l' application de ce que l'on nomme des mots d'action décrivant la fonction correspondante à un niveau plus abstrait et plus élevé que le code correspondant intrinsèque généré à partir du script de test. On connâît également la réalisation de la conception d'un test indépendamment du codage du test et d'élaboration d'un plan pour le test dans un métalangage à un niveau abstrait. La conception du test peut être introduite, à fin d'exécution, sur le système cible à tester en utilisant le script de test. Dans ce cas, il est nocessaire, pour l'élaboration de la conception du test et du script de test, de disposer de solides connaissances sur le système à tester car on doit savoir, par exemple quels sont les ordres à tester de manière judicieuse, à quel moment et quelles en sont les interdépendances. Par contre, le codage du test ne nécessite pas de connaissances plus approfondies sur le système à tester mais sur les alternatives de codage et procédés similaires. On connaît, de WO-A-94/15289, un système de test ainsi qu'une méthode de test s'y rapportant et qui génère et contrôle automatiquement un scénario de test en prenant en compte les conditions préalables. La méthode de test proposce fait appel à l'exécution d'une suite de sous-programmes. Les différents sous-programmes sont dans un premier temps contrôlés afin de vérifier s'ils sont aptes à fonctionner. \\TBPSCH4\VOLl\DACTYL0\19500\19504.doc - 29 mars 2002 - 1/19 Ensuite, on contrôle leur comportement avec différentes combinaisons de conditions préalables, puis l'exactitude des post-conditions qui en résultent. En cas de déLaillance durant l'un des contr81es, celle-ci est communiquée à l'ingénieur responsable du test. La méthode systématise et standardise le test d'un logiciel. On connâît en outre, grâce à l' article intitulé erreurs contenues dans un logiciel. On connat en outre le concept de " backtracking " (rebroussement de chemin). Il constitue un mécanisme essentiel dans le langage de programmation " Prolog " et est donc utilisé comme une sorte de métarègle qui travaille également en suivant le principe " Divide and Conquer ", ce qui signifie le partage d'une tâche globale en sous-tâches qui se dérouleront les unes après les autres. Le concept du rebroussement de chemin est fondé sur une résolution partielle, générant par conséquent une recherche de solutions et un test récursif afin de déterminer ainsi si une solution globale est possible. Si cela n'est pas possible, le déroulement du programme revient donc en arrière aussi loin que nécessaire - par exemple dans une structure arborescente correspondante - jusqu'à ce qu'un n_ud soit atteint qui n'a pas encore été pris en charge. Une nouvelle solution partielle en résulte et le processus est répété. Un retour en arrière a donc touj ours lieu lorsqu'une solution partielle a échoué. Le concept du retroussement de chemin peut en principe n'être utilisé en relation avec le contrôle de la fonctionnalité des cartes à puce que du côté logiciel. Une telle utilisation présente cependant le désavantage que le rebroussement de chemin ne sert à indiquer lors de l'exécution d'un ordre, que les dépendances existantes vis-à-vis d'autres ordres qui fournissent les conditions préalables d' exécution. Si une condition n' est pas remplie, il n'est pas possible de déduire si un ordre testé est exact ou erroné. Dans ce cas, le contrôle ne donne pas de résultat explicite mais permet seulement de déterminer qu'un ordre devant être testé ne peut pas être contrôlé. Ce qui veut dire que le contrôleur a alors pour tâche d'indiquer une nouvelle solution partielle qui fournira les conditions nécessaires pour tester l'ordre. 3s Une telle méthode est. de plus, lorsqu'elle est exécutée manuellement, inacceptable au point de vue coût et durce. Pour tous les ordres, un tableau correspondant est établi - ce que l'on nomme une table de description des commandes - qui fixe pour chaque ordre les possibles \\HIPSCH4\VOLl\DACIYLO\19500\19504.doc - 29 nars 2002 - 2119 combinaisons des conditions ainsi que les paramètres de résultats. Si un ordre doit étre contr81é, il est possible, au moyen du tableau, de saisir toutes les conditions préalables nécessaires. Ensuite, on vérifie si celles-ci sont remplies. L'ordre ne peut être exécuté et contrôlé que si c'est le cas. Pour de nombreuses méthodes de test de contrôle de cartes à puce, une difficulté courante réside dans le fait que chaque ordre d'un ensemble d'ordres à tester doit être testé individuellement. Pour ce faire, la totalité des combinaisons essentielles doit être couverte par le script de test. D'éventuelles interdépendances entre les ordres devant être testés individuellement, ne peuvent pas être détectées. o C'est pourquoi l'objet de la présente invention est de proposer une méthode pour tester les logiciels des supports de données portables, tout particulièrement ceux prenant la forme de cartes à puce; cette méthode permettant de simplifier, d'accélérer et de fournir un résultat de test sans équivoque pour une étendue de test la plus large possible. Le problème est résolu grâce à une méthode ou un procédé pour tester un logiciel et / ou un support de données portable au moyen d'un système de test par contrôle de l'exécution d'au moins un ordre par le logiciel et / ou au support de données portable, dans laquelle la possibilité d'exécution de l'ordre nécessite que soit remplie au moins une condition préalable; la méthode se caractérisant par les étapes suivantes: - de transfert au logiciel d'un ordre à tester, - de détermination des conditions préalables nocessaires à l'exécution de l'ordre à tester, - de contrôle pour vérifier que les conditions préalables sont remplies, - le cas échéant, remplir les conditions préalables non remplies grâce au système de test, - d'exécution par le logiciel de l'ordre à tester, - de détermination du résultat du test obtenu par l'exécution, - d'évaluation du résultat du test au moyen d'un résultat cible prédéterminé. Selon un autre mode de réalisation de la méthode les conditions préalables sont remplies du fait qu'au moins un ordre supplémentaire est émis et exécuté et fournit en tant que post-condition une condition préalable qui n'a pas été remplie dans un premier temps. L'ordre supplémentaire est émis au moyen de la mise en _uvre d'une recherche dans une base de connaissances, et les conditions préalables et les post- conditions de l'ordre sont, pour chaque ordre déposées dans la base de connalssances. H:\DACIYLO\19500\19504.doc - 29 T 2002 - 3119 La méthode peut être employée en mode récursif pour l'ordre supplémentaire, ou bien une suite d'ordres à tester est testée au moyen d'une application itérative de la méthode. Selon un autre mode de réalisation de la méthode ou du procédé, le résultat du test permet d'obtenir une différence non équivoque entre les cas " l'ordre est sans défaut " et " l'ordre n'est pas exécutable ". La méthode peut afficher en plus la cause de l'impossibilité d'exécution en cas de résultat de test: " l'ordre n'est pas exécutable " Toutes les conditions préalables peuvent être automatiquement remplies et les o conditions préalables peuvent être sélectionnées manuellement et / ou les conditions préalables sélectionnées en fonction de critères prédéfinis sont remplies automatiquement. Selon un autre mode de réalisation de la méthode, l'ordre à tester est sélectionné, au moyen d'un générateur de nombres aléatoires, à partir d'un ensemble d'ordres possibles. L'évaluation de l'exécution de l'ordre à tester est effectuée en se basant sur une structure de données de résultats au moyen de laquelle le résultat déterminé du test est comparé avec un résultat cible déterminé pour en vérifier la concordance. Les informations nécessaires pour le test de l'ordre à tester, tout particulièrement les conditions préalables à l'exécution de l'ordre à tester (10), sont automatiquement remplies du fait qu'au moins un ordre supplémentaire est exécuté. Le système de test pour la mise en _uvre de la méthode, telle que décrite ci dessus est caractérisé par: - des moyens pour la détermination d'un ordre à tester, - un dispositif de " Command Tracking ", se composant au minimum d'un dispositif de détermination pour la détermination de(s) la condition(s) préalable(s) pour un ordre à tester et - des moyens pour remplir les conditions préalables de l'ordre à tester, lesquels remplissent la condition(s) préalable(s) au moins et en partie automatiquement grâce à l'exécution d'un ordre supplémentaire, dans le cas o l'ordre à tester ne peut pas être exécuté. - des moyens pour l'exécution de l'ordre à tester, - une unité d'évaluation pour évaluer l'exécution de l'ordre à tester, ainsi que des moyens pour diriger un résultat de test explicite, qui se trouve en échange de données avec l'unité d'évaluation. L' invention adopte une approche pour tester un logiciel et / ou le matériel informatique qui en est à la base, selon lequel est contrôlée leur réaction à des ordres à tester dépendant à chaque fois de conditions préalables correspondantes. Pour ce \\HIRSCH4\VOLl\DACTYLO\19500\19504. doc - 29 mal3 2002 - 4/19 faire, les conditions préalables et nécessaires pour l'exécution d'un ordre à tester sont automatiquement générées selon l'invention lorsqu'elle ne sont pas présentes. La réalisation est effectuée grâce à une combinaison entre une constellation de conditions préalables requises et les possibles post-conditions associées de la totalité des ordres. Pour la combinaison automatique générant les conditions préalables manquantes, le système de test utilise une base de connaissances pré- établie. La méthode objet de l'invention présente l'avantage, en se référant à la fonctionnalité du logiciel testé, de toujours fournir un résultat de test explicite et de o certifier deux catégories de résultats, à savoir " erroné " et " exact ". Les résultats non explicites qui définissent un résultat de test uniquement en fonction d'évènements supplémentaires, sont éludés. La méthode objet de l'invention permet, d'une manière avantageuse, une automatisation extrémement étendue du test d'un logiciel. En général, l'ingénieur de test chargé de l'exécution d'un test doit créer une base de connaissances qui décrit les ordres à tester et fournit les conditions préalables à remplir mais aussi les réponses ainsi que les postconditions. Le test caractéristique peut alors automatiquement étre exécuté par un système de test. Ce résultat est obtenu par l' introduction d'un " Command Tracking ". Dans ce cas, à la différence du concept connu de rebroussement de chemin (Backtracking), une condition non remplie et dont la réalisation est obligatoire pour l'exécution d'un ordre, est automatiquement configurée, de sorte que une itération de la méthode sur plusieurs ordres soit possible. La méthode de test peut continuer, notamment en mode récursif jusqu'à ce qu'une différence soit possible entre " l'ordre n'est pas exécutable " et " l'ordre a été correctement exécuté ". Un autre avantage réside dans la différenciation entre les bons et les mauvais cas o les bons cas englobent des scénarii pour lesquels une exécution de l'ordre à tester est possible et o les mauvais cas englobent les scénarii pour lesquels une exécution de l'ordre à tester n'est, dans un premier temps, pas possible et tout spécialement lorsque au moins une condition préalable n'est pas remplie. Si un mauvais cas se présente, les conditions préalables non encore remplies sont tout d'abord automatiquement remplies grâce à la mise en _uvre de la méthode objet de l' invention et l'ordre à tester, pour autant que cela soit possible, exécuté. I1 est ensuite soumis à une évaluation. Le cas échéant, la méthode est appliquée en mode récursif pour le test des conditions préalables et / ou des ordres de condition préalable. Si un ordre, malgré la confguration de toutes les conditions préalables nocessaires, n'est pas exécutable, un message d'erreur est émis. Dans ce cas, soit le \\HIRSCH4\VOLl\DACTYL0\19500\19504.doc - 29 mas 2002 - 5/19 logiciel testé présente une erreur de logiciel, soit le matériel informatique support présente une erreur de matériel, Pour tester entièrement un logiciel, il sufft de déterminer à intervalles réguliers manuellement, c'est-à-dire en les faisant déterminer par un ingénieur de test chargé de l'exécution du test, un nombre limité d'ordres à tester et de cas de tests. Le test des ordres restants qui ne sont pas déterminés comme devant être absolument testés est automatiquement fait par le système de test qui génère pour ce faire les conditions préalables correspondantes à un ordre et de plus exécute à nouveau les ordres appropriés que les conditions préalables sont fournies. Le système de test génère o ainsi indépendamment des suites d'ordres complètes qui sont exécutés avant que n' arrive un ordre d' exécution fixé par l'ingénieur de test. C ' est pourquoi l'ingénieur de test peut choisir de façon arbitraire les ordres à tester; ils ne doivent pas être liés dans un déroulement de programme global et prescrit. Dans une variante favorable et entièrement automatique, un ordre à tester est à chaque fois sélectionné à partir de l' ensemble des ordres à tester en utilisant un générateur de nombres aléatoires. La méthode de test est alors répétée de nombreuses fois, et surtout aussi souvent jusqu'à ce que l'on suppose que tous les ordres de l'ensemble des ordres ont été testés au moins une fois. Le système de test, conforme à l'invention se caractérise en outre également en ce que des cas de test - principalement tous les cas de test nécessaires - sont automatiquement générés et en ce qu'ainsi la probabilité d'erreur peut être réduite. Si la méthode pour tester un ordre se déroule dans une situation dans laquelle un ordre à tester n'est pas, dans un premier temps, exécutable parce qu'une condition préalable n'est pas remplie ou est erronce, la méthode recherche dans une base de connaissances qui contient les postconditions pour tous les ordres possibles, une pré-condition qui n'a pas été tout d'abord remplie pour l'ordre à tester. La réalisation de la condition préalable peut surtout avoir lieu en ce qu'un ordre supplémentaire est exécuté et qui fournit la réalisation de la condition préalable en tant que résultat cible ou post-condition. Si un tel ordre supplémentaire est présent, il est exécuté automatiquement ou après une saisie correspondante et interactive de l'utilisateur. La base de connaissances se compose surtout d'un grand nombre de tableaux et tout particulièrement de tableaux descriptifs des ordres qui contiennent pour chaque ordre les post-conditions possibles et les conditions préalables nécessaires. C'est pour cette raison que la méthode de test présente l'avantage de pouvoir être utilisée aussi longtemps jusqu'à ce que, dans le pire des cas un résultat de test explicite soit obtenu et que de plus, on puisse déterminer si l'ordre à tester a été exécuté correctement ou non. \\HIRSCH4\VOLI\DACTYLO\19500\19504 doc - 29 mars 2002 - 6/19 Le fait que les structures de données utilisoes soient indépendantes de l'application et de la situation présente également l'avantage que la méthode de test peut être appliquée plusieurs fois à différents scénarii sans que l'on soit obligé à chaque fois de programmer à nouveau. La méthode est conçue de fa,con prétérentielle de telle sorte que le codage du test particulier ne se fasse pas directement mais au contraire au moyen d'un mécanisme de génération indépendant et monté en série qui génère un script de test. C'est pourquoi les données nécessaires et les ordres de l'utilisateur peuvent être réalisées par une conception abstraite et à langage développé si bien que l'on a lo l'avantage d'avoir une interaction facilitée avec le système car le langage utilisé est plus aisément compris et qu'il n'est pas nécessaire d'avoir des connaissances spécifiques d'un langage de programmation. Le modèle préférentiel de l'invention se réfère au test de systèmes d'exploitation de cartes à puce et d'applications de cartes à puce. Les cartes à puce possèdent une interface définie qui permet de les faire fonctionner, tout particulièrement au moyen d'ordres APDU (unité de données de protocole d'application). Cet ensemble d'ordres est pour la carte à puce d'un volume relativement petit et englobe environ 3 0 ordres dans des systèmes d' exploitation de cartes à puce, connus et indépendants de l' application, s ' adaptant sur différentes plates-formes de matériel informatique. Un autre mode de réalisation préférentiel de l'invention consiste en ce que l'évaluation de l' exécution d'un ordre à tester d' après une structure de donnces prédéterminée, tout particulièrement d'une structure de données à résultat cible, s'effectue en comparant la concidence entre le résultat de l'exécution d'un ordre à 2s tester avec un résultat cible déterminé dans une structure de donnces à résultat cible. Le résultat cible est. de plus, à prendre comme résultat généré en cas d'exécution exacte de l'ordre correspondant - c'est à dire en l'absence d'erreurs de logiciel ou de matériel informatique. La structure des données du résultat cible se présente principalement sous forme d'un tableau qui fixe, pour chaque ordre et chaque combinaison de paramètres de l'ordre, les résultats respectifs des ordres et les post conditions. Elle est déterminée à l'avance par la saisie maouelle faite par l'ingénieur de test lors de l'exécution du test. Dans un mode de réalisation préféré de l'invention, la structure des données du résultat cible est intégrée dans une base de connaissances qui englobe toutes les pré constellations, tout particulièrement les conditions préalables et les post constellations, tout particulièrement les résultats cibles d'un ordre. Dans un mode de réalisation préféré de l'invention, la méthode est utilisée en mode récursif sur l'ordre suivant et / ou les ordres suivants. Cela signifie que dans \llRSCH4\VOLl\DACTYLO\19500\19504.doc - 29 Ir 2002 - 7/19 une première étape récurrente, l'ordre suivant qui remplit au moins une des conditions préalables de l'ordre à tester, est exécuté et dans le même temps, cockôlé. Si, de son côté, l'ordre suivant possède une condition préalable qui n'est pas remplie mais qui, grâce à l'exécution d'un koisième ordre, pourrait êke remplie, la méthode est utilisée, au cours d'une deuxième étape récurrente; l'ordre est donc de même testé et le cas échéant exécuté. Cette récurrence se déroule, selon l'invention, aussi longtemps que toutes les conditions préalables de l'ordre respectif à tester sont remplies ou que par ailleurs un ordre final de test n'est pas exécutable en raison d'une erreur de logiciel ou de matériel informatique. Dans ce cas, le test donne le 0 résultat " l'ordre ne peut pas être exécuté ". De plus, le test fournit d'une manière judicieuse pour le résultat cité, l'origine de l' erreur et / ou l' emplacement de l' erreur. Il arrive généralement qu'un ordre à tester possède une condition préalable qui ne peut tout simplement pas être remplie par l'exécution d'un ordre mais au contraire, nécessite l'exécution de plusieurs ordres. La prise en charge des conditions préalables peut êke figurée sous la forme d'une skucture arborescente qui présente comme n_ud de racine, l'ordre à tester dont les n_uds représentent les actions ultérieures à exécuter et dont les feuilles forment les ordres pour les conditions préalables qui, de leur côté - en raison de la récursivité de la méthode peuvent donner lieu à nouveau à une telle sbucture. L'invention dessine là plusieurs concepts pour la prise en charge des conditions préalables. Un concept consiste donc en ce que la prise en charge se déroule jusqu'à une feuille finale d'un sous-arbre qui a été déterminé comme recherche de solutions garante de réussite. Ce résultat cible est ensuite réacheminé aux n_uds des racines afin d'effectuer éventuellement déjà le test avec ces informations et d'exécuter l'ordre à tester. Ce concept peut également eke décrit sous la forme de l'application d'une stratégie en profondeur d'abord (Depth-First). Un anke concept consiste à prendre tout d'abord en charge, tous les n_uds de tous les sous-arbres à l'échelon de la skucture arborescente et de partager ensuite ce résultat avec les n_uds des racines. Ce concept se base sur une skatégie en largeur d'abord (Breadth-First). Une anhe alternative est possible. Elle réside dans la recherche d'un résultat de test avec un tri qui combine, pour ce faire, les ordres à exécuter après une probable réussite. Ceci peut se faire avec l'aide de ce que l'on nomme une mesure heuristique. Une alternative permet également un kaitement maouel de l'arbre de recherche qui peut êke dirigée manuellement; dans ce cas seuls les sousarbres sélectionnés sont réalisés, au moyen d'une saisie interactive via un terminal. On obtient ainsi l'avantage de pouvoir déterminer spécifiquement, d'une part quelles sont les skuctures de l'arbre qui doivent êke prises en charge de prétérence car elles sont \\HIRSCH4\VOLl\DACTYLO\19500\i9504.doc - 29 n3n 2002 - 8/19 plus prometteuses de réussite que d'autres et d'autre part, quelles sont les structures de l'arbre qui ne doivent pas être exploitées car, par exemple, un test de ces ordres avec leurs conditions préalables durerait beaucoup trop longtemps. Dans une des formes préLérentielles de l'invention, il est prévu que toutes les s conditions préalables de l'ordre à tester, appartenant à un ensemble pré-défini d'ordres, soient à chaque fois, automatiquement remplies. Ceci présente l'avantage d'avoir un test complet et de tester en mode récursif tous les ordres d'un ensemble d'ordres précédemment déterminé. Cependant, cette procédure peut se révéler complexe et longue. 0 C' est pourquoi une solution alternative prévoit que toutes les conditions préalables ne soient pas automatiquement remplies mais seulement d'avoir des conditions préalables sélectionnées et/ou des conditions choisies en fonction de critères déterminés. On peut ainsi concentrer le test sur des ordres essentiels. D ' autres avantages, caractéristiques et modèles alternatifs d' exploitation de S l'invention dérivent de la description détaillée des figures qui suivent, faite à titre non limitatif et en relation avec le dessin avec le dessin dans lequel: La figure 1 est une représentation schématique d'un arbre de décision, La figure 2 est une représentation d'un ordinogramme de traitement présentant le déroulement de la méthode, objet de l'invention, La figure 3 est un extrait d'une représentation schématique d'une structure de données - évènements. En ce qui concerne la description suivante, nous sommes partis du principe que le logiciel à contrôler est le logiciel d'un support de données portable prenant la forme d'une carte à puce. Mais la méthode décrite et le système de test correspondant 2s peuvent également être utilisés pour le contrôle d'autres supports de données équivalents à condition que leur logiciel soit accessible au moyen d'une interface définie et d'un ensemble d'ordres limité. De plus, la méthode ou le procédé peut, en règle générale, être également employée pour contrôler les logiciels de dispositifs de traitement de données d'un quelconque agencement, par exemple pour tester des programmes de PC (ordinateur personnel). Pour exécuter la méthode de test, on utilise un système de test constitué de composants connus de matériel informatique et dont on sait que la structure est adaptée à la méthode de test. Le système de test dispose de moyens, d'une structure de matériel informatique lui permettant, d'une part de transmettre les ordres à tester 3s appartenant au logiciel à tester et d' autre part d' évaluer les réponses fournies en retour par le logiciel testé. Normalement, le système de test est basé sur la mise en ordre de tous les composants d'un ordinateur qui est configuré pour exécuter le programme du test. Pour ce faire, le système de test dispose de moyens qui lui \\HIRSCH4\VOL I\DACI.YLO\1 9500H9504.doc - 29 mars 2002 - 9/19 permettent de générer un programme de test mis en _uvre par un ingénieur de test chargé de l'exécution du test. Tout particulièrement, il permet de façon très efficace de générer une base de connaissances 22. Dans la description suivante basée sur un support de données portable, la s totalité des échanges de données est réalisée entre le support de données portable et le système de test mis en _uvre pour l'exécution du test au moyen d'un ordre APDU (unité de données de protocole d'application). La structure de ces ordres et la structure des informations ainsi transmises sont décrites, par exemple dans le "Handbrich des Chipkarton" (Manuel des cartes à puce), W. Rankl, W. Effing, 3ème o édition, 1999. Pour tester la fonctionnalité du logiciel du support de données portable, on procédera à l' évaluation, d'une part d' au moins un ordre, mais de préférence d'un ensemble d'ordres à tester transmis sous la forme d'ordres APDU et d'autre part des réponses envoyées en retour par le logiciel du support de données portable, réponses prenant la forme de ce que l'on nomme des " codes de retour ". Le logiciel est sans défaut lorsque tous les ordres à tester qui ont été envoyés au support de données portable sont exécutables et que les répons es défini es ont été données. De plus, les réponses peuvent communiquer le contenu en cas de situation erronée, c ' est-à-dire lorsqu'une zone d' adresses stockée n' est pas approprice pour exécuter, au moyen d'un ordre APDU, une action prescrite. Si un logiciel testé ne répond pas à un ordre à tester ou donne une réponse différente de la réponse prédéfinie, le système testé présente une erreur de logiciel ou de matériel informatique. Le principe de base de la méthode de test proposée va maintenant être explicité. Comme le montre la figure 1, la méthode pour tester le logiciel d'une carte à puce en testant l'exécution d'un ordre 10 est représentée par une structure arborescente. Pour ce faire, l'ordre à tester 10 forme les racines de l'arbre. Pour que l'ordre à tester 10 puisse être exécuté, il faut que les conditions préalables soient remplies. C'est pourquoi le système de test utilisé vérifie si les conditions préalables sont présentes. Ces conditions préalables peuvent maintenant de leur côté faire en sorte que les différents ordres supplémentaires 12 soient exécutés. Ces ordres supplémentaires 12 sont représentés à l'échelon supérieur de la structure arborescente. Les ordres supplémentaires 12 peuvent, en ce qui concerne leur possibilité d'exécution être dépendants d'ordres tiers. Ceci est présenté au troisième niveau de l'arbre avec les n_uds B21 et B22. Dans l'exemple représenté en figure 1, 3s l'ordre à tester 10, appelé ici B. ne peut être finalement testé que si les autres ordres 12, c'est-à-dire dans ce cas: B1, B2, B3, Bx, By et B21 et B22 ont été exécutés avec succès. \\HiRSCH4\VOLl\DACTYLO\19500\19504 doc - 29 man 2002 -10/i9 La méthode pour le contrôle de la possibilité d'exécution de l'ordre B conduit alors à la procédure suivante: L'ordre à tester 10 ne peut pas être directement exécuté car sa possibilité d'exécution dépend de conditions préalables 14, dans le cas présent: B1, B2, B3 s jusqu'àBy qui ne sont que partiellement remplies. Ces conditions préalables 14 peuvent cependant être remplies grâce à l'exécution d'ordres supplémentaires 12. Ainsi, par exemple, l'ordre supplémentaire 12 peut être exécuté si ses conditions préalables 14 sont remplies. Celles-ci peuvent être remplies au moyen des ordres supplémentaires B21 et B22. L'arbre est alors traité pendant le déroulement du test o depuis la racine B jusqu'aux n_uds des feuilles B21, B22. Si les feuilles peuvent être satisfaites et / ou exploitées avec succès, le résultat intermédiaire est alors retransmis au n_ud correspondant immédiatement supérieur, dans le cas présent, B 22. Ensuite, ce n_ud est exploité et testé afin de pouvoir être pris en charge avec succès. Si cela est le cas, ce résultat intermédiaire est reporté à nouveau sur le n_ud correspondant S immédiatement supérieur, dans le cas présent sur le n_ud de la racine B. Toutes les autres conditions relatives à l'exécution de l'ordre à tester 10 sont alors traitées de la même manière et / ou remplies grâce à l'exécution des ordres supplémentaires respectifs. Si au final, toutes les conditions préalables pour une exécution sont remplies, l'ordre respectif à tester 10 peut passer le test. Il est évident que le traitement d'un arbre complet avec une structure arborescente complexe nécessite beaucoup de temps. C'est pourquoi il est avant ageus em ent prévu que s eules des branches pré ci s e s et / ou des ens emb l es d'ordre passent le test. De plus, les autres ordres sont perçus comme sans défauts. Ceci peut se faire, avant ou pendant le test, grâce à l'exploitation d'une entrée interactive. Il est possible d'avoir une alternative qui consiste, avant le déroulement du test à définir des ensembles d'ordres précis qui se composent d'ordres qui doivent être testés. L'avantage d'un tel principe de test focalisateur est d'avoir une efficacité améliorée. Cependant, il faut accepter que dans ces conditions, le résultat du test est. d'une part moins précis et d'autre part ne permettra pas de fournir des énoncés univoques. A l' aide de la figure 3, le déroulement d'une méthode de test va maintenant être explicitée à l'aide d'un exemple. L'ordre à tester 10 serait dans l'exemple l'ordre " EFFACER FICHER " qui entrâîne l ' effacement d' un fichier existant. La condition 3s pour la possibilité d'exécution de cet ordre est que le fichier, c'est-à-dire le fichier respectif, existe pour que cet ordre puisse être appliqué. Si le fichier n'existe pas, le test correspondant à cet ordre ne peut pas être directement exécuté. C'est pourquoi, conformément à la méthode, dans ce cas, les conditions préalables qui doivent être \\IERSCH4\VOLl\DACrYLO\19500\19504.doc - 29 mam 2002 - Z 1/19 remplies, sont saisies en premier, afin que le test correspondant à l'ordre 10 soit exécutable. Ceci se passe à l' aide des tableaux descriptifs d'ordres qui, comme cela est représenté sur la figure 3, comprennent chacun une structure 24 de donnces des événements et une structure 26 de donnces de résultats. S'y ajoutent pour chaque ordre 10 à tester la structure d'ordres APDU correspondante 18 avec les paramètres réglables 19 et les occupations possibles de variables, les constellations possibles de conditions préalables 14, les possibles résultats cibles prédéfinis 16 ainsi que les post-conditions 17 reçues lors de l'exécution correcte. lo Dans l'exemple, une condition préalable 14 pour l'ordre " EFFACER FICHIER" est la condition "fichier effaçable existant", un résultat cible 16 est " CREER FICHIER ". Durant la prochaine étape, on contrôle à nouveau si l'ordre " CREER FICHIER " peut être directement exécuté. Pour ce faire, on recense si toutes les conditions préalables 14 nécessaires à son exécution sont remplies. Ceci s'effectue éventuellement en utilisant encore une fois la structure 26 de données de résultats cibles. Ici, on part du principe que les conditions préalables 14 sont remplies et tout particulièrement la condition " le nouveau fichier pouvant étre créé n'existe pas encore " est applicable. L'ordre " CREER FICHIER " peut alors être directement exécuté. Ainsi, la branche représentée dans la partie gauche de l'ordinogramme de la figure 2 est parcourue. Une fois que l'ordre "CREER FICHIER" a été exécuté, on contrôle si l'exécution a fourni le résultat cible 16 correspondant aux conditions préalables 14. Pour ce faire, on accède à la structure 26 de donnces de résultats qui prend en principe la forme d'un tableau et forme ensemble avec la structure 24 de données des événements une base de connaissances 22. Le résultat de l'ordre est comparé avec le résultat cible 16 théoriquement correct et inscrit dans le tableau. Si les deux ensembles de données concordent, on en conclut que l'ordre a été correctement exécuté. Dans le cas contraire, un message d'erreur est émis. \\HIRSCH4\VOLIU)ACTYLO\ 1 9S00\1 9504.doc - 29 mars 2002 - 12/19 Par la suite, on peut poursuivre le test de l'ordre 10 " EFFACER FICHIER " introduit à l'origine dans lequel on retourne en arrière à la racine de l'arbre et on contrôle à nouveau si l'ordre à tester 10 " EFFACER FICHIER " est exécutable. Etant donné que toutes les conditions préalables 14 sont remplies et que notamment s il existe un fichier effaçable, l'ordre " EFFACER FICHIER " peut être exécuté. Le résultat de cette opération est à nouveau - comme cela a été décrit précédemment - comparé, en cas d'exécution correcte, avec un résultat cible 16 formant le résultat prévu et délivré conformément. Ceci termine le test et le résultat du test peut différencier sans équivoque les deux scénarii: "Ordre correctement exécuté " et 0 " Système testé erroné ". Dans l'exemple précédent, au regard du résultat cible 16, la réponse donnée par le support testé au système de test s'est limitée au cas de test o, soit l'ordre testé est positif et donc exécutable, soit le système testé présente une erreur. Dans la pratique, en général, de possibles résultats cibles 16 supplémentaires peuvent être prévus avec S d' autres cas de test supplémentaires possibles. Dans l' exemple, un autre cas de test peut plus ou moins être constitué par le fait que pour des erreurs déterminces des conditions préalables " fichier effaçable existant ", il est dans un premier temps délivré un résultat cible 16 de ce contenu. Le test est alors tout d'abord réussi si après avoir déterminé la condition préalable manquante " fichier effaçable existant ", le résultat cible correspondant 16 était renvoyé. Lors de l'exécution du test, il serait judicieux de contrôler tout d'abord le cas de test nommé en dernier et de déterminer si le résultat cible 16 généré concorde avec celui prédéfini dans la structure 26 de données de résultats. Par la suite, le système de test se déroule comme décrit, avec la recherche d'un ordre approprié 12 fournissant la condition préalable à remplir 14. 2s L'évaluation du résultat de la totalité du test contenu au moyen de l'exécution de l'ordre à tester 10 s'effectue dans ce cas à partir des réponses fournies et / ou des résultats cibles 16 pour deux cas de test. D'une façon analogue, on peut prendre en compte des cas de tests supplémentaires et les résultats de test 16 correspondants et prendre pour base l'évaluation. Le logiciel testé est seulement considéré sans défaut si pour tous les cas de test le résultat cible prédéterminé a été fourni. Différents cas de test pour un ordre unique sont bien adaptés en tant que point de sortie pour l'exécution de la méthode de test. Le système de test cherche alors à générer les différentes constellations de conditions préalables correspondant aux cas de tests pour lesquels il peut être nécessaire d'exécuter un grand nombre d'ordres 3s supplémentaires 12 dans les différentes châînes. Afin de pouvoir exécuter la méthode de test automatiquement grâce à un système de test, les possibles constellations de conditions préalables sont déterminées pour chaque test possible à tester par l'ingénieur de test chargé de l'exécution de la méthode du test, ce qui signifie, que \\HIRSCH4\YOLl\DACTYLO\19500\19504.dx - 29 n=5 2002 -13/19 dans le cas, donné en exemple, portant sur le test d'un logiciel d'un support de données portable, les paramètres correspondants spécifiques dépendent, pour chaque ordre APDU, de son exécution. Les conditions préalables peuvent être des enregistrements de paramètres de commande ou des ordres, ou des états qui doivent êhe exécutés ou obtenus avant le cas de test spécifique. De plus, pour chaque exécution possible d'un ordre à tester dépendant de la constellation de conditions préalables et des paramètres de commandes indiqués, il est déterminé une réponse correspondante et / ou un résultat cible. Une constellation de conditions préalables et une réponse correspondante et / o ou un résultat cible forment à chaque fois un cas de test. Chaque ordre à tester peut se voir attribuer un ou plusieurs cas de test. Pour chaque cas de test les post-conditions résultant des conditions préalables et des réponses sont déterminés. Tous les cas de test possibles pour un ordre, avec les paramètres de commande et les constellations de conditions préalables ainsi que les post-conditions correspondantes sont, pour chaque ordre, reportés dans un tableau descriptif des ordres ou des opérations. Les tableaux descriptifs des opérations de tous les ordres sont, de prétérence, stockés dans une base de connaissances à laquelle le système de test exécutant la méthode de test a accès. S'il s'avère, lors de l'exploitation par le logiciel contrôlé d'un ordre à tester, que l' exécution d'un ordre n' est pas possible, parce qu'une condition préalable n'est pas remplie, le système de test recherche dans la base de connaissances tous les ordres pour savoir si la condition préalable peut être suspendue en complétant un autre ordre. 2s La figure 3 présente schématiquement et de manière simplifiée un extrait d'une base de connaissances 22 pour tester un logiciel d'un support de donnces portable. La base de connaissances 22 se compose d'un condensé des tableaux descriptifs des opérations et s'articule en une structure 24 de données des événements et en une structure 26 de donnces de résultats cibles. Elle est préalablement déterminée par la personne chargée de l'élaboration du script de test. La structure de données des événements 24 comprend pour tous les ordres 10 et / ou les commandements la structure d'ordres APDU 1S, transférée sur le support de donnces, avec les paramètres réglables 19, une détermination de la longueur et les différentes occupations possibles de variables ainsi que les constellations possibles 3s des conditions préalables 14. La structure 26 de données de résultats cibles contient, pour tous les cas de test possibles, les réponses pré-déterminées et / ou les résultats cibles ainsi que les post-conditions 17 obtenues pendant l'exécution correcte. Les colonnes 14, 16, 17 et 19 présentent généralement plus d'une entrée. \WRSCH4\VOLl\DACTYLON19500\19504.doc - 29 n 2002 - 14/19 La structure 24 de données des événements et la structure 26 de données de résultats cibles ne doivent impérativement pas être intogrces dans une base de connaissances 22 commune. I1 est également possible de les placer dans des dispositifs de stockage séparés. Si tous les ordres, avec toutes les combinaisons possibles de constellations de conditions préalables et les résultats cibles qui peuvent également présenter des variables sont systématiquement saisis dans la base de connaissances 22, il est possible d'exécuter un test complet d'un support de données mobile avec le test d'ordres, conforme à l'invention, dans lequel seul le contrôle d'un ordre unique est o déclenché. Si l'ordre 10 sélectionné pour être testé exige tout d'abord que les conditions préalables 14 qui ne sont pas remplies le soient, le système de test utilisé exécute, en mode récursif, en accédant à la base de connaissances 22, d'autres ordres 12, et ce jusqu'à ce que l'ordre 10 prescrit à l'origine soit, ou bien exécutable ou bien ne puisse pas être exécuté. Lors de la sélection des ordres à tester 10 appropriés, il est possible ainsi de contrôler un nombre élevé d'ordres et de cas de test sans que chaque différent commande à tester ne doive être préalablement déposé de façon explicite dans un script de test. Bien entendu la présente invention n'est pas limitée aux modes de réalisation décrits et représenté et elle englobe tous les modes de réalisation en variante aisément accessibles à l'homme de l'art. \\HIRSCH4\VOLIIDACl.YLO\19500\19504.doc - 29 nuis 2002 - IS/]9 REVENDICATIONS 1. Méthode pour tester un logiciel et / ou un support de données portable au moyen d'un système de test par contrôle de l'exécution d'au moins un ordre (10) par le logiciel et / ou au support de données portable, dans laquelle la possibilité d'exécution de l'ordre (10) nécessite que soit remplie au moins une condition préalable (14); la méthode se caractérisant par les étapes suivantes: - de transfert au logiciel d'un ordre à tester (10), 0 - de détermination des conditions préalables (14) nécessaires à l'exécution de l'ordre à tester (10), - de contrôle pour vérifier que les conditions préalables (14) sont remplies, - le cas échéant, remplir les conditions préalables (14) non remplies grâce au système de test, d'exécution par le logiciel de l'ordre à tester (10), - de détermination du résultat du test obtenu par l'exécution, - d'évaluation du résultat du test au moyen d'un résultat cible prédéterminé (16). 2. Méthode d'après la revendication 1, caractérisée en ce que les conditions préalables (14) sont remplies du fait qu'au moins un ordre supplémentaire (12) est émis et exécuté et qui fournit en tant que post-condition (17) une condition préalable (14) qui n'a pas été remplie dans un premier temps. 3. Méthode d'après la revendication 2, caractérisée en ce que l'ordre supplémentaire (12) est émis au moyen de la mise en _uvre d'une recherche dans une base de connaissances (22), et en ce que les conditions préalables (14) et les post-conditions (17) de l'ordre (10, 12) sont, pour chaque ordre (10, 12) déposées dans la base de connaissances (22). 4. Méthode d'après la revendication 2 ou 3, caractérisce en ce que la méthode est employée en mode récursifpour l'ordre supplémentaire (12). 5. Méthode d'après l'une quelcouque des précédentes revendications, caractérisée en ce qu'une suite d'ordres à tester (10) est testée au moyen d'une application itérative de la méthode. \\HIRSCH4\YOL I \DACTYLO\ I 9500\19504 doc - 29 ma 2002 - 16/ 19 6. Méthode d'après l'une quelcouque des précédentes revendications, caractérisce en ce que le résultat du test permet d'obtenir une différence non équivoque entre les cas 7. Méthode d'après l'une quelcouque des précédentes revendications, caractérisée en ce que la méthode affiche en plus la cause de l'impossibilité d'exécution en cas de résultat de test: " l'ordre n'est pas exécutable ". 8. Méthode d'après l'une quelconque des précédentes revendications, o caractérisée en ce que toutes les conditions préalables (14) sont remplies automatiquement. 9. Méthode d'après l'une quelconque des précédentes revendications, caractérisce en ce que les conditions préalables (14) sélectionnées manuellement et / ou les conditions préalables (14) sélectionnces en fonction de critères prédéfinis sont remplies automatiquement. 10. Méthode d'après l'une quelconque des précédentes revendications, caractérisée en ce que l'ordre à tester (10) est sélectionné, au moyen d'un générateur de nombres aléatoires, à partir d'un ensemble d'ordres possibles. 11. Méthode d'après l'une quelconque des revendications précédentes, caractérisoe en ce que l'évaluation de l'exécution de l'ordre à tester (10) est effectuée en se basant sur une structure de données de résultats (26) au moyen de laquelle le résultat déterminé du test est comparé avec un résultat cible déterminé (16) pour en vérifier la concordance. 12. Méthode d'après l'une quelconque des précédentes revendications, caractérisée en ce que les informations nécessaires pour le test de l'ordre à tester (10) , tout particulièrement les conditions préalables (14) à l'exécution de l'ordre à tester (10), sont automatiquement remplies du fait qu'au moins un ordre supplémentaire (12) est exécuté. 13. Système de test pour la mise en _uvre d'une méthode selon l'une quelconque des revendications 1 à 12, caractérisé par: - des moyens pour la détermination d'un ordre à tester (10), \\ESCH4\VOLl\DACTYLO\19500\19504.doc - 29 mam 2002 - 17/19 - un dispositif de " Command Tracking ", se composant au minimum d'un dispositif de détermination pour la détermination de(s) la condition(s) préalable(s) (14) pour un ordre à tester (10) et - des moyens pour remplir les conditions préalables (14) de l'ordre à tester (10), lesquels remplissent la condition(s) préalable(s) (14) au moins et en partie automatiquement grâce à l'exécution d'un ordre supplémentaire (12), dans le cas o l'ordre à tester ne peut pas étre exécuté. - des moyens pour l'exécution de l'ordre à tester (10), - une unité d'évaluation pour évaluer l'exécution de l'ordre à tester(10) ainsi o que des moyens pour diriger un résultat de test explicite, qui se trouve en échange de données avec l'unité d'évaluation.