Bonnes pratiques de développement de l’interface utilisateur TestStand

TestStand est conçu à l’aide d’une architecture modulaire, utilisant des composants distincts qui ont chacun un seul objectif, ce qui facilite le développement et la maintenance de l’ensemble du système.

L’interface utilisateur est un composant distinct de l’architecture modulaire TestStand

Le composant d’interface utilisateur permet aux développeurs et aux opérateurs de test de créer et d’exécuter les séquences dans un système de test. Dans une architecture modulaire, une frontière claire doit exister entre l’interface utilisateur et l’application TestStand sous-jacente. Elle présente les avantages suivants :

• Interagir de manière transparente avec un système de test en utilisant plusieurs interfaces utilisateur différentes.  Par exemple, un développeur de test peut utiliser l’éditeur de séquence pour développer des séquences, tandis qu’un opérateur de test utilise une interface opérateur pour exécuter des tests et afficher les résultats.
• Modifier l’interface utilisateur sans risquer de modifier le comportement du test lui-même.

Les interfaces utilisateur TestStand communiquent avec l’API du moteur TestStand pour exécuter leurs diverses fonctions, telles que l’obtention de l’état des exécutions de test, la création et la modification de séquences et la configuration des paramètres. TestStand fournit également un ensemble de contrôles d’interface utilisateur et une API d’interface utilisateur distincte qui vous permet de créer rapidement vos propres interfaces utilisateur TestStand.

Commandes de l’interface utilisateur (UI) de TestStand

Les commandes de l’interface utilisateur (UI) TestStand sont un ensemble de commandes ActiveX qui implémentent les fonctionnalités communes dont les applications ont besoin pour afficher, exécuter et déboguer des séquences de test. Ces commandes ActiveX réduisent considérablement la quantité de code source dont une interface utilisateur a besoin pour interagir avec l’API TestStand pour gérer les tâches de l’interface utilisateur. Vous pouvez utiliser les pages de propriétés ou appeler les propriétés et les méthodes disponibles pour configurer ces contrôles. Reportez-vous à la rubrique d’aide Commandes d’interface utilisateur TestStand pour plus d’informations sur l’utilisation des commandes d’interface utilisateur TestStand dans LabVIEW, CVI, C# ou VB.NET.

Commandes du gestionnaire et commandes visibles

Les commandes de l’interface utilisateur TestStand fournissent deux ensembles de commandes d’interface utilisateur : les commandes du gestionnaire et les commandes visibles.

Les commandes du gestionnaire appellent l’API TestStand pour effectuer des tâches telles que le chargement de fichiers, le lancement d’exécutions et la récupération d’informations de séquence et d’exécution. Les commandes du gestionnaire vous avertissent également lorsque des événements d’application se produisent, par exemple lorsqu’un utilisateur se connecte, qu’une exécution atteint un point d’arrêt ou qu’un utilisateur modifie le fichier ou la séquence qu’il consulte. Les commandes du gestionnaire sont invisibles au moment de l’exécution.

Les commandes visibles affichent des informations pour l’utilisateur, comme une commande de vue d’exécution qui montre l’état d’exécution actuel. Les commandes visibles permettent également à l’utilisateur d’interagir avec l’interface utilisateur, comme l’utilisation d’une commande bouton pour exécuter un test.  Les commandes visibles doivent être connectées à une commande du gestionnaire pour définir leur fonctionnement.  Cette connexion est implémentée à l’aide des méthodes de connexion des commandes du gestionnaire. Lorsque vous connectez des commandes, la logique interne de gestion du comportement des commandes visibles est gérée automatiquement par les commandes du gestionnaire.  Vous pouvez établir des connexions d’affichage, des connexions de liste, des connexions de commande et des connexions de source d’informations, selon le type de commande du gestionnaire et de commande visible que vous connectez, et le comportement souhaité de la commande visible.

Connectez les commandes visibles de l’interface utilisateur TestStand aux commandes du gestionnaire pour définir leur comportement.

Pour plus de détails sur l’utilisation des commandes de l’interface utilisateur TestStand dans différents environnements de programmation, reportez-vous à la rubrique d’aide Commandes de l’interface utilisateur TestStand.  Vous pouvez également utiliser la démonstration Connexion des commandes de l’interface utilisateur pour voir le comportement des connexions disponibles que vous pouvez créer.

De plus, vous pouvez utiliser les commandes fournies de manière native dans votre environnement de programmation avec les commandes de l’interface utilisateur TestStand. Lorsque vous travaillez avec des commandes natives, vous pouvez utiliser l’API d’interface utilisateur pour communiquer directement avec les commandes du gestionnaire afin d’implémenter les fonctionnalités liées à TestStand. Reportez-vous à l’exemple de création d’une interface utilisateur TestStand avec des commandes natives pour plus d’informations sur l’écriture d’une application qui appelle directement l’API TestStand.

Exemples d’applications d’interface utilisateur simples et complètes

TestStand fournit plusieurs exemples et composants que vous pouvez utiliser pour vous aider à créer une interface utilisateur. Les exemples d’interfaces utilisateur fournissent un point de départ pour développer une interface utilisateur personnalisée. TestStand est également livré avec des composants d’interface utilisateur qui implémentent les fonctionnalités fréquentes utilisées dans ces applications, que vous pouvez réutiliser dans vos propres applications.

TestStand est livré avec un exemple d’application d’interface utilisateur simple et complète dans les langages de programmation compatibles, notamment LabVIEW, LabWindows™/CVI™, C# et VB.net. TestStand fournit le code source de ces exemples dans chacun des langages de programmation compatibles. Vous pouvez utiliser ce code source comme point de départ pour développer une interface utilisateur personnalisée, ou vous pouvez l’utiliser tel quel.

L’interface utilisateur simple a un affichage minimal, ne comprend pas de barre de menus et est conçue comme une interface pour les opérateurs de test sur un système de test déployé. L’interface utilisateur complète affiche plus d’informations, comprend une barre de menus et fournit des fonctionnalités de débogage.  L’interface utilisateur complète dispose également d’un mode éditeur qui vous permet de créer et de modifier des séquences de test, comme l’éditeur de séquence TestStand.

Les exemples simples d’interface utilisateur sont un excellent point de départ pour apprendre à développer à l’aide des commandes de l’interface utilisateur TestStand.  Pour les implémentations LabVIEW, LabWindows/CVI ou C#, vous pouvez utiliser les guides suivants pour une description détaillée du code source et de son fonctionnement :

• Utilisation de l’interface utilisateur simple TestStand – LabVIEW
• Utilisation de l’interface utilisateur simple TestStand – LabWindows/CVI
• Utilisation de l’interface utilisateur simple TestStand – C#.NET

Pendant le développement d’interfaces utilisateur pour un système de test, il est important de prendre en compte les objectifs et les besoins de tous les utilisateurs qui interagiront avec l’application.  Les utilisateurs du système de test peuvent généralement être classés dans les rôles suivants :

• Développeur de framework : conçoit des composants de framework de test, y compris des interfaces utilisateur personnalisées, des modèles de processus et des types de pas de test.  
• Développeur de test : crée des séquences de test dans le framework implémenté par le développeur du framework.
• Technicien : résout les problèmes liés aux tests exécutés dans un environnement de production.
• Opérateur de test : configure les unités de test et exécute les tests dans un environnement de production.

Dans la planification et la conception d’interfaces utilisateur appropriées pour les utilisateurs du système de test, vous assumez le rôle de développeur de framework.  Les commandes de l’interface utilisateur TestStand vous permettent de personnaliser entièrement votre interface utilisateur en fonction des besoins de vos utilisateurs. Par exemple, un opérateur de tests peut seulement avoir besoin de pouvoir démarrer un test et voir le résultat.  Un développeur de tests doit cependant avoir un accès complet à la création et à la modification de fichiers de séquence.

Vous pouvez fournir aux développeurs de tests une interface utilisateur complète qui permet la création et la modification de fichiers de séquence, comme l’exemple d’interface utilisateur complet ou l’éditeur de séquence fourni avec TestStand.  Pour les opérateurs de tests, vous pouvez concevoir une interface utilisateur simple qui expose uniquement un bouton pour démarrer le test et un indicateur montrant le résultat du test, pour garantir que les opérateurs peuvent exécuter le test avec succès.  Fournir une interface utilisateur plus compliquée aux opérateurs peut être problématique, car elle nécessite une formation supplémentaire de l’opérateur et est sujette aux erreurs en raison des fonctionnalités disponibles.

En utilisant les commandes de l’interface utilisateur TestStand pour développer l’interface utilisateur, vous pourrez migrer en toute transparence de l’interface utilisateur complète vers l’interface utilisateur simple. Les deux interfaces utilisateur sont basées sur le moteur, les séquences, les modèles de processus et d’autres composants TestStand, qui sont partagés par les deux interfaces utilisateur.

Les interfaces utilisateur complètes telles que l’éditeur de séquence et les interfaces utilisateur simples peuvent interagir de manière transparente avec le même code de test

En plus de créer des interfaces utilisateur distinctes, vous pouvez également utiliser la gestion des utilisateurs TestStand pour personnaliser les fonctionnalités mises à disposition dans une seule application d’interface utilisateur.  Cette approche est plus adaptée dans les cas où différents rôles fonctionnent avec les mêmes exécutions de test.  Par exemple, un technicien responsable du dépannage des échecs de tests devra avoir accès aux données de diagnostic, telles qu’un aperçu de l’exécution et/ou du rapport de tests, qui ne sont généralement pas accessibles aux opérateurs.  Avoir une application d’interface utilisateur distincte pour le technicien serait problématique, car il n’aurait pas accès aux informations d’exécution en cours à partir de l’application distincte.  Pour résoudre ce problème, vous pouvez créer une interface utilisateur unique qui déverrouille des affichages supplémentaires pour les utilisateurs plus avancés.  Par exemple, l’interface utilisateur complète de TestStand peut être changée en mode éditeur en utilisant Ctrl + Shift + Alt + Insert pour fournir aux utilisateurs avancés la possibilité de modifier les séquences.

L’exemple d’interface utilisateur complète peut s’exécuter en mode opérateur ou en mode éditeur

Lorsque vous définissez des utilisateurs pour le gestionnaire d’utilisateurs TestStand, les commandes d’interface utilisateur TestStand activent ou désactivent automatiquement leur état en fonction des privilèges de l’utilisateur actuel. Vous pouvez également définir un comportement personnalisé en fonction des privilèges utilisateur avec la méthode API Engine.CurrentUserHasPrivilege TestStand, par exemple en masquant ou en affichant certaines parties de l’interface utilisateur. Reportez-vous à la rubrique d’aide Gestion des utilisateurs pour plus d’informations sur la définition des utilisateurs et des privilèges.

Pendant le développement d’une interface utilisateur TestStand, il est important de définir une ligne claire de ce qui est implémenté dans l’interface utilisateur par rapport aux autres composants du système de test.  Cette section décrit les fonctionnalités courantes du système de test et où elle doit être implémentée dans l’architecture TestStand.

Implémenter le code d’initialisation dans les rappels frontaux

Dans de nombreux cas, un système de test nécessite que des actions soient effectuées avant que le test ne commence à s’exécuter. Par exemple, vous devrez peut-être initialiser le matériel de test et valider qu’il est étalonné, ou vérifier les privilèges utilisateur pour initialiser l’interface utilisateur.

Pour gérer ces fonctions, vous pouvez utiliser la séquence LoginLogout dans le fichier de séquence de rappels frontaux.  Cette séquence est exécutée par défaut par la commande du gestionnaire d’applications de l’interface utilisateur TestStand au démarrage de TestStand et affiche par défaut la boîte de dialogue de connexion à l’utilisateur.  L’ajout de fonctionnalités à cette séquence présente les avantages suivants :

• Toutes les interfaces utilisateur TestStand et l’éditeur de séquence appellent la même séquence LoginLogout, ce qui vous permet de définir des fonctionnalités auxquelles vous pouvez accéder à partir de n’importe quelle interface utilisateur et d’éviter le code dupliqué.
• Vous pouvez modifier le comportement de votre code supplémentaire sans avoir à modifier les interfaces utilisateur.

En plus de la séquence LoginLogout, vous pouvez définir des séquences supplémentaires dans les rappels frontaux pour implémenter des fonctionnalités appelées à un moment différent.  Pour ces séquences supplémentaires, vous devrez ajouter du code à l’interface utilisateur pour appeler la séquence à l’heure souhaitée, à l’aide de la méthode Engine.CallFrontEndCallbackEx().  Cette approche est pratique, car vous n’avez pas besoin de gérer une référence à un fichier de séquence : le rappel frontal est chargé et déchargé automatiquement par TestStand.  

Utiliser le menu Outils (Tools) pour accéder aux applications supplémentaires

Un système de test utilise souvent des outils ou des applications distincts qui fonctionnent parallèlement au test.  Par exemple, vous pouvez lancer un utilitaire de configuration de base de données ou une application d’analyse.  Plutôt que de créer ces fonctions en tant que modules d’une application d’interface utilisateur, vous pouvez modulariser votre système en implantant des outils autonomes et y accéder via des éléments de menu d’outils personnalisés.  Vous pouvez personnaliser le menu Outils (Tools) à partir de l’éditeur de séquence à l’aide du menu Outils » Personnaliser (Tools » Customize). Dans la boîte de dialogue de personnalisation, vous pouvez ajouter de nouveaux éléments de menu d’outils et configurer leur comportement.

Créez des outils personnalisés pour fournir des fonctionnalités supplémentaires à toute interface utilisateur qui implémente le menu Outils (Tools)

Les modifications que vous apportez sont enregistrées dans un fichier de configuration distinct, de sorte que toutes les interfaces utilisateur affichent les mêmes entrées personnalisées que vous créez.  Pour plus d’informations, reportez-vous à la rubrique d’aide de la boîte de dialogue du menu Personnaliser les outils (Customize Tools).

Utiliser des modèles de processus pour définir des points d’entrée de séquence

Une interface utilisateur doit permettre aux utilisateurs de démarrer les exécutions de séquence, mais il est important que l’interface utilisateur ne soit directement couplée à aucun fichier de séquence.  Pour permettre aux utilisateurs de démarrer des tests, vous pouvez créer un bouton qui appelle un point d’entrée d’exécution de la séquence actuellement chargée, notamment en exécutant la séquence directement ou en utilisant un point d’entrée de modèle de processus, tel que Single Pass et Test UUT.  L’interface utilisateur ne doit pas contenir de fonctionnalités qui sont lancées avant ou après l’exécution d’une séquence ; implémentez plutôt cette fonctionnalité via le modèle de processus.

Les modèles de processus peuvent également définir des points d’entrée de configuration, qui permettent aux utilisateurs de configurer les paramètres du modèle de processus. Assurez-vous que tous les paramètres du modèle sont configurés à partir de ces points d’entrée, et non directement via l’interface utilisateur. En intégrant des fonctionnalités dans le modèle de processus, les fonctionnalités deviennent disponibles dans n’importe quelle application d’interface utilisateur TestStand et dans l’éditeur de séquence.

Pour plus d’informations sur l’utilisation des modèles de processus, reportez-vous au document Pratiques exemplaires pour la personnalisation du modèle de processus TestStand.

Bien qu’il soit important que l’interface utilisateur soit découplée des autres composants du système de test, tels que les fichiers de séquence de test et les modèles de processus, il est nécessaire que l’interface utilisateur communique efficacement avec ces composants.  Cette section fournit des approches que vous pouvez utiliser pour communiquer entre ces composants tout en conservant cette modularité.

Communication entre la séquence et l’interface utilisateur

Pendant qu’un test est en cours d’exécution, le système de test doit fournir un retour à l’opérateur indiquant l’état actuel de l’exécution, tel que le test en cours ou les résultats du test actuel. En général, vous pouvez utiliser les commandes de l’interface utilisateur TestStand pour afficher ces informations, telles qu’un affichage d’exécution et un affichage de rapport. En connectant ces commandes à une commande du gestionnaire, elles seront toujours mises à jour pour afficher l’état d’exécution actuel, comme géré par le moteur.

Dans certains cas, vous souhaiterez peut-être afficher des informations plus précises sur le test.  La séquence d’exécution ou le module de code doit transmettre ces informations à l’interface utilisateur pour affichage ou demander à l’interface utilisateur de prendre des mesures. Afin de communiquer ces informations sans introduire de couplage, vous pouvez utiliser des messages d’interface utilisateur pour implémenter la communication. Utiliser une propriété de fichier de séquence ou une variable d’interface utilisateur comme moyen de communication comme solution de rechange crée des dépendances indésirables entre les fichiers de séquence et l’interface utilisateur. Par exemple, la mise à jour d’un fichier global à partir de la séquence et la vérification de son état dans l’interface utilisateur introduisent un couplage entre le fichier global et l’interface utilisateur.   Les messages d’interface utilisateur sont privilégiés pour deux raisons :

1. Indépendance de l’interface utilisateur et des fichiers de séquence : une interface utilisateur doit toujours fonctionner avec n’importe quel fichier de séquence, et vice versa.  En utilisant des messages d’interface utilisateur, il n’est pas nécessaire que certaines propriétés existent dans les fichiers de séquence pendant leur utilisation avec l’interface utilisateur.  Avec les messages de l’interface utilisateur :
   • L’interface utilisateur peut exécuter des séquences qui n’implémentent pas certains messages (le code de gestion dans l’interface utilisateur ne s’exécute simplement jamais).
   • Les séquences qui publient des messages personnalisés peuvent être exécutées dans une interface utilisateur qui n’est pas conçue pour les gérer (le message de l’interface utilisateur est simplement ignoré par l’interface utilisateur).
2. Maintenabilité : les messages de l’interface utilisateur évitent de dépendre des propriétés du fichier de séquence ou des variables de l’interface utilisateur, ce qui signifie moins de maintenance pour les développeurs de fichiers de séquence et d’interfaces utilisateur.

Pour plus d’informations sur l’utilisation des messages d’interface utilisateur, reportez-vous à la section Utilisation des messages d’interface utilisateur TestStand (messages d’interface utilisateur)

Types de messages d’interface utilisateur

Les messages de l’interface utilisateur contiennent un identifiant de message qui indique le but du message.  TestStand définit plusieurs identifiants de message d’interface utilisateur, qui définissent des messages envoyés automatiquement par le moteur ou gérés automatiquement par les commandes de l’interface utilisateur TestStand.  Par exemple, l’identifiant de message UIMsg_EndExecution (valeur 4) est envoyé par le moteur après la fin d’une exécution.  Les commandes du gestionnaire exposent bon nombre de ces messages d’interface utilisateur en tant qu’événements individuels. Dans ce cas, vous pouvez définir un gestionnaire pour l’événement ApplicationManager EndExecution plutôt que d’utiliser directement un gestionnaire d’événements de message d’interface utilisateur.

D’autres messages d’interface utilisateur sont publiés par les modèles de processus par défaut, tels que UIMsg_ModelState_Identified (valeur  32), que les modèles de processus affichent après avoir indiqué le numéro de série de l’UUT.  De plus, vous pouvez publier des messages UIM prédéfinis ou personnalisés à partir de vos modules de code, de vos séquences de test ou du modèle de processus à l’aide de la méthode API Thread.PostUIMessageEx TestStand.

Une liste d’identifiants de message d’interface utilisateur ou de codes d’événement se trouve dans la rubrique d’aide Codes des messages d’interface d’utilisateur.

Vous pouvez définir vos propres messages UIM pour des opérations personnalisées, telles que la mise à jour des données dans un graphique et un histogramme. Lorsque vous définissez des messages d’interface utilisateur personnalisés, spécifiez des codes d’événement uniques commençant par le code d’événement UIMsg_UserMessageBase. Lorsque vous publiez un message d’interface utilisateur personnalisé, transmettez le code d’événement défini et les données à afficher. Les messages d’interface utilisateur fournissent des champs de données pour les données numériques, chaîne ou ActiveX que vous spécifiez pendant l’appel de la méthode postUIMessageEx. Lorsque vous définissez un gestionnaire pour répondre au message de l’interface utilisateur dans votre interface utilisateur, ces données sont exposées en tant que paramètres dans le rappel d’événement.

Pour définir la façon dont une interface utilisateur gère les messages de l’interface utilisateur, configurez l’interface opérateur pour exécuter le code défini par l’utilisateur lorsqu’un message de l’interface utilisateur est géré en ajoutant un rappel d’événement pour l’un des deux événements du gestionnaire d’application :

• Événement UImessage : cet événement est déclenché chaque fois qu’un message d’interface utilisateur est géré par le gestionnaire d’application.  Le rappel d’événement indiqué s’exécutera avant toute opération de gestion des messages d’interface utilisateur par défaut.  L’argument d’annulation d’événement de sortie peut être défini sur « Vrai » dans le rappel pour remplacer les opérations d’événement par défaut.
• Événement UserMessage : cet événement est déclenché uniquement pour les messages d’interface utilisateur personnalisés (ceux dont l’identifiant de message est supérieur ou égal à 10 000).  

Pour plus d’informations sur la définition des gestionnaires d’événements pour une interface utilisateur, reportez-vous à la rubrique Gestion des événements dans l’aide de TestStand.

Communication de l’interface utilisateur au test d’exécution

Dans certains cas, vous souhaiterez peut-être communiquer des informations de l’interface utilisateur à la séquence de test.  Cependant, la communication entre une séquence et une interface utilisateur doit toujours être initiée par la séquence, pour garantir que la séquence est dans un état où ses données peuvent être modifiées.  Pour ce faire, la séquence peut publier un message d’interface utilisateur avec un code personnalisé, indiquant qu’elle est prête pour la communication. Lorsque vous publiez le message d’interface utilisateur, définissez le paramètre synchrone sur « Vrai » pour que l’exécution attende jusqu’à ce que l’interface utilisateur traite le message. Lorsque l’interface utilisateur traite le message d’interface utilisateur, elle récupère l’objet SequenceContext et écrit ou lit certaines variables, telles que les variables locales du modèle de processus.
Dans de nombreux cas, l’interface utilisateur n’est pas le meilleur endroit pour l’utilisateur pour spécifier les données liées au test.  Par exemple, si les données concernent des tâches dans les modèles de processus, une meilleure approche serait de modifier ou de créer un point d’entrée de configuration, auquel vous pouvez accéder à partir du menu par défaut.

Pour un exemple illustrant la publication et la gestion de messages d’interface utilisateur, y compris l’utilisation de messages d’interface utilisateur pour collecter des données à partir de l’interface utilisateur, reportez-vous à l’exemple d’expédition de Gestion des messages d’interface utilisateur.

Cliquez ici pour accéder à d’autres ressources de la série TestStand Advanced Architecture, qui traite de sujets d’intérêt pour les développeurs avancés en NI TestStand.