Programación con la API TestStand

Una arquitectura modular de pruebas bien diseñada proporciona un valor inmenso. Puede reutilizar una arquitectura generalizada y adaptable en una variedad de sistemas de pruebas para extender la vida útil del sistema de pruebas y reducir los costos de desarrollo de la prueba. TestStand proporciona una plataforma construida en modularidad para simplificar el desarrollo de sistemas de prueba y las pruebas correspondientes. El poder de TestStand reside en su arquitectura abierta, que puede utilizar para crear soluciones de prueba complejas y flexibles.

El Motor TestStand proporciona la funcionalidad para los componentes de TestStand, que se comunican con el motor a través de la API de TestStand

TestStand tiene una clara separación entre la capa de presentación (lo que ve el usuario) y la capa de lógica de negocios (las acciones detrás de una acción del usuario). Estas capas se comunican utilizando la API de TestStand. Este enfoque le permite ampliar TestStand mediante la creación de componentes adicionales que utilizan el Motor TestStand a través de la API TestStand, como la creación de interfaces de usuario personalizadas, el control dinámico del flujo de pruebas, la creación de secuencias sobre la marcha y el desarrollo de otras soluciones avanzadas.

El Motor TestStand es un servidor de automatización ActiveX/COM que expone la funcionalidad a través de una API. Microsoft desarrolló el estándar de comunicación de aplicaciones ActiveX para proporcionar un método de comunicación entre aplicaciones. Ampliamente utilizado en la industria durante muchos años, ActiveX se basa en tecnologías COM. Debido a que TestStand se basa en COM, seguirá funcionando en futuras versiones de los sistemas operativos Windows más allá de la vida útil de ActiveX.

ActiveX utiliza un enfoque cliente/servidor. Un servidor ActiveX es una aplicación que expone una funcionalidad específica a los clientes que siguen el estándar ActiveX. Además, las aplicaciones ActiveX utilizan Programación Orientada a Objetos (OOP).

La arquitectura del servidor ActiveX permite que cualquier lenguaje de programación capaz de invocar código ActiveX, como LabVIEW, LabWindows ™/CVI ™, C #, VB .NET o C ++, interactúe con el Motor TestStand. Al programar con la API de TestStand, la implementación depende del lenguaje que utilice. Por ejemplo:

• LabVIEW usa los Nodos de Propiedad e Invocación para hacer llamadas a la API.
• LabWindows/CVI utiliza una envoltura de controlador de instrumentos alrededor de las llamadas a la API.
• C # o VB .NET llaman a la API utilizando un ensamble de interoperabilidad que proporciona TestStand.
• TestStand proporciona un adaptador ActiveX/COM para acceder a la API, y también puede usar expresiones para acceder a la API directamente.

Independientemente de la forma en que acceda a la API, el comportamiento resultante es el mismo en cualquier entorno, ya que la funcionalidad se implementa dentro del Motor TestStand independientemente de la interfaz que use.

Clases API

La API de TestStand define varias clases para representar tipos de objetos de TestStand, como la clase SequenceFile o la clase Execution. Cada una de estas clases define propiedades y métodos para acceder a datos relevantes o realizar acciones. Por ejemplo, la clase SequenceFile define la propiedad Ruta (Path) para almacenar la ruta del archivo de secuencia en el disco y el método Guardar para guardar el archivo de secuencia.

Consulte el tema de ayuda TestStand API Reference para obtener una lista completa de las clases disponibles definidas en la API de TestStand. Haga clic en una clase particular para ver más información y las propiedades y métodos que define. 

Herencia de Clases

Muchas clases en TestStand están relacionadas a través de la herencia: donde una clase más específica puede heredar propiedades o métodos de una clase más genérica. Por ejemplo, la clase SequenceFile es una versión más específica de la clase PropertyObject. La API de TestStand define una relación de herencia entre estas clases para permitir que los objetos de una clase más específica tengan acceso a las propiedades y métodos de las clases más genéricas.

La clase SequenceFile hereda propiedades y métodos de las clases más genéricas PropertyObjectFile y PropertyObject

Casi todas las clases de la API de TestStand se heredan de la clase PropertyObject base, que incluye métodos y propiedades comunes que comparten los objetos de TestStand. La clase PropertyObject define propiedades genéricas, como Nombre y Formato Numérico, y proporciona métodos comunes para la administración de objetos, como la clonación, configuración y obtención de valores, creación y eliminación de objetos o manipulación de arreglos. Debido a que la mayoría de las clases de la API de TestStand heredan de la clase PropertyObject, también pueden tener acceso a estas propiedades y métodos genéricos. Por ejemplo, puede usar el método PropertyObject.Clone () para crear una copia de un paso, una secuencia o un objeto de archivo de secuencia.

Muchos entornos de desarrollo le impiden tener acceso directamente a las propiedades de una clase principal. De manera similar, en TestStand no puede llamar al método Clone () directamente en un objeto SequenceFile. Sin embargo, la API de TestStand proporciona métodos para seleccionar un objeto para tener acceso a las propiedades y los métodos de la clase más genérica. Para acceder a las propiedades y métodos definidos en la clase PropertyObject, puede convertir el objeto en su clase principal llamando al método AsPropertyObject. Por ejemplo, para tener acceso al método Clone () en un objeto de archivo de secuencia, use
SequenceFile.AsPropertyObject.Clone().

Consulte la Ayuda de NI TestStand para obtener más información acerca de Herencia de API y las propiedades y métodos de la clase PropertyObject.

Propiedades Dinámicas versus Propiedades Integradas

Los objetos de TestStand tienen dos tipos distintos de propiedades:

• Las propiedades integradas (Propiedades de la API), que están definidas por la clase del objeto, están presentes para todos los objetos de una clase determinada.
• Las propiedades dinámicas (sub-propiedades), que están definidas por el objeto, pueden diferir entre los objetos de la misma clase.

Un objeto de paso tiene propiedades dinámicas que pueden diferir según el tipo de paso y las propiedades estáticas que están definidas por la clase de paso en la API de TestStand

Puede ser fácil confundir estos dos diferentes tipos de propiedades, ya que usted puede tener acceso a ambos en una expresión TestStand utilizando "." como operador. Sin embargo, cuando usa la API en otros lenguajes de programación, únicamente las propiedades integradas están disponibles a través del acceso directo, como cuando se usa un nodo de propiedad en LabVIEW.

Para acceder a las Propiedades dinámicas, utilice los métodos de la API PropertyObject, como GetValString () y GetValNumber (), utilizando un LookupString para especificar el nombre de la propiedad dinámica:

En algunos casos, puede tener acceso a una propiedad de varias maneras utilizando propiedades dinámicas o propiedades integradas. Cuando se utiliza la API de TestStand en un módulo de código, es preferible utilizar propiedades integradas, ya que se puede tener acceso a estas propiedades directamente sin la necesidad de mantener cadenas de búsqueda. 

Relaciones de Objeto de TestStand

Los objetos de TestStand pueden contener otros objetos de una clase diferente, denominados Contención de la API . Por ejemplo, un objeto SequenceFile contiene objetos de secuencia para las secuencias definidas en el archivo de secuencia. Los objetos de secuencia, a su vez, contienen objetos de Paso.

Los objetos en la API de TestStand a menudo contienen otros objetos de una clase diferente

Comprender las relaciones de contención entre objetos es útil cuando se navega por objetos específicos. Si un objeto principal contiene varios objetos secundarios de una determinada clase, debe proporcionar un nombre de propiedad o un índice para especificar el objeto secundario deseado. Para la mayoría de los objetos secundarios, usted puede tener acceso a los objetos contenidos desde un objeto principal utilizando un método específico de obtención, que acepta el nombre o índice del objeto como parámetro. Por ejemplo, para acceder a un paso dentro de un archivo de secuencia, utiliza:

SequenceFile.getSequenceByName ("MainSequence"). GetStepByName ("RAM Test", StepGroup_Main)

Además, los objetos secundarios pueden tener acceso a su objeto principal a través de la API. Como un objeto secundario siempre puede tener un objeto principal, se usa una propiedad en lugar de un método de obtención para tener acceso directamente al objeto principal. Por ejemplo, si tiene un objeto SequenceContext y necesita tener acceso a la ejecución principal, podría usar:

ThisContext.Thread.Execution

En muchos casos, las propiedades integradas se proporcionan para tener acceso a ancestros más lejanos. Por ejemplo, puede tener acceso directamente al objeto de ejecución desde un objeto de contexto de secuencia:

ThisContext.Execution

Navegar a través de los Objetos de la API de TestStand

Además de navegar utilizando relaciones de contención, muchas clases proporcionan propiedades o métodos para tener acceso a otros objetos relacionados. Por ejemplo, la clase Módulo proporciona la propiedad Adaptador para tener acceso al adaptador correspondiente que se está ejecutando. 

Puede utilizar la tabla que se proporciona en el tema de ayuda TestStand API Reference para determinar cómo puede tener acceso a un objeto deseado desde el objeto actual. Un subconjunto de esta tabla se muestra a continuación.
 

Desde el objeto sequenceContext, puede navegar las relaciones de objetos para tener acceso a otros objetos

Por lo general, existen dos enfoques que puede utilizar para tener acceso a la API, dependiendo del tipo de aplicación que esté creando:

• Para aplicaciones autónomas, debe crear una nueva instancia del Motor TestStand.
• Para módulos de código u otras herramientas llamadas desde una aplicación existente, debe pasar una referencia existente al Motor TestStand.

Crear una Aplicación Autónoma de TestStand

Para utilizar la API de TestStand en una nueva aplicación, primero debe crear una instancia del Motor TestStand. Cualquier aplicación o proceso de TestStand, como la interfaz de usuario de TestStand, el editor de secuencias o la utilidad personalizada, mantiene una instancia única del motor, o singleton, para realizar cualquier función de TestStand. El motor mantiene referencias para todos los objetos en la memoria, configura y controla las ejecuciones, y almacena los datos de contexto para una sesión de TestStand, así como también las estaciones globales e información del usuario.

El Motor TestStand proporciona métodos que usted utiliza para crear otros objetos de TestStand, que se denotan con la palabra clave "new", como los siguientes métodos:

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

Para obtener una lista completa de las propiedades y métodos disponibles en el objeto Motor, consulte el tema Motor TestStand para obtener más información.

Cuando se completa la aplicación, debe apagar el Motor TestStand antes de salir de la aplicación. Se requiere un proceso de apagado de dos pasos para garantizar que el usuario tiene la oportunidad de terminar cualquier ejecución en proceso como se explica en Shutting Down the Engine en la ayuda de TestStand.

NI recomienda utilizar los controles de la interfaz de usuario de TestStand para desarrollar aplicaciones e interfaces de usuario de TestStand en lugar de crear directamente un objeto del Motor TestStand para reducir la complejidad de su programa. Los controles de la interfaz de usuario de TestStand proporcionan una capa de abstracción por encima de la API de TestStand que facilita el desarrollo de aplicaciones autónomas de TestStand. Consulte la sección de API de Controles de IU de este documento para obtener más información sobre el uso de los controles de IU.

Llamar a un Módulo de Código o Herramienta desde una Aplicación Existente

Al usar la API en un módulo de código o herramienta a la que llama desde otra aplicación TestStand, usted usa el Motor TestStand creado por la aplicación de nivel superior. Si se llama al código desde una secuencia de ejecución, como un módulo de código, esto se logra mejor usando un parámetro de entrada para el SequenceContext. Esto es preferible para pasar el Motor TestStand directamente porque el contexto de la secuencia proporciona acceso al estado actual de la ejecución además del objeto del motor TestStand.

El SequenceContext representa el estado de ejecución actual de una secuencia, proporcionando acceso a una imagen instantánea de todos los datos para una secuencia de ejecución en particular. Cada secuencia de ejecución en cualquier flujo tiene su propio SequenceContext.

Al navegar por la vista Variables, la lista que usted ve es la Sequence Context First-Level Properties, que incluye todos los tipos de variables, el paso actual y la propiedad RunState. El SequenceContext también proporciona referencias a muchos otros objetos como propiedades integradas.

RunState Versus SequenceContext

Las propiedades RunState y SequenceContext proporcionan acceso a muchos de los mismos objetos, como la ejecución actual, el flujo, el archivo de secuencia y la secuencia. Sin embargo, la propiedad RunState contiene estos objetos como propiedades dinámicas, a diferencia de SequenceContext que los expone como propiedades integradas.

Por este motivo, use la propiedad RunState cuando tiene acceso a información sobre el estado en las expresiones de TestStand, mientras que SequenceContext es más apropiado para los módulos de código, donde no puede tener acceso directamente a las propiedades dinámicas.

 SequenceContext proporciona información de estado de ejecución a través de propiedades integradas y dinámicas, mientras que la propiedad RunState proporciona información de estado solo a través de propiedades dinámicas.

Persistencia de los Datos de Secuencia

Antes de ejecutar los pasos en una secuencia, TestStand crea una copia en tiempo de ejecución de la secuencia para mantener valores de propiedades de pasos y variables locales independientes para cada invocación de secuencia. En la mayoría de los casos, cuando se tiene acceso a objetos desde Runstate o SequenceContext dentro de una secuencia de ejecución, los objetos son estas copias en tiempo de ejecución. Esto significa que cualquier cambio que realice en estos objetos no persistirá después de que finalice la ejecución, por ejemplo, al cambiar los valores de las variables locales o al crear una sub-propiedad de un parámetro mediante programación, no afectará el archivo de secuencia en el disco:

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

Los objetos que se heredan desde la clase PropertyObjectFile, como los objetos SequenceFile, no tienen una copia separada en tiempo de ejecución, por lo que los cambios que realice a través de estos objetos persistirán después de que se complete la ejecución. Por ejemplo, el acceso a la propiedad Locals a través del objeto SequenceFile le permite crear una variable local persistente.

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

Si bien la API de TestStand ofrece la capacidad de automatizar toda la funcionalidad de TestStand, hay algunas aplicaciones más comunes de la API:

• Crear Propiedades Personalizadas
• Crear Nuevos Archivos de Secuencia
• Modificar Secuencias Existentes

Crear Propiedades Personalizadas

Puede usar la API de TestStand para generar manera dinámica propiedades personalizadas en tiempo de ejecución, por ejemplo, para añadir datos de diagnóstico específicos a los resultados de la prueba si la prueba falla por un componente en particular o añadir datos personalizados al encabezado del reporte. 

Hay muchas formas de crear propiedades personalizadas a través de la API. Para los tipos de datos primitivos, el uso de los métodos "SetVal" con la opción InsertIfMissing proporciona el método más simple para crear nuevas propiedades. Por ejemplo, puede usar la siguiente expresión para añadir una nueva propiedad a un paso de prueba de límite numérico:

RunState.Sequence.Main["Numeric Limit Test"].AsPropertyObject.SetValString(
"Result.extraResult",
PropOption_InsertIfMissing,
"esta cadena es un resultado extra")

Para añadir una propiedad personalizada al reporte, también debe establecer el indicador IncludeInReport para el objeto, que el generador de reportes utiliza para elegir qué propiedades de resultados registrar:

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

Para obtener más detalles sobre el uso de la API para añadir datos al informe de prueba, consulte el ejemplo Adding Custom Data to a Report.

Para propiedades más complejas, como contenedores, deberá crear las propiedades directamente usando el método NewSubProperty (), que le permite crear contenedores, instancias de tipos de datos y arreglos. Por ejemplo, para crear una nueva variable local del tipo de error, debe usar la expresión:

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

Para obtener más detalles sobre el uso de la API para crear propiedades, consulte el ejemplo [Creating new properties using API].

Crear Nuevas Secuencias

Para automatizar el proceso de crear un archivo de secuencia basado en la información del usuario, puede utilizar la API de TestStand para generar nuevos archivos de secuencia o crear copias modificadas de un archivo existente. Por ejemplo, es posible que desee crear una herramienta que genere un archivo de secuencia de punto de inicio basado en cierta información del usuario o realice modificaciones específicas a los pasos en un archivo de secuencia existente.

Para obtener más información sobre crear nuevos archivos de secuencia utilizando la API, consulte el ejemplo Building a Sequence Using the API.

También puede utilizar la API de TestStand para desarrollar un Traductor de Archivos de Secuencia para generar archivos de secuencia utilizando un formato de archivo personalizado. Al crear un traductor de archivos de secuencia, usted utiliza la API de TestStand para generar archivos de secuencia, secuencias, pasos y propiedades en base a datos de un archivo que usted especifique. El framework del traductor le permite integrar este código con TestStand y abrir archivos directamente en un formato personalizado. 

Para obtener más información sobre el uso de traductores de secuencia de archivos, consulte Sequence File Translators en la ayuda de TestStand

Modificar Secuencias

Puede utilizar la API de TestStand en las herramientas personalizadas que usted utiliza para realizar modificaciones en los archivos de secuencia existentes. Por ejemplo, es posible que desee crear una herramienta que verifique los módulos de código que son especificados por una ruta absoluta y reemplazarlos por rutas relativas. 

Consulte el ejemplo Creating a Sequence File Iteration Tool para más información.

Además de la API Core TestStand, TestStand proporciona otras APIs que amplían la funcionalidad y proporcionan características adicionales:

• API de Controles de IU
• API del Adaptador
• API del Servidor de Sincronización

A diferencia de la API Core TestStand, estas API no son directamente accesibles a través de expresiones; usted las utiliza a través de un paso ActiveX o un módulo de código distinto.

API de Controles de IU

TestStand incluye un conjunto de controles de interfaz de usuario que le permiten desarrollar rápidamente interfaces de usuario de TestStand. Estos controles incluyen controles visibles para mostrar los datos de TestStand, como la Steps View o Variables View, así como los controles Invisible Manager, que manejan gran parte de la comunicación con la API del Motor TestStand en una interfaz de usuario de TestStand.

Al desarrollar una aplicación autónoma de TestStand, NI recomienda que utilice los controles de la interfaz de usuario para desarrollar la aplicación en lugar de crear una instancia del Motor TestStand directamente.

La API de Controles de IU le permite implementar tareas comunes de la interfaz de usuario a través de los controles del administrador, como abrir y ejecutar archivos de secuencia, responder a los mensajes de la interfaz de usuario y apagar la aplicación. La API de Controles de IU también proporciona métodos de conexión utilizados para configurar los controles de interfaz de usuario. 

Para obtener más información sobre el uso de los controles de la interfaz de usuario y la API de Controles de IU, consulte los siguientes temas de ayuda:

• TestStand UI Controls - Descripción general del uso de los controles de la interfaz de usuario para desarrollar aplicaciones de interfaz de usuario de TestStand.
• TestStand UI Controls API Reference Help - Referencia para las clases en la API de controles de interfaz de usuario.
• Best Practices for User Interface Development - Prácticas Recomendadas para el uso de los controles de interfaz de usuario y la API.

Puede pensar en los controles de interfaz de usuario de TestStand como una capa de software sobre la API del Motor TestStand. Estos controles encapsulan muchas de las funciones que usted necesita en una interfaz de usuario, como abrir secuencias, ejecutar pruebas, mostrar el progreso de la prueba, etc. Los Controles de IU de TestStand tienen muchas funciones e incluyen su propia API. Aunque hablar sobre la funcionalidad de los controles de la interfaz de usuario está fuera del alcance de este documento, es importante mencionar que estos controles proporcionan una funcionalidad además de la API del Motor TestStand.

API del Adaptador

La API del adaptador proporciona clases específicas para los diferentes adaptadores incluidos en TestStand. Por lo general, usted usa la API del adaptador para obtener información o funcionalidad específica del adaptador cuando usa las clases de adaptador o módulo en la API principal. En este caso, convierte el objeto a la clase de API del adaptador correspondiente. Por ejemplo, puede usar la clase LabVIEWModule para acceder a métodos y propiedades específicas de LabVIEW para el objeto de módulo en un paso de LabVIEW.

Utilice la API del adaptador para tener acceso a propiedades y métodos específicos del adaptador para las clases de Módulo o Adaptador

Referirse TestStand Adapter API Reference para obtener una lista de las clases proporcionadas en la API del adaptador

API del Servidor de Sincronización

La API del Servidor de Sincronización proporciona acceso directo a los objetos de sincronización de TestStand, como colas, bloqueos o notificaciones. Para usar esta API, primero obtiene una referencia del administrador de sincronización utilizando el método Engine.GetSyncManager. Después de convertir este objeto en la clase de administrador de sincronización definida en la API del servidor de sincronización, puede usarlo para tener acceso o crear nuevos objetos de sincronización.

Utilice SyncManager y la API del Servidor de Sincronización para crear y tener acceso a los objetos de sincronización de TestStand en el código

Esta API es útil cuando se desarrollan aplicaciones que se ejecutan junto con una prueba de TestStand y necesitan tener acceso a información sobre el estado de la ejecución, como una aplicación de monitoreo de estado.

Para obtener más información acerca de las clases disponibles, consulte el tema de referencia TestStand Synchronization Server.

Haga clic para ver otros documentos dentro de la Serie de Arquitectura Avanzada de TestStand que cubren temas de interés para los desarrolladores avanzados de NI TestStand.