Programmation au moyen de l’API TestStand

Une architecture de test bien conçue et modulaire est un avantage extraordinaire. Vous pouvez réutiliser une architecture généralisée et adaptable sur plusieurs systèmes de test pour étendre la durée de vie du système de test et réduire les coûts de développement des tests. TestStand fournit une plate-forme basée sur la modularité qui simplifie le développement de systèmes de test et des tests associés. La force de TestStand tient dans son architecture ouverte, dont vous pouvez tirer parti pour créer des solutions de test complexes et flexibles.

Le moteur TestStand (TestStand Engine) fournit les fonctionnalités pour les composants de TestStand qui communiquent avec le moteur à travers l'API TestStand

TestStand établit une séparation claire entre la couche de présentation (ce que l'utilisateur voit) et la couche de logique métier (les actions derrière l'action de l'utilisateur). Ces couches communiquent à l'aide de l'API TestStand. Cette approche vous permet d'étendre TestStand en construisant des composants supplémentaires qui utilisent le moteur TestStand via l'API TestStand, par exemple la création d'interfaces utilisateur personnalisées, le contrôle dynamique du flux des tests, la création de séquences à la volée et le développement d'autres solutions avancées.

Le moteur TestStand est un serveur d'automatisation ActiveX/COM qui expose les fonctionnalités via une API. Microsoft a développé ActiveX, un standard de communication pour applications, afin de fournir une méthode communication entre les applications. Largement utilisé dans l'industrie depuis de nombreuses années, ActiveX est construit sur des technologies COM. TestStand est basé sur la spécification COM, c'est pourquoi le logiciel continuera de fonctionner sur les versions futures des systèmes d'exploitation Windows, même au-delà de la durée de vie de ActiveX.

ActiveX utilise une approche client/serveur. Un serveur ActiveX est une application qui expose des fonctionnalités spécifiques aux clients qui suivent le standard ActiveX. De plus, les applications ActiveX utilisent la programmation orientée objet (POO).

L'architecture de serveur ActiveX permet à tout langage de programmation capable d'appeler du code ActiveX (tel que LabVIEW, LabWindows™/CVI™, C#, VB .NET, ou C++) d'interagir avec le moteur TestStand. Lorsque vous programmez avec l'API TestStand, l'implémentation dépend du langage que vous utilisez. Par exemple :

• LabVIEW utilise les nœuds de propriété et de méthode pour effectuer des appels d’API.
• LabWindows/CVI utilise un wrapper de driver d'instrument autour des appels d'API.
• C# ou VB .NET appellent l'API à l'aide d'un assembly d’interopérabilité fourni par TestStand.
• TestStand fournit un adaptateur ActiveX/COM (ActiveX/COM Adapter) permettant d'accéder à l'API, et vous pouvez également utiliser des expressions pour accéder directement à l'API.

Quelle que soit la méthode d'accès à l'API, le comportement est le même dans tous les environnements car les fonctionnalités sont implémentées au sein du moteur TestStand, indépendamment de l'interface que vous utilisez.

Classes d'API

L'API TestStand définit plusieurs classes qui représentent des types d'objets TestStand, comme la classe SequenceFile ou la classe Execution. Chacune de ces classes définit des propriétés et des méthodes pour accéder aux données pertinentes ou pour effectuer des opérations. Par exemple, la classe SequenceFile définit la propriété Path pour enregistrer le chemin du fichier de séquence sur disque, et la méthode Save pour sauvegarder le fichier de séquence.

Consultez la rubrique TestStand API Reference Help pour accéder à la liste complète des classes disponibles définies dans l'API TestStand. Cliquez sur une classe spécifique pour obtenir davantage d'informations sur celle-ci, en plus des propriétés et méthodes qu'elle définit. 

Héritage de classe

De nombreuses classes dans TestStand sont liées par héritage : une classe plus spécifique peut hériter des propriétés ou méthodes d'une classe plus générique. Par exemple, la classe SequenceFile est une version plus spécifique de la classe PropertyObject. L'API TestStand définit une relation d'héritage entre ces classes, pour permettre à des objets d'une classe plus spécifique d'accéder aux propriétés et méthodes de classes plus génériques.

La classe SequenceFile hérite des propriétés et des méthodes des classes PropertyObjectFile et PropertyObject plus génériques

Quasiment toutes les classes d'API TestStand héritent de la classe de base PropertyObject, qui inclut les méthodes et propriétés communes partagées par les objets TestStand. La classe PropertyObject définit les propriétés génériques, telles que le nom et le format numérique, et fournit les méthodes communes de gestion d'objets, permettant entre autres de cloner, déterminer et obtenir des valeurs, de créer et de supprimer des objets, ou de manipuler des tableaux. La plupart des classes d'API TestStand héritent de la classe PropertyObject, elles peuvent donc également accéder à ces propriétés et méthodes génériques. Par exemple, vous pouvez utiliser la méthode PropertyObject.Clone() pour créer une copie d'une étape, d'une séquence ou d'un objet de fichier de séquence.

De nombreux environnements de développement vous empêchent d'accéder directement aux propriétés d'une classe parent. De même, TestStand ne permet pas d'appeler la méthode Clone() directement sur un objet SequenceFile. Cependant, l'API TestStand fournit des méthodes permettant de convertir un objet (casting) pour accéder aux propriétés et méthodes de la classe plus générique. Pour accéder aux propriétés et méthodes définies dans la classe PropertyObject, vous pouvez « caster » l'objet dans sa classe parente en appelant la méthode AsPropertyObject. Par exemple, pour accéder à la méthode Clone() sur un objet de fichier de séquence, utilisez
SequenceFile.AsPropertyObject.Clone().

Consultez l'aide de NI TestStand pour en apprendre davantage sur l'héritage dans l'API et les propriétés et les méthodes de la classe PropertyObject.

Propriétés dynamiques vs propriétés intégrées

Les objets TestStand ont deux types distincts de propriétés :

• Des propriétés intégrées (propriétés de l'API), qui sont définies par la classe de l'objet et sont présentes pour tous les objets d'une classe spécifique.
• Des propriétés dynamiques (sous-propriétés), qui sont définies par l'objet et peuvent différer entre objets d'une même classe.

Un objet d'étape possède des propriétés dynamiques qui peuvent être différentes selon le type d'étape, et des propriétés statiques qui sont définies par la classe Step dans l'API TestStand.

Ces deux types distincts de propriétés peuvent être facilement confondus car ils sont tous deux accessibles via une expression TestStand à l'aide de l'opérateur « . ». Cependant, lorsque vous utilisez l'API dans d'autres langages de programmation, seules les propriétés intégrées sont disponibles en accès direct (comme lorsque vous utilisez un nœud de propriété dans LabVIEW).

Pour accéder aux propriétés dynamiques, utilisez les méthodes d'API PropertyObject, telles que GetValString() et GetValNumber(), en utilisant LookupString pour spécifier le nom de la propriété dynamique :

Dans certains cas, vous pouvez accéder à une propriété de plusieurs façons différentes, soit via les propriétés dynamiques, soit via les propriétés intégrées. Lorsque l'API TestStand est utilisée au sein d'un module de code, il est préférable d'utiliser les propriétés intégrées, car il est possible d'accéder à ces propriétés directement sans mettre en œuvre des chaînes de recherche. 

Relations entres les objets TestStand

Les objets TestStand peuvent contenir des objets provenant d'une classe différente : c'est ce qu’on appelle l’imbrication de l'API (API Containment). Par exemple, un objet SequenceFile contient des objets Sequence pour les séquences définies dans le fichier de séquence. Les objets Sequence, quand à eux, contiennent chacun des objets Step.

Les objets de l'API TestStand contiennent souvent d'autres objets d'une classe différente.

Il est utile de comprendre les relations d’imbrication entre les objets pour naviguer vers des objets spécifiques. Si un objet parent contient de multiples objets enfants, vous devez fournir un nom de propriété ou indice de propriété pour spécifier l'objet enfant voulu. Pour la plupart des objets enfants, vous pouvez accéder aux objets contenus à partir d'un objet parent à l'aide d'une méthode accesseur (getter) spécifique, qui accepte le nom ou indice d'objet comme paramètre. Par exemple, pour accéder à une étape dans un fichier de séquence, utilisez :

SequenceFile.getSequenceByName(“MainSequence”).GetStepByName(“RAM Test”, StepGroup_Main)

En outre, les objets enfants peuvent accéder à leurs parents via l'API. Étant donné qu'un objet enfant ne peut avoir qu'un seul parent, utilisez une propriété plutôt qu'une méthode accesseur pour accéder directement au parent. Par exemple, si vous avez un objet SequenceContext et voulez accéder à l'exécution parent, vous pouvez utiliser :

ThisContext.Thread.Execution

Dans de nombreux cas, les propriétés intégrées sont fournies pour accéder à des ancêtres plus distants. Par exemple, vous pouvez accéder directement à l'objet d'exécution à partir d'un objet SequenceContext :

ThisContext.Execution

Navigation entre les objets de l'API TestStand

En plus de la navigation à l'aide de relations d’imbrication, de nombreuses classes fournissent des propriétés et des méthodes pour accéder à d'autres objets associés. Par exemple, la classe Module fournit la propriété Adapter permettant d'accéder à l'adaptateur correspondant qui est en cours d'exécution. 

Vous pouvez utiliser le diagramme fourni dans la rubrique TestStand API Reference Help pour savoir comment accéder à un objet voulu à partir de l'objet actuel. Une partie du diagramme est présentée ci-dessous.
 

À partir de l'objet SequenceContext, vous pouvez naviguer entre les relations d'objet pour accéder à d'autres objets

Deux approches sont généralement utilisées pour accéder à l'API, selon le type d'application que vous créez :

• Pour les applications autonomes, vous devez créer une nouvelle instance du moteur TestStand.
• Pour les modules de code ou autres outils appelés à partir d'une application existante, vous devez transmettre une référence existante au moteur TestStand.

Création d'une application TestStand autonome

Pour utiliser l'API TestStand dans une nouvelle application, vous devez d'abord créer une instance du moteur TestStand. Toute application ou processus TestStand (une interface utilisateur TestStand, un éditeur de séquence ou un utilitaire personnalisé par exemple) maintient une seule instance du moteur (singleton) qui réalise toutes les fonctions TestStand. Le moteur maintient les références vers la totalité des objets en mémoire, configure et contrôle les exécutions, et enregistre les données contextuelles d'une session TestStand ainsi que les variables globales de poste et informations utilisateur.

Le moteur TestStand fournit des méthodes que vous pouvez utiliser pour créer d'autres objets TestStand, qui sont identifiés avec le mot-clé « new », parmi lesquelles :

• Engine.NewSequenceFile()
• Engine.NewStep()
• Engine.NewExecution()
• Engine.NewPropertyObject()

Pour en savoir plus et obtenir la liste complète des propriétés et méthodes disponibles à partir de l'objet Engine, consultez la rubrique dédiée au moteur TestStand.

Lorsque l'application se termine, vous devez arrêter le moteur TestStand avant de quitter l'application. Pour s'assurer que l'utilisateur ait l'occasion de mettre fin à toute exécution, un processus d'arrêt en deux étapes est nécessaire, comme l'explique la rubrique Shutting Down the Engine de l'aide TestStand.

Pour réduire la complexité de votre programme, NI recommande l'utilisation des commandes d'interface utilisateur TestStand pour développer des applications et interfaces utilisateurs TestStand plutôt que de créer directement un objet de moteur TestStand. Les commandes d'interface utilisateur TestStand fournissent une couche d'abstraction au-dessus de l'API TestStand, ce qui facilite le développement d'applications TestStand autonomes. Consultez la section API UI Controls dans ce document pour en savoir plus sur l'utilisation des commandes d’interface utilisateur.

Appel d’un module de code ou d’un outil à partir d'une application existante

Lorsque vous utilisez l'API dans un module de code ou un outil que vous appelez à partir d'une autre application TestStand, vous utilisez le moteur TestStand créé par l'application de plus haut niveau. Si le code est appelé à partir d'une séquence d'exécution, comme un module de code, il est préférable d'utiliser un paramètre d'entrée pour le SequenceContext. Choisissez cette méthode plutôt que de passer directement le moteur TestStand, car le contexte de séquence permet d'accéder à l'état actuel de l'exécution mais aussi à l'objet de moteur TestStand.

SequenceContext représente l'état d'exécution actuel d'une séquence, permettant d'accéder à un aperçu de toutes les données d'une séquence spécifique en cours d'exécution. Chaque séquence en cours d'exécution dans un thread a son propre SequenceContext.

Lorsque vous parcourez l'affichage des variables, la liste que vous voyez contient les propriétés de niveau principal du contexte de séquence, qui incluent tous les types de variables, l'étape actuelle et la propriété de l'état d'exécution (RunState). SequenceContext fournit également des références vers de nombreux autres objets sous la forme de propriétés intégrées.

RunState vs SequenceContext

La propriété RunState et SequenceContext permettent tous deux d'accéder à de nombreux d'objets identiques, comme l'exécution actuelle, le thread, le fichier de séquence et la séquence. Cependant, la propriété RunState contient ces objets en tant que propriétés dynamiques, tandis que SequenceContext les expose comme propriétés intégrées.

C'est la raison pour laquelle la propriété RunState doit être utilisée pour accéder aux informations d'état dans les expressions TestStand, alors que SequenceContext est plus adapté pour les modules de code, qui ne permettent pas d'accéder directement aux propriétés dynamiques.

 SequenceContext fournit des informations sur l'état d'exécution via les propriétés intégrées et dynamiques, tandis que la propriété RunState fournit des informations sur l'état via les propriétés dynamiques uniquement.

Persistance des données de séquence

Avant d'exécuter les étapes en séquence, TestStand crée une copie d'exécution de la séquence pour maintenir des valeurs séparées de variables locales et de propriété d'étape pour chaque invocation de séquence. Dans la plupart des cas, lorsque vous accédez à des objets du RunState ou de SequenceContext au sein d'une séquence en cours d'exécution, les objets sont des copies d'instance d'exécution. Cela signifie que tout changement apporté à ces objets ne persistera pas une fois l'exécution terminée. Par exemple, le changement des valeurs de variables locales ou la création par programmation d'une sous-propriété d'un paramètre ne modifiera pas le fichier de séquence sur le disque :

Locals.SetValString("RuntimeVariable",1, "value")

Les objets qui héritent de la classe PropertyObjectFile, tels que les objets SequenceFile, n'ont pas de copie d'instance d'exécution séparée. Ainsi, les changements effectués via ces objets persisteront après la fin de l'exécution. Par exemple, l'accès aux propriétés Locals via l'objet SequenceFile vous permet de créer une variable locale persistante.

RunState.sequencefile.GetSequenceByName("MainSequence").Locals.SetValString("PersistantVariable",1, "value")

L'API TestStand permet d'automatiser toutes les fonctionnalités de TestStand. Cependant, certaines des applications de l'API sont plus courantes :

• Création de propriétés personnalisées
• Création de nouveaux fichiers de séquence
• Modification de séquences existantes

Création de propriétés personnalisées

Vous pouvez utiliser l'API TestStand pour générer dynamiquement des propriétés personnalisées lors de l'exécution. Par exemple, vous pouvez ajouter des données de diagnostic spécifiques aux résultats des tests si le test échoue pour un composant particulier ou ajouter des données personnalisées à l'en-tête du rapport. 

Il existe de nombreuses façons de créer des propriétés personnalisées via l'API. Pour les types de données primitifs, l'utilisation de la méthode SetVal avec l'option InsertIfMissing est la méthode la plus simple pour créer de nouvelles propriétés. Par exemple, vous pouvez utiliser l'expression suivante pour ajouter une nouvelle propriété à une étape de test de limite numérique :

RunState.Sequence.Main["Numeric Limit Test"].AsPropertyObject.SetValString(
"Result.extraResult",
PropOption_InsertIfMissing,
"this string is an extra result")

Pour ajouter une propriété personnalisée au rapport, vous devez également régler l’indicateur IncludeInReport pour l'objet, que le générateur de rapport utilise pour choisir quelles propriétés de résultat enregistrer :

RunState.Sequence.Main["Numeric Limit Test"].AsPropertyObject.SetFlags(
"Result.extraResult",
0,
PropFlags_IncludeInReport)

Pour plus de détails sur l'utilisation de l'API pour ajouter des données au rapport de test, consultez l'exemple Adding Custom Data to a Report.

Pour les propriétés plus complexes comme les conteneurs, vous aurez besoin de créer les propriétés directement à l'aide de la méthode NewSubProperty(), qui vous permet de créer des conteneurs, des instances de types de données et des tableaux. Par exemple, pour créer une nouvelle variable locale du type Error, vous pouvez utiliser l'expression suivante :

Locals.NewSubProperty("ComplexContainer.Error",PropValType_NamedType, False, "Error",0)

Pour plus de détails sur l'utilisation de l'API pour créer des propriétés, consultez l'exemple [Creating new properties using API].

Création de nouvelles séquences

Pour automatiser le processus de création de fichiers de séquence en fonction de l'entrée utilisateur, vous pouvez utiliser l'API TestStand pour générer de nouveaux fichiers de séquence ou créer des copies modifiées d'un fichier existant. Par exemple, vous souhaiterez peut-être créer un outil qui génère un fichier de séquence de points de départ en fonction de certaines entrées de l'utilisateur ou effectue des modifications spécifiques aux étapes d'un fichier de séquence existant.

Pour plus d'informations sur la création de nouveaux fichiers de séquence à l'aide de l'API, reportez-vous à l'exemple Building a Sequence Using the API.

Vous pouvez également utiliser l'API TestStand pour développer un traducteur de fichier de séquence (Sequence File Translator) pour générer des fichiers de séquence à l'aide d'un format de fichier personnalisé. En créant un traducteur de fichier de séquence, vous utilisez l'API TestStand pour générer des fichiers de séquence, des séquences, des étapes et des propriétés en fonction des données d'un fichier que vous aurez défini. Le framework Translator vous permet d'intégrer ce code à TestStand, et d'ouvrir directement les fichiers dans un format personnalisé. 

Pour plus d'informations sur l'utilisation des traducteurs de fichier de séquence, consultez la rubrique Sequence File Translators de l'aide TestStand.

Modification des séquences

Vous pouvez utiliser l'API TestStand dans les outils personnalisés que vous utilisez pour effectuer des modifications sur les fichiers de séquence existants. Par exemple, vous pouvez créer un outil qui recherche les modules de code spécifiés par un chemin absolu et les remplace par des chemins relatifs. 

Pour plus d'informations, consultez l'exemple Creating a Sequence File Iteration Tool.

En plus de l'API TestStand principale, TestStand offre d'autres API qui étendent les fonctionnalités et fournissent des capacités supplémentaires :

• API UI Controls
• API Adapter
• API Synchronization Server

Contrairement à l'API TestStand principale, ces API ne sont pas directement accessibles à l'aide d'expressions : vous pouvez les utiliser via une étape ActiveX ou un module de code distinct.

API UI Controls

TestStand comprend un ensemble de commandes d'interface utilisateur vous permettant de développer rapidement des interfaces utilisateur TestStand. Ces commandes incluent les commandes visibles pour afficher les données TestStand, telles que les affichages des étapes ou des variables (Steps View ou Variables View), ainsi que des commandes de gestion invisible (Invisible Manager) qui gèrent la majeure partie de la communication avec l'API TestStand Engine dans une interface utilisateur TestStand.

Lorsque vous développez une application TestStand autonome, NI recommande d'utiliser les commandes d'interface utilisateur pour développer l'application au lieu de créer directement une instance du moteur TestStand.

L'API UI Controls vous permet de mettre en œuvre des tâches d'interface utilisateur courantes via les commandes de gestion, comme l'ouverture et l'exécution de fichiers de séquence, la réponse aux messages d'interface utilisateur et la gestion de la fermeture de l'application. L'API UI Controls fournit également des méthodes de connexion pour configurer les commandes d'interface utilisateur. 

Pour plus d'informations sur l'utilisation des commandes d'interface utilisateur et de l'API UI Controls, consultez les rubriques d'aide suivantes :

• TestStand UI Controls – Aperçu de l'utilisation des commandes d'interface utilisateur pour développer des applications d'interface utilisateur TestStand.
• TestStand UI Controls API Reference Help – Référence pour les classes dans l'API UI Controls.
• Bonnes pratiques de développement de l'interface utilisateur – Bonnes pratiques pour l'utilisation des commandes d'interface utilisateur et de l'API.

Vous pouvez considérer les commandes d'interface utilisateur TestStand comme une couche logicielle au-dessus de l'API TestStand Engine. Ces commandes englobent de nombreuses fonctionnalités dont vous avez besoin dans une interface utilisateur, comme l'ouverture de séquences, l'exécution de tests, l'affichage de l'avancement des tests, etc. Les commandes d'interface utilisateur TestStand sont riches en fonctionnalités et incluent leur propre API. Même si ce document n'a pas pour vocation de traiter des fonctionnalités des commandes d'interface utilisateur, il est important de signaler que ces commandes fournissent des fonctionnalités basées sur l'API TestStand Engine.

API Adapter

L'API Adapter fournit des classes spécifiques pour les différents adaptateurs inclus dans TestStand. Généralement, l'API Adapter est utilisée pour les informations ou fonctionnalités spécifiques à l'adaptateur lorsque l'adaptateur ou les classes de module sont utilisées dans l'API principale. Dans ce cas, vous convertissez le type de l'objet (casting) vers la classe d'API Adapter appropriée. Par exemple, vous pouvez utiliser la classe LabVIEWModule pour accéder aux propriétés et méthodes spécifiques à LabVIEW pour l'objet de module dans une étape LabVIEW.

Utilisez l'API Adapter pour accéder aux propriétés et méthodes spécifiques à l'adaptateur pour les classes Module ou Adapter

Consultez la rubrique TestStand Adapter API Reference pour obtenir la liste des classes fournies par l'API Adapter.

API Synchronization Server

L'API Synchronization Server permet d'accéder directement aux objets de synchronisation TestStand, tels que les files d'attente, les verrous ou les notifications. Pour utiliser cette API, vous devez d'abord obtenir une référence vers le gestionnaire de synchronisation à l'aide de la méthode Engine.GetSyncManager. Après avoir converti cet objet (casting) vers la classe de gestionnaire de synchronisation définie dans l'API Synchronization Server, vous pouvez l'utiliser pour accéder à des objets de synchronisation ou en créer de nouveaux.

Utilisez SyncManager et l'API Synchronization Server pour créer des objets de synchronisation de TestStand et y accéder dans le code

Cette API est utile pour développer des applications qui s'exécutent en parallèle d'un test TestStand et qui nécessitent l'accès aux informations sur l'état de l'exécution, comme une application de surveillance de l'état.

Pour plus d'informations sur les classes disponibles, consultez la rubrique Synchronization Server API Reference.

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