Test automatisé: un exemple avec Wonderware Intouch et Modbus

Bonjour,

Pour illustrer l'article sur les architectures de test, voici un exemple pour tester une application réalisé avec un des SCADA leader sur le marché: Wonderware Intouch.

C'est aussi le moyen de vous faire découvrir 2 outils: HMI Test Kit et Modbus Test Kit. Tous les 2 sont écrits en Python, langage idéal pour la réalisation de scripts de test.

J'ai donc réalisé avec Intouch une application très simple qui lit 2 registres par une communication Modbus TCP et affiche la valeur ainsi qu'une animation dont la couleur change en fonction de la valeur lue. Si elle est supérieure à un seuil, la partie externe du synoptique clignote jusqu'à que l'utilisateur acquitte cette alarme en cliquant sur le rond. En absence d'alarme, cette partie est invisible. Le synoptique peut prendre 3 couleurs: vert, jaune et rouge indiquant à l'utilisateur un degré de vigilance. Cette application est bien entendu un peu simpliste mais elle est je pense suffisante pour présenter comment réaliser des tests automatisés. Le principe serait le même pour une application plus complexe.

Application Test Interface

Cette application présente 2 interfaces: l'IHM et sa connection avec un automate Modbus que nous allons essayer d'encapsuler par un ATI (Application Test Interface).

Le rôle de l'ATI est de fournit une couche d'abstraction de l'application à tester afin de faciliter l'écriture des tests et leur maintenance en cas de modification.

Il faut tout d'abord gérer l'automate et puisque nous sommes en test unitaire, nous allons le remplacer par un simulateur comme par exemple celui fourni avec Modbus Test Kit. Je vous propose de consulter mysimu.py dans les exemples fournis avec Modbus Test Kit (aussi disponible en ligne) puisqu'il correspond au simulateur dont nous avons besoin. Un registre contient la valeur et un autre passe à 1 si cette valeur dépasse un seuil fixé à l'avance.

Pour s'interfacer avec l'IHM, nous allons utiliser HMI Test Kit qui est adapté à un logiciel tel qu'Intouch. En effet, contrairement à une application Windows traditionnelle, il n'existe pas de moyen simple pour obtenir l'état d'un contrôle. Il n'existe pas de fonctions ou de librairies pour lire la valeur de ce qui est affiché. il faut donc ruser en utilisant la reconnaissance de couleurs et de caractères d'HMI Test Kit.

Pour encapsuler le comportement de notre IHM, on a besoin de 4 fonctions: la lecture du la valeur affichée, la détection de la couleur du rond, celle de la zone de clignotement, l'acquittement d'une alarme par un click de l'opérateur.

Oracle de test

Une fois que l'on possède les éléments nécessaires pour exécuter les actions sur l'application, il faut écrire la partie en charge de vérifier si l'application est bien dans l'état attendu une fois que ces actions ont été effectuées. C'est le rôle de l'oracle de test. Un oracle de test est le composant qui va détecter si le résultat obtenu par un test est correct ou non.
Pour cela, on soumet l'oracle aux mêmes actions que celles reçues par l'application. On implémente donc dans un 1er temps les fonctions pour simuler les actions: changement de valeur et acquittement de l'opérateur. Il faut ensuite coder les fonctions de vérification des résultats: la valeur affichée, de la couleur du rond et détection du clignotement.

La vérification des résultats peut être parfois difficile et nécessité le choix d'une méthode heuristique basée sur l'observation de certaines caractéristiques du résultat. Par exemple, dans ce cas, la détection du clignotement se fait par la détection de la couleur sur 10 captures prises à intervalles irréguliers. Le critère de validité pour vérifier le clignotement est d'avoir au moins 2 couleurs différentes dans les 10 captures. Ce critère ne garantit pas à 100% le résultat mais il apparaît suffisament sûr dans ce cas. Il induit un faible risque de détecter des fausses erreurs mais cela est acceptable face au risque de ne pas détecter cette même erreur: le but du test est de "chasser les bugs".

Le moteur de test

Une fois que l'on dispose de ces éléments, il faut donc écrire les tests en fonction de la stratégie que l'on a défini dans le plan de test. L'oracle a permis de définir comment détecter la validité d'un résultat, le moteur de test définit ce qui va être testé.

C'est la partie principale des tests qui consiste en l'écriture des cas de test. Si l'ATI et l'oracle sont bien définis, cette tâche est facilitée. C'est néanmoins une tâche très importante où l'expérience et la compétence du testeur sont très importants.

Il existe plusieurs méthodologies pour définir les tests à utiliser. Dans ce cas précis, une approche qui me paraît appropriée est celle du Model Based Testing qui consiste à modéliser les différents états de l'application et générer les tests automatiquement à partir de ce modèle. Cela sera le sujet d'un prochain article.

Voila, j'espère vous avoir fait découvrir de nouvelles possibilités pour les tests d'une application de type SCADA. J'ai choisi le progiciel Intouch pour cet exemple mais j'aurai pu choisir d'autres tel que Wizcon ou CoDeSys que je connais bien... Peut-être pour un prochain article. J'espère que les outils que sont HMI Test Kit et Modbus Test Kit vous permettront d'augmenter la portée de vos tests car sur des applications industrielles, c'est un enjeu essentiel.

Télécharger le script de test complet