Programmer avec l'API TestStand

Aperçu

Cette page est une introduction à l'utilisation de l'API NI TestStand, qui permet de maximiser la puissance et la flexibilité de TestStand. L'API TestStand fournit une interface orientée objet pour toutes les fonctionnalités de TestStand. Pour les applications les plus basiques, il n'est pas nécessaire d'interagir directement avec le modèle d'objet. Mais si vous comprenez le fonctionnement interne de TestStand, il est plus facile de découvrir comment créer rapidement des solutions TestStand avancées.

Contenu

Architecture TestStand et 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 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 TestStand Engine via l'API TestStand, avec 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.

 

Architecture de l'API TestStand

Le TestStand Engine 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 TestStand Engine. 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 appeler les 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 Interop fournit 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 d'aide de référence pour l'API TestStand 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 l'héritage : une classe plus spécifique peut hériter les 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 les propriétés et les 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 format de nom et 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 les classes 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 (step), d'une séquence ou d'un objet de fichier de séquence.

De nombreux environnements de développement ne vous permettent pas d'accéder directement aux propriétés d'une classe parente. 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 « caster » un objet 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 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 statiques

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

  • Des propriétés statiques (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 : elles sont toutes 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 statiques 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 statiques. Lorsque le l'API TestStand est utilisée au sein d'un module de code, il est préférable d'utiliser les propriétés statiques, car il est possible d'accéder à ces propriétés directement sans mettre en œuvre des chaînes de « lookup ».

 

Relations entres les objets TestStand

Les objets TestStand peuvent contenir des objets provenant d'une classe différente : c'est le lien de composition de l'API. 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 de composition entre les objets pour naviguer vers des objets spécifiques. Si un objet parent contient de multiples objets enfant, 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 enfant, 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 enfant peuvent accéder à leurs parents via l'API. Étant donné qu'un objet enfant n'a toujours 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 parente, vous pouvez utiliser :

ThisContext.Thread.Execution

Dans de nombreux cas, les propriétés statiques 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 Sequence Context :

ThisContext.Execution

 

Naviguer entre les objets de l'API TestStand

En plus de la navigation à l'aide de relations de composition, 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 fournit dans la rubrique d'aide de référence pour l'API TestStand pour savoir comment accéder à un objet voulu à partir de l'objet actuel. Un sous-groupe du diagramme est fourni ci-dessous.
 

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

Accès à l'API TestStand

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 nouvelles instance du moteur TestStand.
  • Pour les modules de code ou autres outils appelées à 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 toute 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 des variables globales 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 TestStand Engine.

Lorsque l'application se termine, vous devez arrêter le moteur TestStand Engine 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 Arrêter le moteur de l'aide TestStand.

Pour réduire la complexité de votre programme, National Instruments 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 fournit une couche d'abstraction au-dessus de l'API TestStand, ce qui facilite le développement d'applications TestStand autonomes. Consultez la [section sur l'API des commandes d'interface utilisateur] sur cette page pour en savoir plus sur l'utilisation des commandes.


Appeler un module de code ou 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 à un aperçu de l'état actuel de l'exécution mais aussi à l'objet TestStand Engine.

Le SequenceContext représente l'état d'exécution actuel d'une séquence : il permet 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 premier niveau du contexte de séquence, qui incluent tous les types de variables, l'étape actuelle et les propriétés de l'état d'exécution (RunState). Le SequenceContext fournit également des références vers de nombreux autres objets sous la forme de propriétés statiques.

 

RunState vs. SequenceContext


La propriété RunState et le SequenceContext permettent chacun 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 propriétés dynamiques, tandis que le SequenceContext les expose comme propriétés statiques.

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, là où le SequenceContext est plus adapté pour les modules de code, qui ne permettent pas d'accéder directement aux propriétés dynamiques.


Le SequenceContext fournit des informations sur l'état d'exécution via les propriétés statiques et dynamiques, tandis que la propriété RunState fournit des informations sur l'état d'exécution 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 du 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 complétée. Par exemple, le changement des valeurs de variables locales ou la création via programme 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")

 

Applications courantes de l'API TestStand

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 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 le flag 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 Ajouter des données personnalisées à un rapport.

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 de nouveaux conteneurs, instances de types de données et 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 [Créer de nouvelles propriétés à l'aide de l'API].

 

Créer 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, si vous souhaitez créer un outil permettant de générer un fichier de séquence initial basé sur une entrée utilisateur spécifique ou d'effectuer des modifications spécifiques aux étapes d'un fichier de séquence existant.

Pour d'avantage d'information sur la création de nouveaux fichiers de séquence à l'aide de l'API, consultez l'exemple Construire une séquence à l'aide de l'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 fichier de format 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 Translator de l'aide TestStand.


Modifier les 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 Créer un outil d'itération de fichiers de séquence.

 

API TestStand supplémentaires

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 Commandes d'interface utilisateur
  • API Adapter
  • API Serveur de synchronisation

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


API Commandes d'interface utilisateur

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 affichage des étapes ou des variables (Steps View ou Variables View), ainsi que des commandes de gestion invisible (Insivible 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, National Instruments 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 Commandes d'interface utilisateur vous permet de mettre en œuvre des tâches d'interface utilisateur courante 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 Commandes d'interface utilisateur 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 Commandes d'interface utilisateur, consultez les rubriques d'aide suivantes :


Vous pouvez considérer les commandes d'IU 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'IU TestStand sont riches en fonctionnalités et incluent leur propre API. Même si cette page 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 « castez » le type de l'objet 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 référence sur l'API Adapter TestStand pour obtenir la liste des classes fournies par l'API Adapter.

 

API Serveur de synchronisation

L'API Serveur de synchronisation 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 « casté » cet objet vers la classe de gestionnaire de synchronisation définie dans l'API Serveur de synchronisation, vous pouvez l'utiliser pour accéder à des objets de synchronisation ou en créer de nouveaux.


Utilisez le SyncManager et l'API Serveur de synchronisation pour créer et accéder aux objets de synchronisation de TestStand 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 Référence pour l'API Serveur de synchronisation.