Prácticas recomendadas para la administración de tipos de TestStand

TestStand utiliza diferentes categorías de tipos para almacenar información y definir el comportamiento de los pasos.  Los tipos de datos almacenan información durante el desarrollo y la ejecución de un sistema de pruebas, y los tipos de pasos definen el comportamiento de un paso y los resultados que el paso recopila durante la ejecución.  Tanto los tipos de datos como los tipos de pasos pueden incorporarse y enviarse con TestStand, o pueden ser tipos personalizados que el usuario desarrolle.

Los tipos de TestStand se clasifican en tipos de paso, tipos de datos personalizados y tipos de datos estándar.

Tipos de datos

En muchos casos, deberá definir estructuras de datos complejas para administrar sus datos de prueba.  Los tipos de datos le permiten administrar estas estructuras de datos en una ubicación centralizada.  Los tipos de datos definen la estructura de las propiedades o variables de TestStand, como las variables globales del archivo de secuencia, las variables locales de secuencia y las propiedades de paso.  Todos los tipos de datos tienen los siguientes componentes:

• Nombre del tipo: se utiliza para identificar de forma exclusiva el tipo.  TestStand nunca puede cargar más de un tipo del mismo nombre en la memoria.
• Versión: se utiliza para gestionar revisiones de tipos y resolver conflictos de tipos.
• Datos: la estructura de las propiedades definidas en el tipo.
• Valores predeterminados: los valores de propiedad que se definen en el panel de tipos actúan como valores predeterminados para las instancias del tipo.

Normalmente, se utilizan tipos de datos al definir un conjunto de datos complejos relacionados que contiene una serie de propiedades y contenedores diferentes.  Por ejemplo, un tipo de datos de error puede constar de tres propiedades: una propiedad booleana en el tipo que puede especificar si se ha producido un error, una propiedad de valor de cadena que puede contener el mensaje de error y una propiedad de entero que puede definir el código de error.

Siempre se deben utilizar un tipo de datos al administrar datos complejos, porque si modifica la estructura de un tipo de datos, todas las instancias de ese tipo de datos se actualizan para reflejar la nueva estructura del tipo de datos.  Esto le permite administrar la estructura de los datos en una ubicación centralizada.  

Tipos de datos estándar

Los tipos de datos estándar son un conjunto particular de tipos de datos que se envían con TestStand y que definen un formato estándar para almacenar tipos de datos comunes, como error, ruta o forma de onda.  No se pueden modificar la mayoría de los tipos de datos estándar. Aunque algunos se pueden modificar, solo debe hacerlo si es necesario, ya que otros componentes de TestStand utilizan estos tipos.  

Tipos de pasos

Del mismo modo que puede crear una variable o propiedad a partir de un tipo de datos personalizado, puede crear un paso a partir de un tipo de paso.  Cada tipo de paso consta de un nombre único, propiedades de tipo de paso integradas y personalizadas, y valores predeterminados para propiedades y operaciones de tipo de paso.  Todos los tipos de pasos comparten un conjunto común de propiedades que definen la operación básica y los datos para todos los pasos.  Use el cuadro de diálogo Propiedades de tipo de paso [Step Type Properties] para editar estas propiedades comunes.

Este documento se centra en conceptos que se aplican a todos los tipos, incluidos los tipos de paso y datos.  Para obtener información específica sobre las prácticas recomendadas relativas a los tipos de pasos, consulte el documento Prácticas recomendadas para el desarrollo de tipos de pasos personalizados.

Al crear tipos nuevos, es importante tener en cuenta la ubicación en el disco donde se almacena el tipo. TestStand puede almacenar tipos en archivos de secuencia o en archivos de paleta de tipos.  En la mayoría de los casos, debe almacenar cualquier tipo que cree en un archivo de paleta de tipos. El uso de una paleta de tipos ofrece los siguientes beneficios:

• Los archivos de paleta de tipos proporcionan una ubicación centralizada para almacenar tipos en varios archivos de secuencia.
• Los archivos de paleta de tipos se pueden configurar para cargarse en la memoria cuando se inicia TestStand, lo que garantiza que los tipos estén disponibles para cualquier archivo de secuencia nuevo.
• El hecho de tener una única ubicación centralizada para los tipos ayuda a evitar los conflictos de tipos que pueden surgir cuando varios desarrolladores hacen cambios en los tipos almacenados en varias ubicaciones.
• De forma predeterminada, TestStand no actualiza automáticamente ningún tipo en una paleta de tipos, lo que protege contra la propagación de tipos no deseados.

Al utilizar un tipo de un archivo de paleta de tipos en un archivo de secuencia, se almacena una copia del tipo en el archivo para asegurarse de que funcionará incluso sin el archivo de paleta de tipos. Sin embargo, solo debe hacer cambios en el tipo utilizando la versión de la paleta de tipos.  Al implementar la secuencia de prueba, no es necesario incluir archivos de paleta de tipos en la implementación.  Sin embargo, incluir el archivo de paleta de tipos le permitirá realizar actualizaciones incrementales al sistema de prueba con mayor facilidad.  Si se requieren actualizaciones en determinados tipos, puede crear e implementar una nueva versión del archivo de paleta de tipos sin necesidad de hacer ningún cambio en los archivos de secuencia.

Al compartir tipos entre varios desarrolladores, es importante asegurarse de que cada desarrollador utilice la misma versión más reciente de la definición de tipo. También debe asegurarse de que los desarrolladores no hagan cambios por separado en el mismo tipo, ya que es difícil fusionar los cambios en los tipos.  Use las siguientes técnicas para administrar los tipos compartidos de manera eficaz:

• Defina un propietario para los archivos de paleta de tipos.
• Utilice el control de código fuente para paletas de tipos.

Definir la propiedad de los archivos de paleta de tipos

Para controlar los cambios en los tipos, es importante establecer un propietario claro para cada tipo, que implemente o apruebe cualquier cambio en los tipos.  En una organización de gran tamaño, a menudo es conveniente asignar la propiedad del tipo a diferentes individuos del grupo.  Para facilitar este método, cree archivos de paleta de tipos independientes para organizar los tipos en grupos lógicos; por ejemplo, puede almacenar tipos específicos de un proyecto en una paleta de tipos que contiene el nombre del proyecto, y puede guardar los tipos más generales que utiliza en varios proyectos en un archivo de paleta de tipos compartido.  A continuación, puede determinar un propietario para cada tipo de archivo de paleta.

La organización de archivos de paleta de tipos en grupos lógicos le permite asignar los propietarios de los tipos a cada archivo de paleta de tipos con mayor facilidad.

Utilizar el control de código fuente para restringir los cambios en los archivos de paleta de tipos

Para controlar aún más los cambios en las versiones de tipo, use una solución de control de código fuente para asegurarse de que los archivos solo se puedan editar si están seleccionados.  Puede usar los permisos de control de código fuente para asegurarse de que solo el propietario de un archivo de paleta de tipos en concreto tenga la capacidad de registrar los cambios.  Como mínimo, el propietario de la paleta de tipos debe habilitar las notificaciones relativas a los archivos, de modo que esté al tanto de cualquier actividad relacionada con el archivo.

Aunque los usuarios aún podrán modificar los tipos en su máquina local, el uso del control de código fuente impide que TestStand guarde estos cambios en el disco o en la versión compartida del archivo.  

Impedir conflictos entre tipos no relacionados

Uno de los modos en que pueden surgir conflictos de tipos es cuando varios tipos no relacionados entre sí tienen el mismo nombre por accidente. Debido a que los tipos usan su nombre como un identificador único en el sistema, cuando desarrolle nuevos tipos, anteponga un ID de organización único al nombre del tipo.  Por ejemplo, todos los nombres de los tipos de pasos que se envían con TestStand comienzan con el prefijo “NI”.  Esto garantiza que sus tipos no entren en conflicto con aquellos creados fuera de su organización si el código se comparte entre grupos.

TestStand carga solo una versión de un tipo con un nombre determinado a la vez para garantizar que se use la misma información de tipo en todos los archivos cargados en la estación.  Si intenta abrir un archivo de secuencia o cargar una paleta de tipos que contiene un tipo con el mismo nombre que ya está cargado, se produce un conflicto de tipo, donde TestStand debe determinar si se debe mantener el tipo actual cargado o si se debe reemplazar con el tipo nuevo.  

Se produce un conflicto de tipo cuando se intenta cargar un archivo que contiene una definición que es diferente de la que está cargada en ese momento en TestStand.  El conflicto debe resolverse antes de que se pueda cargar el nuevo archivo.

Si los desarrolladores tienen cuidado a la hora de conservar nombres de tipo únicos y de conservar los tipos en un único archivo de paleta de tipos controlado, TestStand podrá manejar correctamente los conflictos de tipos.  Sin embargo, los conflictos de tipos pueden causar cambios incorrectos en sus archivos basados en reglas automáticas de resolución de conflictos de tipos o decisiones incorrectas de los desarrolladores, lo que puede conducir a la propagación de versiones de tipos no deseados.  

Propagación de versiones de tipos no deseados

La propagación de tipos no deseados describe el caso cuando la resolución de un conflicto de tipo provoca cambios no deseados en los archivos que contienen una versión diferente de un tipo. Cuando se comparten archivos con el tipo incorrecto, otros desarrolladores pueden cargar sin saberlo la versión incorrecta del tipo.  A medida que los archivos se comparten entre más desarrolladores, el nuevo tipo se propaga a muchos archivos y puede ser difícil encontrar todos los archivos con el tipo incorrecto.
Esta situación puede darse al resolver conflictos que surgen en los casos siguientes:

• Cuando se carga un tipo en una versión anterior de TestStand en la que el tipo es incompatible.
• Cuando se crean varios tipos no relacionados con el mismo nombre.
• Cuando hay varios desarrolladores que hacen cambios paralelos a un tipo.

Utilice las técnicas que se muestran de esta sección para minimizar los casos en los que los conflictos de tipos se manejan incorrectamente y evitar la propagación de versiones de tipos no deseados.

Mantenimiento del campo de versión del tipo

Los tipos de TestStand utilizan el campo de versión para determinar qué versión de un tipo es la más reciente.  Si se carga la versión más reciente del tipo en la memoria y usted carga un archivo de secuencia que usa una versión anterior del tipo, TestStand puede actualizar automáticamente el archivo para usar la versión de tipo más reciente, según la configuración de la estación.  De forma predeterminada, TestStand resuelve automáticamente cualquier conflicto que no actualice los tipos en los archivos de paleta de tipos.

Para ayudar a garantizar que las versiones de tipo se actualicen, TestStand hace un seguimiento de los tipos que edita mediante el indicador de tipo modificado.  Si guarda un tipo con este indicador habilitado, TestStand muestra una advertencia que señala que se han realizado cambios.  

TestStand avisa cuando se hacen modificaciones en los tipos para garantizar que los cambios son intencionados antes de guardarlos.

En este caso, debe incrementar las versiones de tipo, lo que garantizará que los cambios que realice se propaguen a otros archivos que hagan referencia al tipo cuando se cargan en TestStand.  Sin embargo, no debe seleccionar la opción para guardar la configuración y no solicitarla, ya que esta advertencia es una herramienta útil para impedir cambios no deseados en los tipos.  Si tiene dudas en cuanto al cambio, al cancelar el diálogo se cancelará la operación de guardado, lo que le permitirá inspeccionar el tipo y asegurarse de que los cambios son válidos.

Configurar la resolución automática de conflictos de tipos

En algunos casos, TestStand puede determinar automáticamente qué tipo debe cargarse en caso de conflicto de tipos.  La resolución automática de conflictos de tipos solo es posible cuando se cumplen estas condiciones:

• Las versiones de tipo no son las mismas para los dos tipos.
• El indicador “modificado” no está configurado para ninguno de los tipos.

TestStand proporciona la configuración Permitir resolución automática de conflictos de tipos [Allow Automatic Type Conflict Resolution] para que pueda determinar cuándo resolverá TestStand estos conflictos automáticamente.  Para acceder a esta configuración, haga lo siguiente:

1. En el editor de secuencia, seleccione Configurar » Opciones de estación [Configure » Station Options].
2. Seleccione la pestaña Archivo [File].

TestStand le permite configurar cuándo los conflictos de tipos se manejan automáticamente y cuándo se le solicita al desarrollador que elija la versión de tipo que se debe guardar en la memoria.

En la mayoría de los casos, debe utilizar el valor predeterminado de esta configuración, que consiste en preguntar únicamente si se modificará un archivo de paleta de tipos.  Esta configuración permitirá que TestStand elija automáticamente el tipo con la versión superior, siempre que el tipo de versión inferior no se almacene en un archivo de paleta de tipos.  Esta configuración ayuda a garantizar que la solicitud de conflicto de tipo solo aparezca cuando se produzca una posible propagación de tipos no deseados.  También asegurará que los conflictos innecesarios, como la carga de un archivo de secuencia antiguo con tipos antiguos de NI en una nueva versión de TestStand, se resuelvan de forma automática y no requieran que el usuario tome una decisión.

Por ejemplo, el desarrollador A actualiza el tipo de paso “RunCalibration”, un tipo almacenado en el archivo de paleta de tipos de compañía, Company_types.ini.  Tras analizar esto con el propietario del archivo de paleta de tipos, guardan el cambio en el tipo y seleccionan incrementar la versión del tipo a 1.0.1.0.  A continuación, guardan la paleta de tipos actualizada en el repositorio de control de código fuente.  Después, el desarrollador B se sincroniza con el repositorio, obteniendo la versión de Company_types.ini con el tipo actualizado.  Abren TestStand y cargan un archivo de secuencia que hace referencia al tipo.  Dado que el archivo de secuencia todavía hace referencia a la versión de tipo anterior, la referencia en el archivo de secuencia se actualiza automáticamente, que es el comportamiento deseado.

Sin embargo, un tercer desarrollador C también tiene un archivo de secuencia que utiliza el paso “RunCalibration” y, sin darse cuenta, realiza un cambio por separado al tipo de paso “RunCalibration” sin consultar al propietario del tipo, actualizando su instancia local a la versión 1.1.0.0.  Si este desarrollador sincroniza el archivo de paleta de tipos de la compañía y carga su archivo de secuencia en TestStand, TestStand le pedirá que resuelva el conflicto de tipos, ya que el tipo se modificará si se utiliza la versión más reciente.  El desarrollador C sabrá que el archivo de la paleta de tipos se ha actualizado y lo consultará con el propietario de la paleta de tipos o revertirá los cambios locales que hizo en el tipo.

Si TestStand no puede resolver automáticamente el tipo de conflicto, se le pedirá que decida cómo resolver el conflicto:

Utilizar el cuadro de diálogo Conflicto de tipo en archivo [Type Conflict In File] para resolver conflictos de tipos que no se pueden resolver automáticamente.

Para resolver el conflicto de tipo, puede elegir cargar uno de los dos tipos, cambiar el nombre de uno de los tipos o cancelar la apertura del archivo.  Cuando selecciona la versión que se va a utilizar, TestStand convierte todas las instancias en la memoria para que coincidan con el tipo que ha seleccionado. Si cambia el nombre de uno de los tipos, TestStand modifica las instancias en la memoria para referirse al tipo cargado, y las instancias en el nuevo archivo para referirse al tipo en el archivo.

Establecer la configuración de resolución de conflictos específicos de tipos

En un entorno estrictamente controlado, puede verse tentado a seleccionar la opción Solicitar siempre al usuario que resuelva el conflicto [Always prompt the user to resolve the conflict] para deshabilitar la resolución automática de conflictos de tipos en todos los casos. Esto le indicará al usuario que resuelva el conflicto en cualquier caso que se detecte un tipo de conflicto, lo que le permite tener control total sobre los tipos que se cargan.  Sin embargo, esto añade una toma de decisiones al proceso de desarrollo, lo que puede hacer que los desarrolladores tomen decisiones incorrectas y descarten rápidamente la gran cantidad de diálogos que encontrarán.  

Un método más adecuado consiste en utilizar la configuración específica del tipo en los tipos que requieren un control estricto.  Esta opción, que se encuentra en la pestaña Versión [Version] de la configuración Tipo [Type], permite especificar si el tipo puede resolverse automáticamente.  El uso de esta configuración evita la interacción innecesaria del usuario en conflictos de tipos de bajo riesgo, como la carga de un archivo de secuencia anterior con tipos de NI más antiguos en una nueva versión de TestStand, al tiempo que proporciona un control total sobre los tipos personalizados estrictamente controlados.

Deshabilitar la resolución automática de conflictos de tipos para tipos específicos que requieren un control más estricto.

Evitar la propagación de versiones de tipos no deseados a versiones anteriores de TestStand

Debido a que se pueden guardar archivos de secuencia en versiones anteriores de TestStand, pero es posible que algunos tipos no se ejecuten correctamente en versiones anteriores de TestStand, puede especificar la versión más antigua de TestStand que puede ejecutar un tipo. Habilite la opción Establecer la versión más antigua de TestStand que puede usar este tipo [Set Earliest TestStand Version that can Use this Type] en la pestaña Versión [Version] del cuadro de diálogo Propiedades de tipo [Type Properties] y establezca la versión más antigua en la versión actual de TestStand. Esto evitará que la versión actual de un tipo se use o se propague accidentalmente a una versión anterior de TestStand.

Si necesita que un tipo esté disponible en versiones anteriores de TestStand, cree varias versiones del tipo para ejecutarlas en diferentes versiones de TestStand. Cuando guarda una secuencia para una versión anterior de TestStand, TestStand busca en un conjunto de directorios de compatibilidad para encontrar la versión de tipo que es compatible con la versión anterior en la que desea guardar el archivo de secuencia. TestStand guarda los tipos de los archivos de paleta de tipos en los directorios <TestStand Public>\Components\Compatibility\<número de versión> y <TestStand Public>\Components\Compatibility\<número de versión> con el archivo de secuencia. Puede colocar archivos de paleta de tipos de versiones anteriores de TestStand en el directorio <TestStand Public>\Components\Compatibility\<número de versión> para asegurarse de que TestStand guarda la versión correcta de los tipos con el archivo de secuencia.

Los desarrolladores deben ser cautelosos al personalizar los tipos de datos integrados, incluidos los tipos de datos estándar y los tipos de datos del modelo de proceso.  Otros tipos de datos o tipos de pasos de TestStand utilizan muchos tipos integrados, como CommonResults, lo que aumenta el potencial de propagación de tipos no deseados.

Aspectos a tener en cuenta al personalizar tipos de datos estándar

No personalice los tipos integrados si está creando archivos de secuencia o archivos de paleta de tipos que se distribuirán como productos de terceros o se utilizarán en varias organizaciones. Los archivos con tipos integrados modificados deben permanecer dentro de una sola organización que tenga conocimiento de los cambios de tipo.  Si se distribuyen los archivos de secuencia o las paletas de tipos, otras organizaciones heredarán sus personalizaciones de tipos o se toparán con conflictos si la versión de la otra organización de estos tipos se carga en sus archivos.  

Dado que los cambios en los tipos incorporados tienen tal impacto en cualquier estación de prueba en la que se utilicen, asigne un desarrollador o arquitecto central que comprenda la arquitectura de prueba de las organizaciones para aprobar los cambios y reducir los problemas de administración de tipos.

Aspectos a tener en cuenta al personalizar tipos de datos del modelo de proceso

Los modelos de proceso y las secuencias de plug-in de TestStand utilizan una variedad de tipos de datos para definir las estructuras de datos del modelo de proceso.  Por ejemplo, el tipo de datos UUT contiene datos como el número de serie, el número de pieza y el índice de socket de prueba.  Si bien puede personalizar estos tipos, solo debe hacerlo cuando sea necesario.  Los tipos de modelo de proceso se definen solo en archivos de secuencia y no tienen una paleta de tipos central.  Por esta razón, la propagación de tipos no deseados puede producirse con mayor facilidad en estos tipos, ya que la configuración predeterminada de la resolución automática de conflictos permitirá a TestStand actualizar estos tipos automáticamente.
Si necesita añadir datos adicionales a la UUT o a los tipos de datos NI_StationInfo, puede utilizar la propiedad AdditionalData, que es un contenedor no estructurado definido en el tipo, para añadir datos extra a las instancias del tipo en tiempo de ejecución.  Para obtener más información sobre este método, consulte el tema de ayuda Almacenar información adicional para UUT y estaciones de prueba en modelos de proceso.

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