Desarrollo de modelos de proceso y personalización de TestStand

La creación de una prueba completa para un producto requiere algo más que la ejecución de un conjunto de casos de prueba. Por lo general, el sistema de pruebas debe realizar una serie de operaciones antes, durante y después de ejecutar la secuencia que efectúa las pruebas. Las operaciones comunes que definen el proceso de prueba incluyen la identificación de la UUT, la notificación al operador del estado de aprobación/fallo, el registro de resultados y la generación de un informe de prueba. El conjunto de tales operaciones y su flujo de ejecución se denomina modelo de proceso. En TestStand, la capa del modelo de proceso se implementa en archivos de secuencia y es distinta del motor TestStand. Esta modularidad le permite personalizar los modelos de proceso sin afectar al propio ejecutivo de pruebas.

Los modelos de proceso proporcionan una capa adicional, separada del código de prueba y del ejecutivo de pruebas, para implementar una funcionalidad de pruebas común

Los modelos de proceso diferencian a TestStand de la mayoría de los ejecutivos de pruebas locales. Por lo general, estas aplicaciones no tienen el concepto de un modelo de proceso, y la secuencia de prueba o el propio ejecutivo de la prueba proporcionan el mecanismo para las tareas de pruebas comunes.  Ninguno de estos enfoques es la solución ideal:

• Si el código de prueba es responsable de estas operaciones comunes, cada nuevo conjunto de prueba creado deberá repetir este código.
• Si las operaciones comunes se implementan directamente en el ejecutivo de pruebas, hacer cambios en las operaciones de pruebas comunes requiere actualizaciones para todo el ejecutivo de pruebas.

El uso de un modelo de proceso para realizar tareas comunes permite una mayor modularidad y reutilización porque se puede modificar las operaciones comunes en un solo lugar, manteniéndolas separadas del ejecutivo de pruebas subyacente.

Los modelos de proceso de TestStand se modularizan aún más a través de la arquitectura de plug-in.  Los modelos de proceso llaman a los archivos de secuencia de plug-in para implementar el procesamiento de resultados, como la generación de informes y el registro de base de datos.  Puede modificar estos plug-ins o crear los suyos propios para ampliar la funcionalidad del modelo de proceso sin modificar los modelos de proceso en sí.

El modelo de proceso llama a los plug-ins para realizar el procesamiento de resultados, incluida la generación de informes y el registro de base de datos.  También puede crear plug-ins personalizados para implementar mecanismos de registro personalizados.

Puede usar los modelos de proceso de TestStand para crear una aplicación de pruebas extremadamente potente y flexible. La implementación modular del modelo de proceso minimiza la cantidad de cambios de código que debe realizar al actualizar la funcionalidad de marco de trabajo. El uso de la arquitectura del modelo de proceso de TestStand para desarrollar un sistema de pruebas completo puede ahorrar tiempo y costes de desarrollo y de mantenimiento.

En TestStand, los modelos de proceso se implementan como archivos de secuencia con la opción de modelo de proceso habilitada, lo que les permite contener tipos adicionales de secuencias específicas del modelo.  El tipo de archivo de secuencia se configura en la pestaña Avanzado [Advanced] de Propiedades del archivo de secuencia [Sequence File Properties]. Cada tipo de secuencia tiene un comportamiento específico:

• Los Puntos de entrada de ejecución permiten a los usuarios ejecutar pruebas usando una secuencia del modelo de proceso deseada.
• Los Puntos de entrada de configuración proporcionan una interfaz de usuario para que los usuarios configuren los ajustes del modelo de proceso y almacenen esa configuración.
• Las Devoluciones de llamada de modelos permiten que el archivo de secuencia de prueba anule el comportamiento del modelo de proceso.
  

Utilice la pestaña Modelo [Model] del cuadro de diálogo Propiedades de la secuencia [Sequence Properties] para configurar los tipos de secuencias que puede contener un archivo de modelos de proceso.

Secuencias de puntos de entrada de ejecución

Los puntos de entrada de ejecución ofrecen un método para que los usuarios ejecuten su código de prueba a través del modelo de proceso. El modelo de proceso predeterminado de TestStand proporciona dos puntos de entrada de ejecución, las UUT de prueba y el Pase único. Cada uno de estos puntos de entrada se implementa en una secuencia en el archivo de secuencia del modelo de proceso. En el editor de secuencia, el menú Ejecutar [Execute] enumera los puntos de entrada de ejecución cuando la ventana activa contiene un archivo de secuencia que utiliza el modelo de proceso.

El modelo de proceso secuencial utiliza los puntos de entrada de ejecución de Pase único y UUT de prueba. Ambos puntos de entrada de ejecución llaman a la secuencia MainSequence del archivo de secuencia del cliente para ejecutar pruebas para una UUT a la vez. Los puntos de entrada también comparten otras acciones, como la generación de informes de prueba y el almacenamiento de resultados de datos en una base de datos.

Flujo de punto de entrada de ejecución de UUT de prueba y Pase único en el modelo de proceso secuencial

La expresión del nombre del punto de entrada es el nombre que aparece en el Editor de secuencia o en una interfaz de usuario mientras se usa el punto de entrada. Para editar este valor, utilice el cuadro de texto Expresión del nombre del punto de entrada [Entry Point Name Expression] en la pestaña Modelo [Model] del cuadro de diálogo Propiedades de la secuencia [Sequence Properties]. El cuadro de texto Expresión del nombre del punto de entrada [Entry Point Name Expression] solo es visible cuando la secuencia que selecciona es un punto de entrada de ejecución. Un valor predeterminado, como ResStr("MODEL", "TEST_UUTS"), utiliza la función ResStr, que ofrece la localización de TestStand. Reemplace el valor con otro valor localizado o use una expresión de cadena constante que describa el punto de entrada desde el punto de vista de un usuario.  

El uso de cadenas de localización en lugar de una constante ofrece la ventaja de permitirle hacer cambios en el valor de la cadena sin la necesidad de modificar el modelo de proceso en sí. Para obtener más información sobre el uso de las cadenas de recursos de TestStand para la localización, consulte el tutorial Localización de TestStand para diferentes idiomas.

Puntos de entrada de configuración

Los puntos de entrada de configuración proporcionan a los usuarios una forma de configurar los ajustes para el modelo de proceso.  Los modelos predeterminados contienen los puntos de entrada Opciones de modelo y Procesamiento de resultados.  Los puntos de entrada de configuración son parecidos a los puntos de entrada de ejecución. Se implementan en una secuencia en el archivo de modelos de proceso y se enumeran en el menú Configurar [Configure] en el editor de secuencias.  Para guardar la configuración, los puntos de entrada del modelo escriben datos en los archivos de configuración en el directorio de configuración de TestStand.

Devoluciones de llamada de modelos

Las devoluciones de llamada de modelos permiten a los desarrolladores de pruebas personalizar determinados aspectos del modelo de proceso para su prueba, sin tener que hacer cambios en el modelo de proceso en sí.  El modelo de proceso define secuencias de devolución de llamada a las que los puntos de entrada llaman en varios puntos en ejecución.  Por ejemplo, el punto de entrada UUT de prueba llama a la secuencia de devolución de llamada PreUUT antes de comenzar la prueba para solicitar al usuario un número de serie.  Si un desarrollador de pruebas requiere un cambio específico en esta funcionalidad, puede anular la devolución de llamada en su archivo de secuencia de prueba.  En este caso, cuando el modelo llama a la secuencia PreUUT, se llama a la secuencia del archivo de secuencia de prueba en lugar de a la secuencia PreUUT del archivo de modelos de proceso.

Para obtener una descripción detallada de las devoluciones de llamada del modelo de proceso, consulte el documento Usar devoluciones de llamada en NI TestStand.

El archivo de secuencia de prueba puede anular las secuencias de devolución de llamada en el modelo de proceso para definir un comportamiento personalizado

Plug-ins del modelo de proceso

Los modelos de proceso predeterminados utilizan una arquitectura de plug-in para implementar el procesamiento de resultados, incluida la generación de informes y el registro de base de datos.  Cada plug-in se implementa en un archivo de secuencia que contiene secuencias de puntos de entrada de plug-in que se llaman en varios puntos en los puntos de entrada del modelo de proceso principal.  Los modelos de proceso también proporcionan un cuadro de diálogo de configuración de plug-in que permite a los desarrolladores de pruebas configurar qué plug-ins están activos y configurar los ajustes de los plug-ins.  

Para obtener más información sobre la arquitectura de plug-in del modelo de proceso de TestStand, consulte el tema de ayuda Arquitectura de plug-in del modelo de proceso.  

Devoluciones de llamada adicionales del motor

Los archivos de secuencia del modelo de proceso proporcionan devoluciones de llamada adicionales del motor que no están disponibles en los archivos de secuencia estándar.  Estas devoluciones de llamada, que tienen el prefijo “ProcessModel”, se ejecutan solo en los pasos del archivo de secuencia del cliente actual del modelo de proceso donde los define.  Por ejemplo, la devolución de llamada ProcessModelPostStep se lleva a cabo después de cada paso que se ejecuta en la secuencia de prueba, pero no después de los pasos que se ejecutan en el modelo de proceso en sí.

Una aplicación común para estas devoluciones de llamada es el manejo personalizado de errores.  Por lo general, los desarrolladores de pruebas quieren extraer la mayor cantidad de información posible de los errores y quieren controlar el comportamiento del sistema cuando se producen errores. En otros casos de uso, los entornos subcontratados y totalmente automáticos suelen requerir entradas de inicio/detención y salidas de luz roja/verde con un registro de depuración adecuado para rastrear el sistema anterior y comprobar la actividad de los errores.

Puede utilizar las devoluciones de llamada de motor ProcessModelPostStepFailure y ProcessModelPostStepRuntimeError definidas en el nivel de modelo de proceso para manejar de manera genérica los errores de todos los archivos de secuencia de cliente sin que el programador de la secuencia de prueba tenga que hacer un esfuerzo adicional. Estas devoluciones de llamada se ejecutan si se produce un error en el archivo de secuencia del cliente.

En muchos casos, es posible que deba ampliar o modificar la funcionalidad de los modelos de proceso que se envían con TestStand.  Los cambios comunes en los modelos de proceso incluyen modificaciones para los informes, estrategias de reintento de prueba, manejo y registro de errores, rutinas de calibración de estaciones y mecanismos de selección de UUT.

Adición de nuevas funciones mediante el uso de plug-ins de modelos de procesos

Los modelos de proceso predeterminados utilizan plug-ins para implementar la funcionalidad del procesamiento de resultados, incluida la generación de informes y el registro de base de datos.  Sin embargo, los plug-ins no se limitan solo al procesamiento de resultados.  Si necesita añadir una funcionalidad al modelo de proceso, puede crear un plug-in para implementar esta funcionalidad sin modificar los propios modelos de proceso.  Este enfoque tiene muchas ventajas:

• Puede integrar fácilmente los plug-ins con los modelos secuenciales, por lotes y paralelos, en lugar de implementar cambios en cada uno.
• No necesitará mantener e implementar un modelo de proceso personalizado.
• Puede integrar personalizaciones con cambios futuros en los modelos de proceso.
• Los plug-ins se pueden compartir sin la necesidad de integrar cambios en el código del modelo de proceso.

De forma predeterminada, los usuarios deben crear instancias de plug-ins para que el modelo los ejecute.  Este enfoque opcional es aconsejable si la nueva funcionalidad que se añade solo se requiere en determinados casos.  Si la funcionalidad debe ejecutarse siempre, igual que el código en el modelo de proceso en sí, puede utilizar un complemento del plug-in del modelo de proceso.   Los complementos del plug-in del modelo se implementan de la misma manera que los plug-ins estándar, pero se guardan en la subcarpeta de complementos en el directorio de plug-ins.  No aparecen en el cuadro de diálogo de configuración del plug-in y se ejecutan siempre.

Creación de nuevos plug-ins

Puede desarrollar plug-ins personalizados para ampliar el modelo de muchas maneras, además del procesamiento de resultados personalizado.  La calibración de la estación de prueba es un ejemplo de funcionalidad que podría añadir a los modelos de proceso a través de un plug-in personalizado.  Antes de ejecutar los archivos de secuencia de prueba en una estación de prueba, es posible que tenga que confirmar la validez de la calibración de la estación. En estas pautas se suele comprobar que el equipo de prueba está calibrado en función de una fecha de caducidad. La caducidad de la calibración desencadena una condición de error, advierte al operador e impide que la prueba se ejecute.

Al implementar la funcionalidad en un plug-in de modelo personalizado, puede permitir que los usuarios deshabiliten la calibración si es necesario y proporcionar una interfaz de configuración para desarrolladores de prueba a través del diálogo de procesamiento de resultados.  Consulte el tema Creación de plug-ins de modelo de proceso para obtener información sobre la implementación.

Para cambiar el comportamiento que se implementa directamente en el modelo de proceso, como el seguimiento del número de serie de UUT, es necesario realizar cambios directamente en el modelo. Utilice una copia del modelo de proceso como punto de partida para desarrollar nuevos modelos de proceso o para personalizar modelos de proceso existentes, de modo que pueda volver a utilizar grandes cantidades de lógica ajustada ya implementada en el modelo de proceso predeterminado.    

Antes de modificar los modelos de proceso, cree una copia de todo el directorio de modelos, ubicado en <TestStand>/Components/Models, en la ubicación correspondiente del directorio público de TestStand, <TestStand Public>/Components/Models.  Haga cambios solo en los archivos que se encuentran en la ubicación pública de TestStand.

Modificación de puntos de entrada del modelo

En muchos casos, es posible que desee personalizar el flujo de ejecución del punto de entrada de ejecución.  Por ejemplo, podría querer que el sistema de pruebas vuelva a efectuar una prueba en un UUT automáticamente cuando se produzcan determinados tipos de fallos o que se limite el número de reintentos por operador antes de requerir la intervención del supervisor para determinar la necesidad de nuevas pruebas. En este tipo de cambios, será necesario modificar directamente la secuencia de puntos de entrada para añadir ciclos y otras condiciones.  Al hacer cambios en los puntos de entrada, asegúrese de documentar los cambios realizados para que sea más fácil diferenciar el comportamiento predeterminado de las personalizaciones.

Permitir a los desarrolladores de pruebas personalizar el comportamiento del modelo

Al personalizar los modelos de proceso, es importante tener en cuenta si una prueba determinada puede requerir la modificación o desactivación del comportamiento que se está definiendo.  En los casos en que el desarrollador de la prueba pueda necesitar hacer cambios, utilice una secuencia de devolución de llamada existente o nueva para implementar los cambios.  El desarrollador de pruebas puede anular la devolución de llamada si necesita cambiar el comportamiento que usted define.  

La nueva funcionalidad debe implementarse siempre en una secuencia aparte, a la que llama desde los puntos de entrada que deben implementarla. Puede implementar una secuencia en el modelo de proceso de las siguientes maneras según el nivel de personalización que desee proporcionar a los desarrolladores de pruebas:

• Desea proporcionar un método para que los desarrolladores de pruebas amplíen el modelo en un determinado punto de la ejecución: Implemente un marcador de posición sin funcionalidad predeterminada para que el archivo de secuencia del cliente pueda insertar funcionalidad si es necesario. Opcionalmente, puede pasar parámetros a la devolución de llamada cuando llame desde el punto de entrada para proporcionar datos relevantes al desarrollador de pruebas.  Por ejemplo, ModifyReportHeader no proporciona una implementación predeterminada, pero los parámetros que contienen datos relacionados con el informe se pasan a la devolución de llamada para que los desarrolladores de pruebas puedan acceder y modificar el informe.
• Desea definir la funcionalidad que los desarrolladores de pruebas puedan personalizar o deshabilitar:  Implemente el comportamiento predeterminado para que la devolución de llamada del cliente pueda invocar la devolución de llamada del modelo a fin de ejecutar la implementación predeterminada del modelo de proceso y la devolución de llamada del cliente pueda implementar una funcionalidad adicional. De forma predeterminada, PostUUT implementa banners para mostrar el resultado de la secuencia de prueba. Un archivo de secuencia de cliente puede implementar comportamientos PostUUT personalizados y mantener el banner al anular la devolución de llamada y aún así llamar a la implementación del modelo de proceso.  Puede usar la opción Copiar paso y entornos locales [Copy Step and Locals] al crear una anulación de secuencia en las propiedades de secuencia para especificar que el contenido de la secuencia debe copiarse cuando un desarrollador de pruebas anula la devolución de llamada.
• Desea evitar que los desarrolladores de pruebas personalicen la funcionalidad: Si define una funcionalidad que los desarrolladores de pruebas nunca deben modificar, utilice una secuencia normal en lugar de una devolución de llamada, la cual no puede anularse en los archivos de secuencia del cliente.

Personalización del comportamiento del plug-in del modelo existente

Es habitual que los desarrolladores de marcos de trabajo personalicen el comportamiento de generación de informes para abordar los requisitos específicos de su sistema de pruebas.  La personalización de informes se describe en detalle en el documento Prácticas recomendadas para la generación y personalización de informes de NI TestStand de la Serie de arquitectura avanzada.  Este documento proporciona más información sobre cómo implementar personalizaciones para generar informes dentro de la arquitectura del modelo TestStand.  

Los modelos de proceso predeterminados definen tipos de datos para almacenar información sobre las opciones actuales de UUT, estación y modelo.  En algunos casos, es posible que deba almacenar datos adicionales en estas propiedades, generalmente los datos UUT.  Por ejemplo, el mecanismo de selección de UUT de TestStand predeterminado solo hace seguimiento de un número de serie, pero es posible que también deba mantener el número de modelo.  

NI recomienda no hacer cambios en los tipos de datos del modelo cuando sea posible, ya que se hace referencia a ellos en muchos archivos de TestStand, y las actualizaciones pueden ser difíciles de mantener.  Sin embargo, los modelos de proceso proporcionan una propiedad no estructurada en los tipos de datos UUT y NI_StationInfo que le permite agregar fácilmente información adicional de seguimiento de UUT sin la necesidad de modificar el tipo de datos UUT. Puede crear una nueva propiedad ModelNumber en el contenedor UUT.AdditionalData para almacenar esta información.  El ejemplo Agregar datos personalizados a un informe que se incluye con TestStand muestra cómo puede usar esta propiedad para agregar campos a esta propiedad e incluirlos en el informe de prueba.  El ejemplo implementa las actualizaciones en el archivo de secuencia del cliente mediante una devolución de llamada, pero puede utilizar el mismo enfoque directamente en el modelo de proceso.

También puede anular una devolución de llamada en el archivo de secuencia del modelo de proceso al crear una secuencia con el mismo nombre pero con otra funcionalidad en StationCallbacks.seq en el directorio <TestStand Public>\Components\Callbacks\Station. TestStand llama a las devoluciones de llamada del modelo en StationCallbacks.seq en lugar de llamar a la devolución de llamada con un nombre similar definido en cualquier modelo. Una devolución de llamada en un archivo de cliente anula la devolución de llamada con un nombre similar en el modelo y en el archivo StationCallbacks.seq.

Al actualizar a una versión más reciente de TestStand, deberá fusionar todos los cambios realizados en los modelos de proceso predeterminados con los cambios que NI ha llevado a cabo en la nueva versión.  Para ello, primero verifique las diferencias entre el modelo de proceso predeterminado anterior y el nuevo mediante la herramienta de diferenciación de TestStand, ubicada en Editar » Archivo de secuencia diferente ante [Edit » Diff Sequence File Against] en el editor de secuencia. Si todas las modificaciones se centralizan en nuevas secuencias en los archivos del modelo de proceso, o se implementan por separado en plug-ins, la importación de las personalizaciones del modelo de proceso en la versión más reciente del modelo de proceso será una tarea relativamente sencilla.

Si migra modelos que creó en las versiones de TestStand anteriores a 2012, existen cambios significativos en los nuevos modelos para implementar la arquitectura del plug-in.  En tal caso, consulte Migración de personalizaciones del modelo de proceso a TestStand 2012 o posterior para obtener más información sobre la migración de sus modelos de proceso.

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