FR 3101165 A1 20210326 FR 1910483 A 20190923 Procédé d’enregistrement de séquences de commande et de contrôle d’un robot de test, logiciel pour mise en œuvre de ce procédé Procédé d’enregistrement d’une séquence de test pour tester un appareil/équipement, la séquence de test comprenant une ou plusieurs actions de contrôle ou de commande destinées à contrôler ou commander un robot (1) configuré pour tester l’appareil/équipement, le robot pouvant notamment être un banc de test automatisé, le procédé exécutant un logiciel (102) de pilotage du robot sur un dispositif (100), tel qu’un ordinateur, comportant un processeur, une mémoire et un écran, le procédé comprenant les étapes suivantes : a) sélection par un utilisateur, à partir d’une interface graphique (104), d’une action de contrôle ou de commande du robot ; b) caractérisation de l’action sélectionnée par l’utilisateur, à partir de l’interface graphique ; c) réitération des étapes a) et b) autant de fois que souhaité par l’utilisateur pour obtenir une séquence de test ; d) enregistrement par l’utilisateur de la séquence de test obtenue selon l’étape c). Figure pour l’abrégé : Fig. 3 Procédé d’enregistrement de séquences de commande et de contrôle d’un robot de test, logiciel pour mise en œuvre de ce procédé La présente invention concerne le domaine des logiciels d’enregistrement de séquences de pilotage et de contrôle de robots, en particulier de bancs de test automatisés d’appareils/d’équipements. Il peut notamment s’agir de bancs de test automatisés, non intrusifs, destinés à réaliser des tests mécaniques et/ou logiciels et/ou visuels et/ou sonores d’interface homme-machine d’un appareil ou équipement, tel qu’un équipement électronique muni d’une interface homme-machine comprenant un écran et un clavier, ces derniers pouvant être confondus dans le cas d’un écran tactile. Parmi les appareils et équipements pouvant être soumis à un banc de test automatisé tel qu’envisagé dans le cadre de l’invention, on peut citer les smartphones, les indicateurs de pesage, les terminaux de paiement, les tableaux de bord ou sous-ensembles de tableaux de bords, ou encore les instruments portables. La présente invention vise plus précisément à permettre de créer et d’enregistrer différentes séquences de pilotage d’un banc de test comprenant une ou plusieurs étapes de tests, et à piloter le banc de test pour mettre en œuvre les séquences de pilotage enregistrées. On peut classer en différentes catégories les solutions de test automatisées d’interface homme-machine d’appareils/équipements qui existent à ce jour. Les tests qui doivent être mis en œuvre sont des tests fonctionnel ou d’endurance mettant en œuvre le clavier et/ou l’écran et/ou l’application logicielle standard de l’appareil/équipement avec l’environnement extérieur. La première catégorie concerne des bancs à automatismes dédiés spécifiquement aux tests. Ainsi, un développement mécanique et logiciel est fait spécifiquement pour chaque nouveau type d’appareil/équipement que l’on souhaite tester. On perçoit immédiatement l’inconvénient majeur de cette solution : pour chaque nouvel équipement ou évolution de l’équipement, un nouveau développement doit être réalisé. Des logiciels permettent de faciliter ce développement, mais ils restent destinés à un public confidentiel d’informaticiens. On peut citer ici le logiciel de dénomination commerciale « LabView ». Des tests intrusifs ont également été mis en œuvre, comme décrit dans la demande de brevet EP0084454. Ici, un logiciel dédié, dont les fonctions sont de retrouver des informations sur les affichages en cours et également de simuler un appui touche sur un clavier de l’appareil/équipement à tester, est chargé dans ce dernier. Dans ce cas, le test peut être automatisé sans mise en œuvre de moyens mécaniques extérieurs. Outre le fait que l’appareil/équipement est chargé avec un logiciel supplémentaire, ces tests intrusifs ont pour inconvénient majeur d’introduire des conditions de test qui ne sont pas identiques aux conditions d’exploitation de l’équipement. Des logiciels de tests spécifiquement dédiés aux interfaces homme-machine ont été développés. Ces logiciels se limitent au test d’applications à utiliser sur le web, et sont rarement utilisables pour des logiciels embarqués. Ces logiciels peuvent être considérés comme intrusifs car ils ne sont pas nécessaires à l’exploitation de l’appareil/équipement. On pourra se référer au logiciel « Selenium », qui est un « framework » de test informatique développé en Java. Enfin, il existe des fonctions de tests de claviers ou d’écrans. Ces fonctions permettent de réaliser le test physique mais se limitent à un clavier ou à un écran. La combinaison écran et clavier est utilisée pour le test d’un des sous-ensembles, comme divulgué dans les demandes de brevet EP2405356 et EP0175765. Ces solutions ne mettent pas en œuvre l’application d’exploitation de l’appareil/équipement mais une application dédiée, et peuvent donc à ce titre être considérés comme intrusifs. Aussi, afin de pallier les inconvénients précités, la demande de brevet déposée sous le numéro FR 1858627 divulgue un banc de test automatisé, non intrusif, configuré pour réaliser des tests mécaniques et/ou logiciels et/ou sonores d’interfaces homme-machine d’un appareil/équipement à tester. Un banc de test tel que décrit dans cette demande est représenté en figures 1 et 2. La figure 1 est une vue en perspective avec transparence d’un exemple de banc de test automatisé selon la demande FR 1858627, désigné par la référence 1. La figure 2 illustre en vue de côté le banc de test 1. Le banc de test 1 est constitué d’un module avec un bâti 10 assemblé de pluralité de profilés 11 et qui est muni de pieds 12. Une unité centrale 2, une enceinte 3, un coffret électrique de commande 4 de l’unité centrale et une connectique extérieure 5, de préférence une connectique d’alimentation en 220V et/ou une connectique de type Ethernet sont fixés au bâti. Le fond de l’enceinte 3 comprend un support 6 qui permet de maintenir l’appareil à tester dans une position fixe de référence, pendant des séquences de tests. Une autre connectique d’alimentation 7 qui peut alimenter l’appareil/équipement à tester et être pilotée est agencée à proximité du support 6. L’enceinte 3 comprend une pluralité de parois transparentes 30 dont une peut s’ouvrir et constitue pour un opérateur, un accès sécurisé au support 6 depuis l’extérieur. Pour faciliter l’accès, la paroi d’accès 30 est munie d’une poignée P. Des moyens électroniques 31 permettant la coupure des alimentations de puissance et le cas échéant le verrouillage/déverrouillage de la porte d’accès sont prévus. En outre, un bouton d’urgence 32 fixé sur le bâti 10 à proximité de la porte d’accès permet à un opérateur d’interrompre tout test en cas d’urgence. Un portique à trois axes (X, Y, Z) 8 est fixé à l’intérieur de l’enceinte 3. Un palpeur 9 est fixé au portique 8 qui peut donc déplacer en translation le palpeur 9 selon chacun des trois axes X, Y et Z. Le palpeur 9 peut donc venir en contact à souhait avec n’importe quelle zone de l’appareil pendant le(s) test(s), chaque zone de contact constituant une interface (IHM) d’acquisition. Une caméra 13 est également fixée au portique 8. Cette caméra permet la prise d’images et/ou de vidéos de l’appareil/équipement, plus particulièrement de la ou des interfaces (IHM) de restitution visuelle de l’appareil/équipement, pendant le(s) test(s). Pour maitriser les conditions d’éclairage à l’intérieur de l’enceinte et donc augmenter la qualité des prises d’image et/ou de la vidéo de la caméra 13, des moyens d’éclairage 14 du support de l’appareil/équipement sont fixés au bâti 10. L’unité centrale 2 peut piloter l’allumage, l’extinction et le cas échéant le réglage de l’intensité du faisceau F des moyens d’éclairage 14 lors de la ou des séquence(s) de test(s) de l’appareil/équipement. Un microphone 15 est fixé à l’intérieur de l’enceinte 3. Ce microphone 15 est adapté pour capter les sons émis par au moins une interface de restitution sonore de l’appareil/équipement, pendant le(s) test(s). Le fonctionnement du banc de test 1 qui vient d’être décrit va maintenant être brièvement expliqué. L’opérateur vient positionner et le cas échéant fixer l’appareil/équipement à tester sur le support 6. Puis, il branche une alimentation de l’appareil/équipement à tester sur la prise d’alimentation 7 que l’unité centrale 2 peut piloter. L’opérateur ferme alors la porte d’accès 30 de l’enceinte 3 qui est verrouillée par les moyens ad’hoc 31. Une séquence de test de l’appareil/équipement peut alors être initiée. Un logiciel de contrôle-commande chargé dans l’unité centrale 2 a déjà récupéré ou récupère la liste des tests à exécuter dans un langage dédié. Le logiciel pilote et synchronise alors tout ou partie des composants internes à l’enceinte 3 selon une séquence de test prédéfinie: le portique 8 à trois axes et donc le palpeur 9, la caméra 13 et le cas échéant les moyens d’éclairage 14, le microphone 15, et le cas échéant la prise d’alimentation électrique. Le logiciel récupère alors les informations fonctionnelles de l’appareil/équipement testé. En particulier, le logiciel peut effectuer un traitement d’images issues de la caméra 13 de préférence, avec de la reconnaissance de caractère OCR, 7 segments, 16 segments, et/ou de la reconnaissance de couleur, et/ou de la reconnaissance de forme, et/ou de la reconnaissance d’icônes. En outre, le logiciel peut effectuer un traitement des sons émis par l’appareil/équipement testé, afin de distinguer les opérations issues des IHM. Au final, le logiciel permet de remonter les résultats et les traces des tests exécutés dans un format dédié, qui peuvent enregistrer dans un ou plusieurs fichiers dans l’unité centrale 2 ou dans un support d’enregistrement extérieur via la connectique extérieure 5. En plus des fonctions décrites, on peut implanter d’autres fonctions de test au banc 1 selon l’invention, et ce en fonction du type d’appareil/équipement à tester. Ainsi, par exemple, si ce dernier est un terminal de paiement électronique, on peut implanter à l’intérieur de l’enceinte 3, des moyens d’insertion mécanique d’une carte de paiement électronique à l’intérieur du terminal. Cependant, les méthodes existantes pour définir la ou les séquences de test à exécuter par le logiciel de contrôle-commande de l’unité centrale, en général à l’aide d’un langage informatique dédié, ne donnent pas entière satisfaction. Il est par exemple connu de définir les étapes successives d’une séquence de test en écrivant un ensemble de lignes de commande. Cela représente une opération longue et relativement complexe à mettre en œuvre, nécessitant des connaissances plus ou moins avancées dans le domaine informatique. Il existe des logiciels de définition de séquences de pilotage permettant de simplifier l’écriture des lignes de commande, mais cela reste destiné à un public ayant des connaissances avancées en informatique. Il est par ailleurs connu d’enregistrer une séquence de test par déplacement d’un robot : bien que cela limite le besoin de recourir à l’écriture de lignes de commande, cela reste une méthode peu pratique et lente à mettre en œuvre en particulier pour des séquences de test. La demande WO 2018/062156 A1 divulgue un robot destiné à déplacer une galette de matériau semi-conducteur à l’aide d’un bras de robot, un dispositif de contrôle du robot ainsi qu’un procédé d’apprentissage de la position du robot. Le procédé d’apprentissage repose sur la comparaison d’informations visuelles obtenues par une caméra avec un substrat virtuel : lorsque les deux coïncident, la position du bras du robot est enregistrée. La demande WO 2011/065035 A1 porte sur un procédé de génération de données d’apprentissage pour un robot comportant un bras de robot, ainsi qu’un dispositif d’apprentissage basé sur les mouvements dans l’espace d’un opérateur. Le procédé d’apprentissage requiert l’intervention d’une personne humaine. La demande EP 1710649 A2 divulgue un dispositif de contrôle de mouvement qui permet d’apprendre à un robot à se positionner. La demande décrit également un dispositif d’apprentissage de la position du robot, un procédé d’apprentissage de la position du robot et un logiciel pour l’apprentissage de la position du robot. Par conséquent, il existe un besoin pour proposer une solution de génération de séquences de test qui soit rapide, simple d’utilisation et qui ne nécessite pas la mise en place d’un environnement matériel spécifique. Le but de l’invention est de répondre au moins partiellement à ce besoin. Pour ce faire, l’invention concerne un procédé d’enregistrement d’une séquence de test pour tester un appareil/équipement, la séquence de test comprenant une ou plusieurs actions de contrôle ou de commande destinées à contrôler ou commander un robot configuré pour tester l’appareil/équipement, le robot pouvant notamment être un banc de test automatisé, le procédé exécutant un logiciel de pilotage du robot sur un dispositif, tel qu’un ordinateur, comportant un processeur, une mémoire et un écran, le procédé comprenant les étapes suivantes : a) sélection par un utilisateur, à partir d’une interface graphique, d’une action de contrôle ou de commande du robot ; b) caractérisation par un ou plusieurs paramètres de l’action sélectionnée par l’utilisateur, à partir de l’interface graphique ; c) réitération des étapes a) et b) autant de fois que souhaité par l’utilisateur pour obtenir une séquence de test ; d) enregistrement par l’utilisateur de la séquence de test obtenue selon l’étape c). Ainsi, l’invention consiste essentiellement en la mise en œuvre d’un procédé permettant à un utilisateur de sélectionner et de caractériser à partir d’une interface graphique, de manière simple et intuitive, un ensemble d’étapes formant une séquence de test d’un robot de test. Le procédé selon l’invention permet de sélectionner, de caractériser et d’enregistrer une suite d’actions physiques et/ou logiques à effectuer sur l’équipement sous test. Cette suite d’actions forme une séquence de test qui peut être exécutée directement par le robot sur l’équipement sous test en un mode non intrusif : aucune adaptation mécanique, électronique ou logicielle n’est à prévoir pour l’équipement sous test. Selon un mode de réalisation avantageux, la séquence de test obtenue comporte au moins une action d’appui sur l’appareil/équipement à tester, l’action d’appui étant sélectionnée parmi un appui simple sur l’appareil/équipement, une suite d’appuis sur l’appareil/équipement ou un mouvement de glissement sur l’appareil/équipement. De préférence, l’interface graphique comprend une interface de visualisation adaptée pour permettre à l’utilisateur de visualiser l’appareil/équipement sous test. De manière avantageuse, la caractérisation de l’action d’appui est faite en interaction avec l’interface de visualisation. Selon une caractéristique avantageuse, la séquence de test obtenue comporte au moins une action de contrôle visuel, l’action de contrôle visuel consistant en la recherche sur un écran de l’appareil/équipement d’un élément défini par l’utilisateur, tel qu’un texte, une icône ou une couleur. Avantageusement, l’action de contrôle visuel est suivie par une action d’appui sur l’élément défini par l’utilisateur. Selon un mode de réalisation avantageux, la séquence de test obtenue comporte au moins une action de contrôle sonore sélectionnée parmi une détection d’un dépassement d’un niveau sonore prédéfini, une détection d’un son choisi par l’utilisateur. Selon une variante de réalisation, la séquence de test obtenue comporte au moins une action de contrôle-commande d’entrées-sorties du dispositif sélectionnée parmi un paramétrage d’une ou plusieurs valeurs de sortie du dispositif, une comparaison des valeurs d’une ou plusieurs valeurs d’entrée du dispositif. Selon une caractéristique avantageuse, le procédé comporte en outre l’étape suivante : e) modification par l’utilisateur des paramètres des actions et/ou de l’ordre des actions de la séquence de test obtenue selon l’étape c). De manière avantageuse, le procédé comporte en outre l’étape suivante : f) exécution par l’utilisateur de manière partielle ou totale de la séquence de test. L’invention concerne également un produit programme d’ordinateur comportant un support et, enregistrées sur ce support, des instructions lisibles par un processeur pour que, lorsqu’exécutées, elles permettent de : - générer une interface graphique sur le dispositif ; - visualiser un appareil/équipement sous test ; - visualiser ou écouter un enregistrement sonore de l’appareil/équipement sous test ; - piloter les entrées/sorties du robot ; - mettre en œuvre le procédé d’enregistrement selon l’invention. La figure 1 représente une vue en perspective d’un banc de test automatisé selon l’état de l’art. La figure 2 illustre en vue de côté le banc de test selon la figure 1. La figure 3 représente de manière schématique un ordinateur exécutant un logiciel selon l’invention et connecté à un banc de test selon la figure 1. Procédé d’enregistrement d’une séquence de test pour tester un appareil/équipement, la séquence de test comprenant une ou plusieurs actions de contrôle ou de commande destinées à contrôler ou commander un robot (1) configuré pour tester l’appareil/équipement, le robot pouvant notamment être un banc de test automatisé, le procédé exécutant un logiciel (102) de pilotage du robot sur un dispositif (100), tel qu’un ordinateur, comportant un processeur, une mémoire et un écran, le procédé comprenant les étapes suivantes : sélection par un utilisateur, à partir d’une interface graphique (104), d’une action de contrôle ou de commande du robot ; caractérisation par un ou plusieurs paramètres de l’action sélectionnée par l’utilisateur, à partir de l’interface graphique; réitération des étapes a) et b) autant de fois que souhaité par l’utilisateur pour obtenir une séquence de test ; enregistrement par l’utilisateur de la séquence de test obtenue selon l’étape c). Procédé d’enregistrement selon la revendication 1, la séquence de test obtenue comportant au moins une action d’appui sur l’appareil/équipement à tester, l’action d’appui étant sélectionnée parmi un appui simple sur l’appareil/équipement, une suite d’appuis sur l’appareil/équipement ou un mouvement de glissement sur l’appareil/équipement. Procédé d’enregistrement selon l’une des revendications 1 ou 2, l’interface graphique (104) comprenant une interface de visualisation (106) adaptée pour permettre à l’utilisateur de visualiser l’appareil/équipement sous test. Procédé d’enregistrement selon les revendications 2 et 3, la caractérisation de l’action d’appui étant faite en interaction avec l’interface de visualisation (106). Procédé d’enregistrement selon l’une des revendications précédentes, la séquence de test obtenue comportant au moins une action de contrôle visuel, l’action de contrôle visuel consistant en la recherche sur un écran de l’appareil/équipement d’un élément défini par l’utilisateur, tel qu’un texte, une icône ou une couleur. Procédé d’enregistrement selon la revendication 5, l’action de contrôle visuel étant suivie par une action d’appui sur l’élément défini par l’utilisateur. Procédé d’enregistrement selon l’une des revendications précédentes, la séquence de test obtenue comportant au moins une action de contrôle sonore sélectionnée parmi une détection d’un dépassement d’un niveau sonore prédéfini, une détection d’un son choisi par l’utilisateur. Procédé d’enregistrement selon l’une des revendications précédentes, la séquence de test obtenue comportant au moins une action de contrôle-commande d’entrées-sorties du dispositif (100) sélectionnée parmi un paramétrage d’une ou plusieurs valeurs de sortie du dispositif, une comparaison des valeurs d’une ou plusieurs valeurs d’entrée du dispositif. Procédé selon l’une des revendications précédentes, comportant en outre l’étape suivante : e) modification par l’utilisateur des paramètres des actions et/ou de l’ordre des actions de la séquence de test obtenue selon l’étape c). Procédé selon l’une des revendications précédentes, comportant en outre l’étape suivante : f) exécution par l’utilisateur de manière partielle ou totale de la séquence de test. Produit programme d’ordinateur (102) comportant un support et, enregistrées sur ce support, des instructions lisibles par un processeur pour que, lorsqu’exécutées, elles permettent de : générer une interface graphique (104) sur le dispositif (100) ; visualiser un appareil/équipement sous test ; visualiser ou écouter un enregistrement sonore de l’appareil/équipement sous test ; piloter les entrées/sorties du robot ; mettre en œuvre le procédé d’enregistrement selon les revendications 1 à 10.