Avant d’être mis sur le marché ou lors d’une maintenance, les équipements avec une interface homme-machine (IHM) sont testés fonctionnellement afin d’assurer une utilisation optimale au client final.
Régulièrement, les industries ont recours à des tests intrusifs pour tester les logiciels présents dans leurs produits.
Cette méthode de test nécessite l’ajout de code dans les applications afin de vérifier le bon fonctionnement du logiciel.
Celle-ci peut rapidement devenir chronophage et coûteuse puisqu’elle peut nécessiter de développer du code exclusivement dédié au test.
Elle ajoute des séquences d’exécution dédiées au test qui ne se retrouveront pas dans le produit final. En un mot cette méthode ne teste pas le produit qui sera effectivement retrouvé en exploitation sur le terrain.
La méthode non intrusive peut donc être un excellent complément.
Focus sur la force du test non intrusif pour les interfaces homme-machine.
Votre produit est-il une interface homme-machine ?
Une interface homme-machine (IHM) est définie comme un ensemble écran, clavier, voyant, bouton permettant à un utilisateur, une personne physique, de se connecter et d’interagir avec un système, un appareil ou une machine.
Pour exemple, vous croisez quotidiennement plus d’une dizaine d’interfaces homme-machine : smartphone, ordinateur portable, PC, tableau de bord de voiture, robot de cuisine, panneau de commande de chauffage, terminal de paiement…
Pourquoi tester votre produit au travers de son IHM ?
Le test de votre produit au travers de son interface homme-machine est indispensable avant sa mise sur le marché mais également en cas de maintenance, de SAV ou de reconditionnement du produit.
Réaliser des tests fonctionnels permet de garantir la qualité et la fiabilité de vos produits à la sortie d’usine.
Vous augmentez la confiance que vous avez dans vos produits et vous offrez aux utilisateurs la meilleure expérience d’utilisation possible.
Le test intrusif
Le test intrusif consiste à ajouter du code directement dans le logiciel pour le tester. Celui-ci s’exécute donc simultanément avec le programme à tester.
Quelques exemples de code ajouté :
Pour les IHM
Le code se substitue à une interface homme-machine en utilisant des fonctions simulant l’opérateur.
Exemple d’une page web : Développement de code de test permettant de réaliser des clics, slides, sélections, etc… Ce n’est pas un opérateur qui utilise la page mais un logiciel qui simule le comportement de celui-ci. Dans ce cas, nous sommes intrusifs car l’opérateur est remplacé par du logiciel. Ce logiciel de simulation ne sera pas livré dans la version terrain.
Pour les environnements d’exploitation
Le code intrusif permet de mettre des points de test dans le logiciel afin de lire des données d’exécution ou de débogage.
Exemple d’un thermostat : Il peut être intéressant de savoir dans quel mode le thermostat est en train de travailler, ou bien la température qu’il y avait il y a 5 minutes.
En boîte noire le thermostat ne peut pas renvoyer ces informations, nous ne pouvons pas obtenir ces résultats. Il est nécessaire de développer des points de test, des bouts de logiciels qui vont nous permettre de récupérer ces données structurées. Nous commençons ici à être intrusif car on ajoute du code pour faire du test.
Exemple le développement d’un interpréteur de commandes : Nous développons des fonctions dans le produit qui vont permettre de recevoir des commandes, d’exécuter ces commandes et d’analyser les résultats. Nous sommes intrusifs. Nous avons ajouté du code dans le produit que l’on veut tester. Pour la version terrain, cet interpréteur de commandes sera retiré. Cela peut être un risque pour le produit final qui n’utilisera pas le code qui a été testé.
Il existe beaucoup d’autres raisons d’ajouter du code pour réaliser du test. Nous ne pouvons pas en établir une liste exhaustive.
Cette solution ne couvre pas toutes les combinaisons possibles et coûte cher puisqu’il peut être nécessaire de redévelopper le code intrusif à chaque nouvelle version.
Pour les IHM grand public (pc, smartphones) avec des distributions parfaitement connues comme Linux, Windows, ou pour les navigateurs Web, il existe des outils qui permettent de simuler des comportements d’opérateurs. Le test en mode simulé pour ce type d’équipements fonctionne très bien. La méthode est intrusive mais ça n’est pas un problème car le test ne porte généralement pas sur le temps réel. Ces outils font partie des distributions officielles et sont tellement utilisés qu’ils pourraient être considérés comme non intrusifs (Appium, Selenium…)
Pour les produits industriels, développés en spécifique, sur des systèmes d’exploitation temps réel ou propriétaire, on ne trouve généralement pas de solution de test intrusif du commerce. Le développeur devra alors développer ses propres outils intrusifs, ce qui peut être long et fastidieux, il pourra également s’appuyer sur des solutions non intrusives telles que décrites à la suite.
Le test non intrusif
Le test non intrusif consiste à tester un équipement en jouant une expérience utilisateur sans avoir apporté quelconque modification logicielle ou matérielle au produit à tester.
Pour les IHM
L’équipement est testé avec le toucher, la vue, et l’ouïe comme s’il s’agissait d’une personne physique. Cette méthode ne vient pas ajouter du code pour vérifier le logiciel. Nous n’entrons pas dans le logiciel du produit à tester.
Pour l’environnement d’exploitation du produit
Avec un simulateur on va être capable de le solliciter le produit à tester en lui envoyant des stimuli qui peuvent être des valeurs analogiques, des valeurs numériques, des flux, du réseau, etc.
Nous analysons les retours d’exécution pour voir si le produit en boîte noire fonctionne parfaitement. Ici le mode est non intrusif car le logiciel que l’on teste est bien le logiciel terrain.
Certains outils de test se présentent comme non intrusifs pour le test des IHM en utilisant les fonctions d’écran déportées disponible pour des distributions standards. Cette approche est effectivement très peu intrusive même si elle peut influer sur le temps réel du produit. Dans tous les cas elles ne remplacent pas un test utilisant les interfaces d’exploitation du produit final.
Face à ce constat, nous avons développé une solution de test non intrusive pour les IHM.
Pourquoi privilégier le test non intrusif
- L’équipement est testé en conditions réelles.
- Pas de risque d’endommager le système par des ajouts matériels ou logiciels.
- Respect du temps réel du produit (temps de réaction).
- Pas de développement d’outillages spécifiques au test.
Découvrez eTASQ Motion, le premier robot testeur non-intrusif
Passionnés par la qualité et l’innovation et spécialiste de l’informatique industrielle et embarquée nous avons développé eTASQ Motion.
eTASQ Motion est une solution unique au monde.
Grâce au toucher, à la reconnaissance optique et à l’écoute des sons vous pouvez tester fonctionnellement et de manière non-intrusive vos IHM les plus complexes.
La valeur ajoutée du robot : mettre en œuvre le produit dans son contexte terrain de manière non-intrusive. Il se mets en lieu et place d’un opérateur qui utiliserait l’IHM et rédigerai un compte rendu de ce qu’il se passe au niveau des équipements que l’on va solliciter.
Ce robot made in France permettra également une montée en compétences de vos opérateurs. Grâce à lui fini les tests fonctionnels réalisés manuellement, eTASQ Motion automatise cette étape du processus. Vous mobilisez vos équipes sur des tâches à plus forte valeur ajoutée.
Vous souhaitez tester votre IHM ?
