FR 2806495 A1 20010921 FR 0003267 A 20000314 Procédé d'analyse d'un logiciel de test La présente invention a pour objet un procédé d'analyse d'un logiciel de test. Elle trouve plus particulièrement son utilisation dans le domaine des logiciels de tests mis en oeuvre par des appareils de test pour tester des composants électroniques, notamment pour évaluer les performances d'un logiciel utilisé comme outil de contrôle de la qualité de fabrication, de composants électroniques, des fabrications de composants étant généralement en grande séries. Dans l'état de la technique on ne connaît pas de procédé d'analyse de tels logiciels de test. L'intérêt de l'invention est de proposer un procédé d'analyse permettant d'organiser une maintenance d'un appareil de test, et d'exploiter des résultats fournis par ce procédé d'analyse, ainsi que ceux fournis par le logiciel de test, à des fins d'optimisation du logiciel. Dans l'état de la technique, on connaît un appareil de test mettant en oeuvre un programme de test du logiciel de test, tel que le programme de test comporte une succession d'instructions à effectuer, afin de tester un composant à tester. Cette succession d'instructions, ainsi que des critères d'acceptation vis à vis des résultats obtenus suite à la réalisation de ces instructions, sont stockés dans une mémoire de données de l'appareil de test. Un appareil de test comporte généralement un microprocesseur permettant d'échanger des informations avec la mémoire de données. D'autre part, le microprocesseur commande un multiplexeur de l'appareil test. Le multiplexeur permet d'associer à des broches de l'appareil de test des potentiels à appliquer à des points particuliers du composant électronique à tester. D'autre part il permet également d'identifier des potentiels émis par le composant dans les broches. Le microprocesseur enregistre les potentiels émis par chacune des broches, ce qui constitue des résultats du programme de test. Les résultats sont ensuite enregistrés dans une mémoire de mesures de l'appareil de test. Pour garantir une qualité des résultats fournis par un tel appareil de test, il faut assurer le bon fonctionnement de chacun des composants électroniques qui constituent l'appareil de test lui-même. Ainsi, dans l'état de la technique, on doit fréquemment réparer l'appareil de test. Par exemple, si un nombre important de composants à tester sont rejetés de manière consécutive, et ce pour un même motif, alors il faut arrêter l'appareil de test et entamer une recherche de panne au niveau des composants électriques qui le constitue. De même, dans un autre cas de figure, si l'appareil de test ne peut plus effectuer le programme de test en entier, alors il faut arrêter les tests effectués avec cet appareil, et entamer une recherche de panne. Or la recherche de panne est une opération fastidieuse dans l'état de la technique. En effet on recherche des pannes sur l'appareil de test selon un ordre logique qui est fonction d'une fréquence d'apparition des pannes pour chacun des composants constitutifs de l'appareil de test. Cet ordre de recherche de panne est établi de manière empirique, en fonction d'observations faites par des utilisateurs de l'appareil de test. Cette recherche de panne est réalisée indépendamment de la connaissance des instructions contenues dans le programme de test, et mettant en oeuvre les différents composants de l'appareil. Dans l'état de la technique, I'utilisation d'un appareil de test mettant en oeuvre un programme de test pose des problèmes. En effet, un tel appareil de test tombe fréquemment en panne, et ce de manière inopinée, ce qui peut être gênant lorsque la panne survient pendant une campagne de tests sur des lots de composants à tester. D'autre part, lorsque la machine de test est arrêtée pour cause de panne, la réparation de cette panne peut parfois être longue, dans la mesure o aucune méthode ne permet de trouver rapidement la cause de la panne et des moyens de la résoudre. En effet, la démarche empirique utilisée ne permet pas d'optimiser la résolution de ce type de problème. Par ailleurs, dans l'état de la technique, il n'existe pas de moyen de maintenance préventive, permettant de minimiser la survenue de pannes. En effet, on doit faire face, seulement le moment venu, au problème. Il n'y a pas de moyens de les éviter. L'invention a pour objet de remédier aux problèmes cités en proposant un procédé d'analyse d'un logiciel de tests, tel que le procédé d'analyse enregistre un nombre de réalisation d'une opération donnée d'un programme de tests du logiciel. Un logiciel de test peut comporter des programmes, tel que chaque programme est spécifique à un type de composant électronique donné. Un programme de test comporte des opérations, ou instructions à exécuter par le biais de l'appareil de test. On enregistre alors, pour chaque programme de test le nombre de réalisations de chacune des opérations. En outre, le procédé d'analyse évalue également le nombre de fois o un composant électronique de l'appareil de test est sollicité par l'un quelconque des programmes de test du logiciel de test. Ainsi, on peut déduire un classement des composants électroniques de l'appareil de test en fonction du nombre de fois o ils sont sollicités par le logiciel. Par ailleurs, on peut également connaître les opérations le plus fréquemment réalisées par chacun des programmes de tests. Selon le procédé de l'invention, on peut évaluer un taux d'usure de chacun des composants de l'appareil de test, et également prévoir l'évolution de ce taux d'usure pour chacun des composants lors d'un lancement d'une série de test sur une série de composants à tester. On peut ainsi prévoir un remplacement prématuré, voire une fréquence de remplacement de chacun de ces composants, de manière à éviter l'apparition de pannes. De plus, à partir de ces informations fournies par le procédé d'analyse on peut également prévoir une optimisation d'un agencement des opérations contenues dans chacun des programmes de test. Cette optimisation vise à réduire le nombre de réalisation des opérations les plus fréquentes. D'autre part, dans la mesure o l'on peut connaître, par le procédé d'analyse, une durée de réalisation de chaque opération, on va préférentiellement chercher à diminuer le nombre de réalisation des opérations les plus longues. La solution apportée par l'invention permet de réaliser une maintenance préventive sur l'appareil de test, et également d'optimiser le logiciel, voire les programmes de test mis en oeuvre par ce logiciel. L'invention concerne donc un procédé d'analyse d'un logiciel de tests caractérisé en ce qu'il comporte les étapes suivantes: - on utilise, dans un appareil de test, un programme de ce logiciel pour tester des composants électroniques; - on enregistre des nombres d'occurrence de réalisations d'opérations de test identiques du programme, et ou un taux de sollicitations des éléments constitutifs de l'appareil de test. L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci ne sont présentées qu'à titre indicatif et nullement limitatif de l'invention. Les figures montrent: - Figure 1: un schéma d'un procédé d'analyse d'un logiciel selon I'invention; - Figure 2: un schéma d'analyse de données selon le procédé d'analyse de l'invention. La figure 1 montre un appareil de test 1 pour tester un composant électronique 2. Le composant électronique 2 est par exemple une carte munie d'un microcircuit électronique, comme une carte à puce ou un composant mémoire. Généralement ce composant électronique 2 est présenté sur une plaque 3 appelée "wafer", tel q'un wafer 3 comporte généralement plusieurs composants électroniques tel que 2 à tester. Les composants d'un tel wafer 3 peuvent être tous identiques les uns aux autres, ou éventuellement différents. Dans un exemple préféré, un wafer 3 comporte des circuits intégrés tous identiques les uns aux autres. L'appareil de test 1 comporte un module 4 comportant des broches par exemple P1, P2, P3 et P4, pour venir au contact de points particuliers 5 du composant électronique 2 à tester. Le module 4 peut comporter une multitude de broches pour venir au contact d'une multitude de points particuliers du composant électronique 2. Les broches sont réparties selon une géométrie particulière qui permet de mettre en vis-à-vis, et de manière connue, chacune des broches avec chacune respectivement un point particulier du composant électronique 2 à tester. L'appareil de test 1 comporte également un microprocesseur 6 pour gérer des flux d'informations, tels que des bus de données, de commandes et d'adressages émis vers le module 4 et reçu de ce module 4. Le microprocesseur 6 appelle dans un logiciel 7 un programme de test 8. Le programme de test 8 appelé est fonction de la nature du composant à tester. Le logiciel 7 comporte plusieurs programmes de test tels que 8. Dans un exemple préféré, un opérateur peut piloter le microprocesseur 6 par le biais d'un clavier 11, et peut recevoir des informations émises par le microprocesseur 6 par le biais d'un écran 12. Par exemple, un utilisateur peut, à l'aide du clavier 11 imposer au microprocesseur 6 I'utilisation du programme 8, ou d'un autre programme 13 stocké dans le logiciel 7. D'autre part, cet utilisateur peut éventuellement voir s'afficher sur l'écran 12 des résultats de mesures demandées dans le programme 8, ou des résultats au procédé d'analyse du programme 8, voire éventuellement des résultats du procédé d'analyse du logiciel 7. Le programme 8 comporte plusieurs opérations, ou lignes d'instructions 14. Ces opérations 14 sont exécutées par l'intermédiaire du module 4. Les lignes d'instructions 14 sont repérées par des codes, par exemple Cl, C2, C3, C4, C5, C6, C7. Une même ligne d'instruction, ou opération, 14 peut être répétée plusieurs fois au sein d'un même programme. Par exemple, comme il est présenté à la figure 1, la ligne d'instruction dont le code est Cl est répétée une fois dans le programme 8, alors que la ligne d'instruction C2 est répétée quatre fois dans ce même programme 8. Dans un exemple, le programme 8 comporte essentiellement deux type d'instructions. D'une part des instructions de type "envois d'un potentiel", par exemple S/P1/Sl de code Cl, qui ont pour but d'alimenter la broche P1 avec une valeur Sl. D'autre part le programme 8 comporte des instructions de type "mesure", par exemple M P2, de code C2, qui a pour but de demander une mesure d'un potentiel de la broche P2. Le programme 8 est exécuté ligne après ligne par le microprocesseur 6. Dans le cas d'une ligne d'instruction du type S/P1/Sl, le microprocesseur 6 appelle, dans la mémoire de données 9, la valeur Sl. Dans le cas de la ligne d'instruction MP2, la mesure du potentiel de la broche P2 est stockée par le microprocesseur 1 dans la mémoire de mesure 10. Figure 2 dans un tableau Tab 1, pour chaque ligne d'instruction 14 distincte, identifiée par son code, on note dans une colonne 15 de ce tableau, un nombre d'occurrence de cette instruction 14 lors de la réalisation d'un programme de test sur un composant électronique 2. Etant donné que le logiciel 7 est utilisé pour tester plusieurs composants électroniques tel que 2, le tableau Tab1 comporte alors plusieurs colonnes telle que 15. Chaque colonne telle que 15 comporte le nombre d'occurrence de chaque instruction pour toutes les instructions proposées par le logiciel 7, à chaque nouvelle réalisation d'un programme tel que 8 ou 13 du logiciel 7. Dans un tel tableau, on peut également enregistrer dans une colonne 16 un nombre total d'occurrence pour chacune des instructions 14. Une colonne 16 peut correspondre à la somme des nombres d'occurrences, du 8 à un même programme. On a ainsi plusieurs colonnes telles que 16 dans le tableau Tab1, une par programme tel que 8 ou 13 proposé par le logiciel 7. On peut de plus obtenir un total, dans une colonne telle que 16, correspondant à un total du nombre d'occurrence d'une instruction dues à I'ensemble des programmes du logiciel 7, c'est-à-dire un total du nombre d'occurrences dues à chaque programme du logiciel 7 mettant en ceuvre cette instruction. De plus, on peut enregistrer dans une colonne 18 des valeurs statistiques calculées à partir de ces données chiffrées. Par exemple, on peut calculer un écart-type et/ou une variance de ces données. De la même manière que pour chaque instruction 14 dans le tableau Tab1, on peut réaliser un deuxième tableau Tab2 pour chacun des éléments constitutifs du module 4, notamment pour ceux mis en oeuvre par des programmes tels que 8 du logiciel 7. Le module 4 se décompose en éléments tels que les broches P1, P2, P3 et P4 et des microcircuits électroniques pour piloter chacune de ces broches. Le tableau Tab2 comporte donc une ligne pour chacune de ces éléments. Dans le tableau Tab2 on évalue un taux de sollicitation de chacun des éléments constitutifs du module 4. Ainsi selon l'exemple de la figure 1, on obtient que la broche P1 a été sollicitée une fois, alors que la broche P2 a été sollicitée cinq fois, lors de la réalisation du programme 8 pour tester un composant. Les taux de sollicitations sont alors stockés dans une colonne 17. Pour chaque réalisation d'un programme tel que 8, on enregistre dans une colonne telle que 17 les taux de sollicitations de composants mis en oeuvre. Un tel tableau Tab2 peut comporter plusieurs colonnes telles que 17, autant qu'il y a de réalisations de programmes du logiciel 7. On peut enregistrer, dans une colonne 18 pour chaque élément constitutif, les taux de sollicitation total, ce total faisant la somme des sollicitations dues à l'ensemble des programmes mis en ceuvre pour tester des composants. ** ou mis en oeuvre pendant une période donnée. Ainsi, on peut aussi estimer un total du taux de sollicitations dues au logiciel 7 de chacun des éléments constitutifs. Des analyses statistiques peuvent être réalisées sur les valeurs, par exemple on peut, pour chaque élément constitutif, évaluer un écart-type et/ou une variance, et/ou une moyenne dans une colonne telle que 18. On peut également évaluer dans un tableau tab 2, pour chaque composant, un taux de sollicitations subies depuis la mise en place dans l'appareil de test. Etant donné que tous les composants constitutifs d'un appareil de test ne sont pas renouvelés simultanément, on prévoit de remettre les compteurs à zéro de manière individuelle pour chacun des composants. Dans chacun des deux tableaux décrits précédemment, on peut déduire de ces informations, un moyen de classer les opérations d'un programme, ou d'un logiciel, en fonction d'un nombre d'occurrence de réalisation. On peut par exemple classer ces instructions, ou opérations, entre elles, notamment ce classement peut être par ordre décroissant en fonction de leur nombre d'occurrence total de réalisation. Ainsi avec un tel classement, on peut mettre en avant les instructions les plus fréquemment mises en oeuvre par un programme de test, ou de manière plus générale les plus fréquemment mises en oeuvre par le logiciel de test. De même, à partir du taux de sollicitation de chacun des éléments constitutifs de l'appareil de test, on peut déterminer un total du nombre de sollicitation de chacun de ces éléments. Le total pouvant être effectué soit pour un programme en particulier soit pour l'ensemble des programmes mis en oeuvre par le logiciel 7 de tests. Ainsi on peut savoir quels sont les éléments de l'appareil de test qui sont les plus sollicités par les programmes de test. On peut donc effectuer un classement parmi ces éléments constitutifs selon un ordre décroissant par rapport au nombre total de sollicitation. Ainsi ce classement, notamment celui par ordre décroissant selon le nombre total de sollicitation depuis la mise en place, permet de déterminer un ordre préférentiel de recherche de pannes. En effet, les éléments d'un appareil de test les plus sollicités sont les plus à risque en cas de panne, ils sont les plus fragilisés par l'ensemble des tests effectués, et donc ils sont en général les premiers à tomber en panne. La connaissance de cet ordre permet donc d'effectuer une recherche de panne simplifiée et plus rapide. D'autre part, on peut enregistrer sur ce même tableau, un nombre de pannes observées et identifiées pour chacun des éléments constitutifs. On note par exemple dans une colonne 19 du tableau Tab2 des nombres xl, x3 et x4 pour respectivement les éléments constitutifs P1, P3 et P4. Cette connaissance est empirique et est renseignée par un utilisateur de l'appareil de test. On connaît une durée de vie statistiques des composants. Ainsi, on peut corréler pour un élément de l'appareil de test, le nombre de pannes observées de manière empirique avec son taux de sollicitation depuis sa mise en place. En fonction d'une corrélation observée, en compilant des données obtenues sur plusieurs composants consécutifs, mis en place à un même endroit dans l'appareil de test, entre le taux de sollicitation et la nombre de panne on détermine une durée de vie théorique de cet élément dans l'appareil de test. Par ailleurs, étant donné que l'on connaît le nombre de sollicitations de ce composant par programme et par logiciel, on peut prévoir au bout de combien de temps, la durée de vie théorique, il faut changer cet élément constitutif. Pour améliorer la maintenance d'un appareil de test, préférentiellement, on détermine cette durée de vie théorique inférieure à la durée de vie statistique, de manière à ce que les pannes n'aient plus lieu. On réalise ainsi de la maintenance préventive. On peut prévoir dans un exemple de redéterminer la durée de vie théorique d'un composant à chaque fois que le nombre de pannes observées pour ce composant devient trop important. De même étant donné que l'on connaît à l'avance le type de campagnes de tests qui vont être mises en oeuvre sur l'appareil de test, on peut calculer le nombre prévisionnel de fois o chaque composant va être sollicité, c'est à dire que l'on peut calculer l'incrémentation du taux de sollicitation de chaque composant. On peut alors prévoir d'éventuellement changer un composant avant de lancer une campagne de tests sur un ensemble de composants à tester, pour éviter de devoir arrêter les tests au milieu de cet ensemble. D'autre part, pour chaque opération d'un programme de test, on peut également enregistrer dans une colonne 20 du tableau Tab1, la durée élémentaire observée à chaque fois que l'opération est mise en ceuvre. On a ainsi une colonne telle que 20 pour chaque réalisation de l'opération considérée. On peut ensuite effectuer des calculs statistiques, tels que des moyennes, à des écarts-type, avec ces valeurs. Les durées sont spécifiques à chacune des opérations de test. On peut de plus évaluer une durée totale de réalisation d'un programme de test. On peut effectuer le calcul pour chaque réalisation d'un programme de test sur un composant à tester. Ainsi on obtient autant de valeurs qu'il y a eu de composants testés. On peut calculer un total, une moyenne, un écart-type, ou d'autres valeurs statistiques à partir de ces durées totales de réalisation d'un test sur un composant à tester. De manière moins formelle, on peut prévoir simplement d'enregistrer des durées de séquences de test. Une séquence comporte alors plusieurs opérations de test successives. Pour améliorer le logiciel, on peut optimiser chaque programme en diminuant sa durée de réalisation d'un test sur un composant. Pour cela, on peut mettre en place deux axes principaux de recherche de diminution de la durée élémentaire d'un programme. Le premier axe consiste à chercher à diminuer le nombre des opérations étant identifiées comme étant les plus longues, selon le tableau Tabl. Un deuxième axe de recherche de diminution peut être de chercher à diminuer les opérations les plus fréquemment mis en oeuvre, également selon les données de Tab1. En effet on peut penser qu'une opération souvent mise en oeuvre peut être utilisée pour différentes fonctions de tests, et alors n'être réalisée qu'une seule fois. Il faut alors pouvoir utiliser des résultats obtenus par cette opération pour plusieurs tests distincts. REVENDICATIONS 1 - Procédé d'analyse d'un logiciel de tests (7) caractérisé en ce qu'il comporte les étapes suivantes: - on utilise, dans un appareil de test (1), un programme (8) de ce logiciel pour tester des composants électroniques (2), - on enregistre des nombres (15, 16) d'occurrence de réalisations d'opérations (14) identiques du programme, et ou un taux de sollicitations (17) des éléments constitutifs de l'appareil de test. 2 - Procédé selon la revendication 1 caractérisé en ce que - on classe les opérations de test en fonction d'un nombre d'occurrence statistique de réalisations, et ou - on classe les éléments constitutifs en fonction d'un taux statistique de sollicitations. 3 - Procédé selon l'une des revendications 1 à 2 caractérisé en ce que - on détermine un classement des éléments constitutifs de l'appareil de test en fonction de leur taux de sollicitation, pour déterminer un ordre de recherche optimisé à mettre en oeuvre en cas d'une panne de cet appareil. 4 - Procédé selon l'une des revendications 1 à 3 caractérisée en ce que - on enregistre un nombre (19) d'occurrence de panne pour chacun des éléments constitutifs de l'appareil de test, - on détermine une durée de vie statistique de ces éléments constitutifs, en corrélant pour chacun des éléments le taux de sollicitations et le nombre d'occurrence de pannes. - Procédé selon la revendication 4 caractérisé en ce que - on change de manière préventive les éléments constitutifs de l'appareil de test à une fréquence inférieure à leur durée de vie statistique. 6 - Procédé selon l'une des revendications 1 à 5 caractérisé en ce que - on enregistre des durées de réalisation de séquences du programme de test, - on optimise le logiciel en diminuant une durée de réalisation d'un programme de test sur un composant électronique, une diminution de cette durée étant obtenue en diminuant le nombre de réalisation des séquences les plus longues, et en diminuant le nombre d'occurrence de réalisations des opérations les plus fréquentes.