Prácticas recomendadas para el desarrollo de sistema TestStand

Un sistema de pruebas suele ser complejo y contiene muchos componentes y archivos, todos los cuales deben implementarse adecuadamente para garantizar que la prueba se ejecute sin problemas en un sistema de producción. En este documento, tendremos en cuenta únicamente los componentes de software que se utilizan para probar un producto.

Los sistemas TestStand tienen muchos componentes que deben incluirse en una implementación

Los componentes principales de un sistema de pruebas de TestStand son Código de pruebas, Archivos de marco de trabajo de prueba y Controladores y motores en tiempo de ejecución.

Código de pruebas

El código de pruebas incluye los archivos de secuencia y los módulos de código que crea para implementar las pruebas reales. Al implementar el código de prueba, debe asegurarse de que se incluyan todas las dependencias requeridas de sus módulos de código y que los archivos se implementen en las ubicaciones adecuadas del disco para que las personas que llaman puedan encontrarlos. Por lo general, el código de prueba incluye uno o más archivos de secuencia junto con los archivos a los que hacen referencia. 

Archivos de secuencia

Los archivos de secuencia dependen de los módulos de código a los que llaman, de las dependencias de los archivos de secuencia y de los archivos complementarios como, por ejemplo, los archivos del cargador de propiedades. Puede usar la Utilidad de implementación TestStand para analizar archivos de secuencia y enumerar estas dependencias. La Utilidad de implementación TestStand no reconocerá las dependencias referenciadas dinámicamente, como un archivo de propiedades especificado por la expresión TestStand, o los archivos referenciados implícitamente, como la documentación de la prueba.

Siempre que sea posible, debe almacenar todos los archivos dependientes de un archivo de secuencia determinado en un subdirectorio situado bajo la ruta del archivo de secuencia. Esta estructura tiene las ventajas siguientes:

• Se puede hacer referencia a los archivos mediante una ruta relativa al archivo de secuencia actual, lo que garantiza que las rutas sigan siendo válidas si copia el archivo de secuencia y las dependencias a otra ubicación.
• El seguimiento de las dependencias dinámicas e implícitas es mucho más sencillo, ya que se puede implementar el directorio de dependencias como un todo.

También hay que tener en cuenta las dependencias de los propios módulos de código. El proceso de implementación de estas dependencias varía según el tipo de módulo.

Módulos de código de LabVIEW

Los módulos de código de LabVIEW incluyen VI, llamadas de miembros de clase de LabVIEW, llamadas de Express VI y llamadas de nodo de propiedad. Para ejecutar módulos de código de LabVIEW en un sistema sin el sistema de desarrollo de LabVIEW instalado, debe asegurarse de que todas las dependencias de los módulos de código de VI se guarden en la misma versión de LabVIEW. También necesitará incluir cualquier VI dependiente enviado con el sistema de desarrollo de LabVIEW, como los presentes en los directorios vi.lib o instr.lib de la instalación de LabVIEW. Puede usar los siguientes enfoques para asegurarse de que se cumplan ambas condiciones:

• Crear una distribución de origen de LabVIEW para todos los VI del módulo de código y asegurarse de que las opciones para excluir vi.lib, instr.lib y user.lib no estén seleccionadas. Para impedir los enlaces cruzados entre los VI de origen y los VI de la distribución de origen, asegúrese de agregar los archivos a una nueva biblioteca de proyectos.
• Crear una o más bibliotecas de proyectos en paquete (PPL) para sus archivos de origen. Una PPL es un único archivo compilado que contiene todos los VI y sus dependencias. Con este enfoque, puede actualizar las implementaciones existentes al reemplazar una PPL implementada con una versión actualizada.

* Las PPL no incluyen dependencias que son DLL o VI que ya están compiladas en una PPL.

Para gestionar gran parte de este proceso de forma automática, puede usar la Utilidad de implementación TestStand para implementar sus archivos de secuencia que llaman a los módulos de código de LabVIEW. La Utilidad de implementación TestStand guarda todos los VI en una única versión de LabVIEW e incluye las dependencias requeridas que forman parte del ADE de LabVIEW. La utilidad de implementación también puede generar opcionalmente una Biblioteca de proyectos en paquete (PPL). Para obtener más información, consulte Implementación de VI en las bibliotecas de proyectos en paquete de LabVIEW.

Dependencias de DLL de C/C++

Por lo general, cualquier DLL dependiente se copiará en el directorio de compilación o son DLL del sistema que se incluyen con los motores en tiempo de ejecución requeridos. Cuando sea posible, no debe implementar DLL u otros archivos binarios directamente en los directorios del sistema Windows, sino determinar el software que instala estas dependencias e incluirlo en su implementación. Consulte la sección Controladores y tiempos de ejecución que aparece a continuación para obtener más información sobre la implementación de software adicional.

Dependencias .NET

Como la DLL C/C++ no administrada, las DDL .NET administradas son código compilado que puede ejecutarse sin un ADE. A diferencia de las DLL C/C++, los ensamblados .NET pueden hacer referencia a ensamblados dependientes en la caché de ensamblados global (GAC), que puede incluir ensamblados instalados con controladores o software de tiempo de ejecución, pero también puede incluir su propio código.

Al compilar ensamblados .NET, puede usar la propiedad “Copy local” para ensamblados referenciados para incluir una copia de ellos junto a su ensamblado. Al hacerlo, puede garantizar que se implementan las dependencias .NET al implementar la carpeta que contiene sus ensamblados y dependencias.

Archivos de marco de trabajo de prueba

Además del código de prueba, también debe implementar los archivos de marco de trabajo de TestStand. Si incluye TestStand Runtime en su implementación, las versiones predeterminadas de estos archivos se instalarán en el sistema. Sin embargo, si tiene versiones personalizadas de estos componentes, deberá incluirlos en la implementación del sistema de pruebas. 

Archivos de configuración de TestStand

Los archivos de configuración de TestStand almacenan la configuración de la instalación local de TestStand.  Estos archivos describen y guían el comportamiento de un sistema de pruebas. Los archivos de configuración de TestStand se encuentran en el directorio <TestStand Application Data>\Cfg.

Para obtener detalles sobre los archivos de configuración que se incluyen con TestStand y la información que se almacena en cada archivo, consulte el tema de ayuda Archivos de configuración.

Componentes de TestStand

Los componentes de TestStand son características que implementan la ejecución de alto nivel del sistema de pruebas y se desacoplan de la secuencia de prueba para mejorar la modularidad de la arquitectura TestStand. Los componentes de TestStand implementan características como la funcionalidad de inicio y cierre de sesión, informes, registro de base de datos e ingreso de número de serie. Estos archivos se encuentran ubicados en el directorio <TestStand>\Components.

Para obtener detalles de los elementos en el directorio de componentes de TestStand, consulte el tema de ayuda Directorio de componentes

Interfaces de usuario de TestStand

Para ejecutar secuencias en una máquina implementada, deberá implementar al menos una interfaz de usuario, ya que el Editor de secuencia solo está disponible en máquinas de desarrollo. Las interfaces de usuario pueden ser simples o pueden estar muy personalizadas, según sus necesidades. TestStand incluye aplicaciones de interfaz de usuario que puede implementar en <TestStand Public>/UserInterfaces.

Para obtener información específica sobre la creación de interfaces de usuario de TestStand para su uso en máquinas desplegadas, consulte el documento Prácticas recomendadas para el desarrollo de la interfaz de usuario de TestStand de NI.

Controladores y motores en tiempo de ejecución

Para ejecutar secuencias y código de pruebas en un sistema de producción, debe asegurarse de que estén instalados todos los motores en tiempo de ejecución (tiempos de ejecución) y controladores de hardware necesarios. Se requieren motores en tiempo de ejecución para que se ejecuten los componentes de software, como los DLL, VI y los archivos de secuencia. Se requieren controladores para los componentes de hardware utilizados por el sistema de pruebas. Siempre necesitará implementar el tiempo de ejecución de TestStand, que contiene el motor TestStand y los archivos de soporte. 

Si en la implementación utiliza la Utilidad de implementación TestStand, puede elegir detectar e incluir la versión requerida de controladores y tiempos de ejecución a los que hacen referencia los módulos de código. Si no incluye el tiempo de ejecución, la Utilidad de implementación TestStand proporciona en su lugar un mensaje de registro informativo que indica qué versiones deben incluirse en la implementación.

Licencias de software

Debe asegurarse de que haya licencias de software adecuadas para las máquinas implementadas. Cada máquina implementada requiere, como mínimo, una licencia de implementación básica, que permite la ejecución de la secuencia, pero no el desarrollo. Muchos motores en tiempo de ejecución, como LabVIEW y LabWindows/CVI Runtimes, no tienen ningún requisito de licencia. Debe consultar la documentación de todo componente adicional que implemente para asegurarse de obtener las licencias de implementación necesarias. Consulte el tema de ayuda Sección de licencias de implementación de las licencias de implementación y depuración para software de NI para obtener una lista de todos los productos de NI que requieren licencias en aplicaciones implementadas.

Si lleva a cabo la implementación en una gran cantidad de ordenadores de producción, NI proporciona licencias por volumen, lo que le permite administrar licencias a través de un servidor central de licencias. Para obtener más información sobre las opciones de licencias por volumen, consulte la página Programa de licencias por volumen para software.

Una vez que haya definido el conjunto de archivos que debe incluir en la implementación de su sistema de pruebas, deberá elegir un mecanismo para distribuir los archivos a los ordenadores de producción. A continuación se describen los siguientes mecanismos de implementación:

• Implementación basada en paquetes de NI
• Implementación basada en el instalador
• Implementación de unidad de red

Implementación basada en paquetes de NI

Los paquetes de NI proporcionan un mecanismo para consolidar todos los archivos de la implementación en un solo archivo, que puede implementar y extraer en las ubicaciones correctas en los ordenadores de producción mediante el NI Package Manager. Puede usar la Utilidad de implementación TestStand para crear un paquete que contenga todos los archivos de la implementación. En el caso de las implementaciones basadas en paquetes, los controladores y componentes que se requieren para la implementación se mencionan como dependencias del paquete, pero no se incluyen en el paquete en sí. 

Al instalar el paquete en un ordenador de producción, NI Package Manager detectará estas dependencias y le permitirá descargar e instalar estos paquetes. También puede usar el software SystemLink para proporcionar un repositorio de paquetes de NI dentro de su organización, incluidos los paquetes de NI que cree. Para obtener más información sobre el uso de SystemLink para administrar implementaciones basadas en paquetes, consulte ¿Cómo configurar sistemas e implementar software con SystemLink?

Dado que cada paquete de NI es un componente único, puede actualizar una implementación basada en paquetes al crear una nueva versión del paquete con un número de versión actualizado. Una vez probada y validada la nueva versión, puede distribuirla a los ordenadores de producción a través de una transferencia de archivos convencional o mediante SystemLink.

Implementación basada en el instalador

Otra forma de implementar archivos consiste en crear un instalador que contenga todos los componentes necesarios de la implementación, que se pueden copiar e instalar en los ordenadores de la estación de prueba. A diferencia de los paquetes, los instaladores pueden incluir controladores y componentes necesarios dentro del instalador. La inclusión de estos componentes hace que el instalador tenga un tamaño mucho mayor en el disco, pero garantiza que los controladores y los motores en tiempo de ejecución se incluyan y estén siempre disponibles. La Utilidad de implementación TestStand le permite crear un instalador en su sistema TestStand sin tener conocimientos previos de la tecnología del programa de instalación de Microsoft, y ofrece las siguientes características:

• Permite distribuir archivos a directorios específicos en el ordenador de destino, como el directorio <TestStand> o el directorio <Desktop>.
• Permite importar la configuración de hardware que se genera en Measurement and Automation Explorer (MAX).
• Permite incluir componentes adicionales, como controladores y tiempos de ejecución. 
•  Permite crear instaladores de parches para aplicar actualizaciones a una implementación existente.

Para obtener más información sobre las características disponibles en la Utilidad de implementación TestStand, consulte el tema Creación de un instalador con la Utilidad de implementación TestStand en la ayuda de TestStand. En la mayoría de los casos, la Utilidad de implementación TestStand proporciona las características necesarias para crear un instalador de implementación personalizado. Si necesita un control adicional del comportamiento del instalador de implementación, puede crear un instalador mediante herramientas de terceros. Consulte Creación de un instalador con herramientas de terceros para obtener más información sobre los casos en los que esto puede ser necesario.

Para aplicar actualizaciones a un instalador existente, puede usar la Utilidad de implementación TestStand y crear un instalador de parches, que solo incluye componentes actualizados. Para obtener más información sobre la creación de instaladores de parches, consulte el tema de ayuda Implementaciones de parches. Además, plantéese crear varios instaladores para modularizar la implementación, por ejemplo, tener instaladores separados para el código de pruebas, los componentes de TestStand y los controladores y motores en tiempo de ejecución. Con este enfoque, puede actualizar y distribuir solo los instaladores que tienen cambios.

Dado que los instaladores colocan automáticamente los archivos en las ubicaciones correctas y pueden incluir los controladores y los motores en tiempo de ejecución necesarios, es sencillo implementar el sistema una vez que se crea un instalador de trabajo. Sin embargo, debido a que la implementación basada en el instalador se debe trasladar e instalar en cada ordenador de prueba, por lo general son más adecuados para las implementaciones que se utilizan en un número menor de ordenadores de prueba. 

Implementación de unidad de red

Con las arquitecturas de implementación de unidad de red, los archivos se comparten con los ordenadores de la estación de prueba utilizando directamente una unidad de red, sin consolidación en un instalador. El acceso a los archivos en la unidad de red se puede administrar con una solución de control de código fuente. Con este enfoque, los desarrolladores de pruebas crean y actualizan archivos en el repositorio compartido. Una vez finalizadas las pruebas, estos archivos se copian en máquinas de producción o se usan directamente desde la ubicación de red. 

Con una estrategia de implementación de unidad de red, puede usar un repositorio compartido para compartir archivos entre ordenadores de desarrollo, almacenamiento provisional y producción.

Al desarrollar un código de pruebas nuevo, es importante asegurarse de que el código en desarrollo nunca se use en sistemas implementados hasta que se haya probado y validado. Por lo general, un ordenador de producción con acceso al hardware de prueba se designa como un probador de ensayos y se usa para validar y probar sistemas de pruebas previos al lanzamiento. Una vez que el sistema de prueba ha sido validado en el probador de ensayos, se puede implementar en máquinas de producción.

El mejor enfoque para garantizar que el código implementado se valide varía según la frecuencia con la que se deben aplicar las actualizaciones a las estaciones de prueba.

Para los casos en los que se necesitan actualizaciones frecuentes, un enfoque de Integración y Entrega Continua (CI/CD) puede ayudar a garantizar que el último código esté disponible en los ordenadores de prueba, al tiempo que garantiza que el código se haya probado y validado correctamente. Con un enfoque de CI/CD, se automatiza gran parte del procedimiento para construir, probar e implementar actualizaciones del código de pruebas a fin de reducir la sobrecarga tanto como sea posible. Puede usar herramientas de terceros, como Jenkins, para implementar este tipo de automatización. 

Para entornos controlados más estrechamente, los requisitos de validación suelen ser muy estrictos y, por lo tanto, las actualizaciones del sistema de pruebas no pueden producirse con frecuencia. En estos sistemas de pruebas, defina un repositorio o tronco separado donde los desarrolladores realicen cambios y agreguen nuevas características a la prueba. Una vez que se ha finalizado y validado la última versión del sistema de pruebas, los desarrolladores crean una rama versionada del tronco para su uso en máquinas de producción. Esta rama debe estar bloqueada dentro del control del código fuente para evitar cualquier cambio en el código validado. Una vez que se completa y se valida la nueva rama, cree una nueva rama versionada que contenga el código.

Para implementar el código de pruebas, las máquinas de producción obtienen una copia del código versionado, que debe permanecer como de solo lectura para garantizar que no se modifique. Para garantizar aún más que no se realicen cambios en los archivos validados, puede agregar código a la secuencia de prueba para validar las sumas de verificación de todos los archivos. Para obtener más información sobre este enfoque, consulte el documento Prácticas recomendadas para la verificación y validación de sistemas de TestStand.

Implementar controladores y motores en tiempo de ejecución con implementaciones de unidades de red

Cuando utilice un enfoque basado en unidades de red, deberá utilizar un mecanismo separado para instalar los controladores y tiempos de ejecución necesarios en los ordenadores de prueba. Los motores en tiempo de ejecución y los controladores se pueden implementar a través de los siguientes mecanismos:

• Crear un instalador que contenga el software requerido. La Utilidad de implementación TestStand puede generar un instalador que incluye motores en tiempo de ejecución y controladores.
• Crear una imagen del sistema basada en un sistema con todos los controladores y tiempos de ejecución necesarios instalados.

El mejor enfoque depende principalmente de la frecuencia de las actualizaciones del sistema. En muchos casos, puede usar una combinación de varios enfoques. Los siguientes escenarios comunes ilustran la elección de una estrategia para la implementación del controlador y el tiempo de ejecución:

• Para sistemas con actualizaciones poco frecuentes, la creación de una imagen suele tener un ROI positivo. Las actualizaciones pequeñas para el sistema de pruebas se pueden implementar sin la necesidad de actualizar la imagen.
• Para los sistemas que se actualizan con más frecuencia, cree un instalador para su sistema de pruebas con los controladores y tiempos de ejecución necesarios.

Estrategias para acceder a los archivos del sistema de pruebas

Con una implementación de unidad de red, puede usar uno de los siguientes enfoques generales para administrar el almacenamiento de archivos:

• Acceder a los archivos directamente desde la unidad de red.
• Copiar archivos localmente desde la unidad de red, utilizando herramientas de terceros para garantizar que los archivos locales estén sincronizados con la unidad.
  
  

Acceder a los archivos directamente desde la unidad de red

La ventaja de acceder a los archivos directamente desde una unidad de red es que, cuando los archivos se actualizan en la unidad de red, se asegura de que la actualización se aplique a todos los ordenadores de prueba. Sin embargo, el acceso a los archivos directamente desde una unidad de red significa que el funcionamiento de las estaciones de prueba dependerá de la disponibilidad de la unidad compartida y de la conexión de red. Si ninguno de los dos está disponible, los operadores de fabricación no pueden ejecutar archivos de prueba desde la estación de prueba, lo que puede causar paradas en la línea de producción. Por lo tanto, es fundamental que trabaje con su departamento de TI para asegurarse de que puedan cumplir con los requisitos de tiempo de operación tanto para la unidad compartida como para la red. Por ejemplo, mediante la redundancia del servidor para cumplir con los requisitos de tiempo de operación de la unidad compartida. 

Si desea utilizar una unidad compartida para almacenar archivos y componentes de configuración de TestStand, debe usar la característica de entornos TestStand, que le permite especificar la ubicación de los directorios de TestStand. Para ello, cree un archivo de entorno (tsenv) que contenga la ubicación de la unidad de red para estos directorios. Para obtener información sobre cómo crear y usar este archivo, consulte el tema de ayuda de Entornos TestStand.

Copiar archivos localmente a cada estación de prueba

También puede optar por crear copias locales de todos los archivos de implementación. Este enfoque tiene las siguientes ventajas:

• Permite a las estaciones de prueba ejecutar pruebas sin una conexión de red permanente.
• Puede disminuir el tiempo de carga de los archivos del sistema de pruebas.

Sin embargo, este enfoque añade un esfuerzo adicional para copiar archivos en todas las estaciones de prueba. También debe asegurarse de que todos los sistemas de pruebas tengan los archivos más recientes antes de ejecutar cualquier prueba.

Puede crear herramientas adicionales para comparar automáticamente la versión del archivo en la estación de prueba que coincide con la unidad compartida cada vez que se inicia la estación de prueba y descargar los archivos que no estén actualizados.

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.