Cómo mejorar el rendimiento de los sistemas de TestStand

TestStand tiene varias opciones de configuración que pueden afectar al rendimiento. Las siguientes secciones describen dichas opciones.

• Rastreo de secuencias
• Opciones de la velocidad de ejecución de equilibrio y el uso de memoria

Rastreo de secuencias

El rastreo de secuencias proporciona comentarios inmediatos y el estado de la operación actual, como Aprobado, Reprobado, Error u Omitido. Sin embargo, el rastreo de secuencias afecta al rendimiento, ya que disminuye la velocidad de ejecución. Los siguientes enfoques pueden ayudarle a mejorar la velocidad de ejecución sin sacrificar los beneficios del rastreo de secuencias.

Para mejorar el rendimiento cuando el rastreo de secuencias está habilitado, establezca la velocidad de rastreo en rápida para asegurarse de que no hay ninguna demora adicional entre los pasos. Use la pestaña Ejecución [Execution] del cuadro de diálogo Opciones de estación [Station Options] para configurar el rastreo, al que puede acceder mediante Configurar » Opciones de estación [Configure » Station Options].

Incluso cuando se establece en la velocidad más rápida, el rastreo agrega unos pocos milisegundos de sobrecarga por paso para actualizar el panel Vista de ejecución [Execution View] tras la ejecución de cada paso. Para obtener el rendimiento más rápido, puede deshabilitar completamente el rastreo. Sin embargo, si deshabilita el rastreo de secuencias, la vista de ejecución no se actualiza al ejecutarse la secuencia.

Para equilibrar el rendimiento con los beneficios de la facilidad de uso del rastreo, use la Configuración del rastreo de llamadas de secuencia [Sequence call trace setting] para deshabilitar el rastreo en subsecuencias específicas.  Para utilizar este enfoque, organice sus pruebas en grupos lógicos y cree subsecuencias para cada uno.  Por ejemplo, en una secuencia de prueba para un dispositivo móvil, las pruebas para cada componente, como los datos celulares, la entrada del usuario y los sistemas de audio, se pueden implementar en secuencias independientes. Para el paso SequenceCall de cada componente, deshabilite el rastreo dentro de la llamada de secuencia.

1. Seleccione Propiedades » Opciones de ejecución [Properties»Run Options].
2. Establezca la propiedad Configuración del rastreo de llamadas de secuencia [Sequence call trace setting] en Desactivar rastreo en la secuencia [Disable tracing in sequence].

Organizar la secuencia de prueba de esta manera le permite utilizar el rastreo de secuencias para la secuencia de nivel superior sin la sobrecarga de rendimiento del rastreo de cada subpaso. Este enfoque también se puede adaptar fácilmente a las pruebas en paralelo, ya que puede llamar a cada subsecuencia de forma asíncrona. Consulte la sección Mejorar el rendimiento de la prueba mediante pruebas en paralelo para obtener más información sobre la paralelización de la secuencia de prueba.

Utilice los pasos de llamadas a secuencias con el rastreo deshabilitado para mejorar el rendimiento y ver el estado de ejecución

Opciones de la velocidad de ejecución de equilibrio y el uso de memoria

TestStand le permite configurar cuándo se cargan y descargan los módulos de código de la memoria, lo que puede tener un impacto significativo en el uso de la memoria y la velocidad de ejecución de una secuencia de prueba. La configuración de módulos para que permanezcan en la memoria más tiempo mejorará el tiempo de ejecución, ya que no será necesario volver a cargar los módulos en ejecuciones posteriores.  Sin embargo, si se guardan demasiados módulos en la memoria, puede exceder los límites de memoria de la aplicación o la memoria física disponible, lo que también puede ralentizar la ejecución.

Lo ideal sería poder realizar mejoras en su sistema de prueba para aumentar las limitaciones de memoria, en lugar de descargar módulos de código para ahorrar memoria. Por ejemplo:

• Usar la versión de 64 bits de TestStand para aumentar los límites de memoria de la aplicación. Para obtener más información sobre cómo abordar problemas de memoria con TestStand de 64 bits, consulte el tema de ayuda Elegir entre TestStand de 32 bits y TestStand de 64 bits  
• Agregar memoria física adicional a los sistemas de pruebas.
• Usar discos duros de estado sólido para mejorar el rendimiento de la memoria virtual.

Si el uso de la memoria sigue siendo un problema, puede configurar las opciones de carga y descarga en el nivel de paso o en el nivel de archivo de secuencia. En la mayoría de los sistemas de prueba, puede combinar las opciones Precargar cuando se abre el archivo de secuencia [Preload when opening sequence file] o Precargar cuando comienza la ejecución [Preload when execution begins] con la opción Descargar cuando el archivo de secuencia está cerrado [Unload when sequence file is closed] para obtener el mejor rendimiento.  

Formato de archivo

El formato de archivo puede afectar a la velocidad y al rendimiento al cargar archivos de secuencia de gran tamaño. TestStand le permite guardar secuencias en los siguientes formatos de archivo: INI, XML y binario.  

• Utilice el formato XML solo si el archivo debe ser visible en aplicaciones sin acceso al motor TestStand, como con la herramienta Visor de archivos de secuencia [Sequence File Viewer] u otro visor personalizado.
• Utilice el formato INI solo si su archivo de secuencia debe ser compatible con TestStand 3.x o una versión anterior.
• Si no se aplica nada de lo anterior, utilice el formato binario para los tiempos de carga más rápidos.  

Siga los pasos siguientes para especificar qué formato usar para los nuevos archivos de secuencia:  

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

Para cambiar el formato de un archivo de secuencia existente, siga estos pasos:

1. Seleccione Editar » Propiedades del archivo de secuencia [Edit » Sequence File Properties]. 
2. Seleccione Formato de archivo [File Format] en la pestaña General [General].
3. Elija el formato deseado en el menú Formato de archivo para archivos nuevos [File Format for New Files].

Utilice el formato de archivo binario para los tiempos de carga de archivos de secuencia más rápidos

Configuración del directorio de búsqueda

La configuración del directorio de búsqueda afecta directamente al tiempo requerido para cargar archivos de secuencia y módulos de código cuando se especifican con rutas relativas. La configuración del directorio de búsqueda afecta al rendimiento de la carga inicial y a la ejecución de las pruebas, y a iteraciones posteriores si los módulos se cargan dinámicamente. Utilice el cuadro de diálogo de configuración del directorio de búsqueda para ver y editar los directorios de búsqueda. Seleccione Configurar » Buscar directorios [Configure » Search Directories] para abrir el cuadro de diálogo Editar directorios de búsqueda [Edit Search Directories]. 

Al resolver la ruta relativa de un módulo de código, TestStand utiliza el siguiente procedimiento:

1. Agregar la ruta del módulo de código al primer directorio de búsqueda.
   
2. Comprobar si la ruta absoluta del archivo existe en el disco.

• Si existe, la ruta se resuelve.
• Si no existe, vaya al siguiente directorio.

TestStand verifica la lista de directorios de búsqueda para resolver una ruta relativa a un archivo de módulo de código

Dado que solo se calcula una ruta para cada directorio de búsqueda, por lo general. este proceso no afecta significativamente el rendimiento.  

Sin embargo, si un directorio de búsqueda tiene la opción Buscar subdirectorios [Search Subdirectories], el proceso se repite con cada subdirectorio que se encuentra dentro de la ruta especificada.  Si la ruta contiene una gran jerarquía de directorios, esta opción puede afectar significativamente al rendimiento.  Además, si existen varios archivos con el mismo nombre dentro de la jerarquía, es posible que se cargue el archivo incorrecto. Por estas razones, evite usar esta opción en los directorios de búsqueda que añada.  En su lugar, asegúrese de que se especifiquen todas las rutas del módulo de código mediante una ruta relativa al directorio de búsqueda base.

Para optimizar aún más el orden de los directorios de búsqueda, siga las siguientes pautas:

• Coloque los directorios que contienen la mayoría de los módulos de código cerca de la parte superior de la lista y los directorios de uso menos frecuente hacia la parte inferior.
• Coloque los directorios ubicados en las unidades de red más abajo en la lista, ya que el acceso a la red es más lento que el acceso al disco local.
• Si necesita utilizar la opción Buscar subdirectorios [Search Subdirectories], coloque estos directorios en la parte inferior de la lista como un cajón de sastre.   

Cuando diseñe la estructura de directorios para su sistema de pruebas, considere la posibilidad de guardar los módulos de código en un directorio debajo de la ruta del archivo de secuencia o en una ubicación específica del módulo de código.   

• El uso de rutas relativas al archivo de secuencia garantiza que la primera ruta de búsqueda (el directorio actual del archivo de secuencia) siempre devuelve el archivo correcto y evita la necesidad de búsquedas adicionales. Esto también le permite mover toda la carpeta a otra ubicación u ordenador sin tener que cambiar los directorios de búsqueda. Utilice este enfoque para los módulos de código que solo utilizan un único archivo de secuencia o un conjunto de archivos de secuencia relacionados.
• La utilización de una ubicación específica para los módulos de código le permite hacer referencia a los módulos de código de diferentes archivos de secuencia con facilidad al añadir la ubicación a la lista de directorios de búsqueda.  Utilice este enfoque para los módulos de código que comparten muchos archivos de secuencia.

TestStand puede llamar a módulos de código en varios entornos de desarrollo para realizar pasos de prueba. La configuración de estos módulos de código y entornos de desarrollo puede tener un gran impacto en el rendimiento.  En cualquier entorno de módulo de código, puede lograr un mejor rendimiento al trasladar solo los datos necesarios dentro y fuera de un módulo de código. Evite trasladar grandes cantidades de datos a los que el módulo de código no accederá ni modificará.

Módulos de código compilado (DLL)

Los módulos de código compilado, como los ensambles .NET o DDL de C/C++, pueden reducir el rendimiento si utiliza una versión de depuración de DLL en lugar de una versión de lanzamiento. Por lo general, los desarrolladores usan DLL de depuración en el desarrollo para que sea más fácil encontrar y corregir problemas en los módulos. Una vez que la secuencia de prueba esté lista para la implementación, conmute para publicar las DLL para mejorar el rendimiento.  

Módulos de código de LabVIEW

Puesto que los VI de LabVIEW se ejecutan directamente, pueden ejecutarse en el entorno de desarrollo de LabVIEW o en LabVIEW Runtime Engine.  Cuando ejecuta los VI de LabVIEW en el entorno de desarrollo, puede usar características de depuración para solucionar problemas de módulos de código, pero la velocidad de ejecución disminuye.  Para las pruebas de producción, utilice LabVIEW Runtime Engine para llamar a los VI. Puede configurar qué servidor de LabVIEW se usa para ejecutar el código de LabVIEW mediante el cuadro de diálogo del adaptador de LabVIEW:

1. Seleccione Configurar » Adaptadores [Configure » Adapters].
2. Seleccione el adaptador LabVIEW y, a continuación, haga clic en Configurar [Configure].
3. Seleccione LabVIEW Run-time Engine o el sistema de desarrollo de LabVIEW.

Para optimizar aún más los tiempos de carga para el código de LabVIEW, puede compilar sus VI de módulo de código en las Bibliotecas de proyectos en paquete (PPL).  Como las PPL contienen versiones compiladas de todas las dependencias de los VI de los VI del módulo de código, LabVIEW puede cargar las dependencias en la memoria con mayor rapidez.  Como alternativa, si implementa su código con la Utilidad de implementación TestStand, puede generar PPL para su VI como parte del proceso de implementación.

Para obtener más información sobre el uso de PPL con la Utilidad de implementación TestStand, consulte el tema de ayuda Organizar archivos de programas de prueba con bibliotecas de proyectos en paquete de LabVIEW.

A menudo, se puede mejorar la velocidad de la prueba si se llevan a cabo pruebas en paralelo, de manera que se completan varias pruebas de forma simultánea.  TestStand incluye funciones que ayudan a paralelizar las pruebas de una única UUT, o a probar varias UUT al mismo tiempo.   

Paralelizar una secuencia de prueba

Al probar una única UUT, es posible que pueda probar varias partes del sistema a la vez.  Por ejemplo, piense en la secuencia de prueba para un dispositivo móvil. Las pruebas para cada componente, como los datos celulares, la entrada del usuario y los sistemas de audio, se pueden implementar en secuencias independientes. En lugar de llamar a cada una de las secuencias de forma secuencial, puede configurar el paso de llamada de secuencia para llamarlas de forma asíncrona y acelerar la prueba.

Para especificar que una llamada de secuencia debe ejecutarse de forma asíncrona, haga lo siguiente:

1. Seleccione un paso de llamada de secuencia y haga clic en la pestaña Módulo [Module].
2. En el menú Opciones de ejecución [Execution Options], seleccione la opción Usar nuevo hilo [Use New Thread] o Usar nueva ejecución [Use New Execution].

Llamar a una secuencia en un nuevo hilo le permite probar diferentes partes de una UUT de forma simultánea

Al configurar llamadas de secuencia asíncronas, tenga en cuenta las diferencias entre usar un nuevo hilo y una nueva ejecución:

Por lo general, debería usar la opción de nuevo hilo para pruebas relacionadas dentro de una secuencia de pruebas.  El uso de una nueva ejecución es más apropiado para obtener una funcionalidad más independiente, como un monitor de estado que debería ejecutarse sin depender de la secuencia de prueba.

Para obtener más información sobre cómo decidir si usar un nuevo hilo o una nueva ejecución, consulte Cuándo ejecutar una secuencia en una nueva ejecución o en un nuevo hilo.

Obtener resultados de llamadas de secuencia asíncronas

Para obtener los resultados de las subsecuencias asíncronas para los informes o el registro de la base de datos, utilice los pasos de espera al final de la secuencia de inicio para esperar a que se completen las llamadas de secuencia asíncronas. Una vez que se completa el hilo de la subsecuencia, TestStand adjunta los resultados de la subsecuencia asíncrona a los resultados del paso de espera, poniéndolos a disposición de la generación de informes y el registro de la base de datos. Para esperar la ejecución de una secuencia o hilo, seleccione Ejecución [Execution] o Hilo [Thread] en Esperar [Wait] para controlar y especificar la ejecución o hilo al que esperar.  Tenga en cuenta que añadir esta espera puede hacer que la ejecución se demore si la secuencia de llamada se completa antes del hilo; por lo tanto, utilice este enfoque solo cuando necesite los resultados del nuevo hilo.

Utilizar un paso de espera para obtener los resultados de una llamada de secuencia asíncrona

Pruebas de varias UUT en paralelo

Además de usar llamadas asíncronas en la secuencia de prueba, TestStand le permite probar varias UUT en paralelo mediante los modelos de proceso en paralelo y por lotes.  Estos modelos de proceso crean varias ejecuciones, cada una de las cuales ejecuta la secuencia de prueba en una UUT independiente.  Puede cambiar el modelo de proceso para la estación actual o para un archivo de secuencia de prueba individual.

Probar varias UUT simultáneamente mediante los modelos de proceso en paralelo y por lotes

Si desea ver una demostración de cómo las pruebas en paralelo pueden mejorar los tiempos de prueba, consulte la Demostración de estrategias de prueba en paralelo incluida con TestStand.

Elegir entre el modelo de proceso en paralelo o el modelo de proceso por lotes

Mientras que el modelo de proceso en paralelo le permite iniciar y finalizar las pruebas de UUT en diferentes momentos, el modelo de proceso por lotes está diseñado para iniciar y finalizar la secuencia de prueba en todas las UUT al mismo tiempo.  

• El modelo de proceso en paralelo es ideal para probar varias UUT mediante dispositivos de prueba independientes, donde cada UUT se prueba por separado.   
• El modelo de proceso por lotes es ideal para probar las UUT que se prueban como grupo mediante un dispositivo de prueba común o una cámara de prueba, donde las pruebas deben estar sincronizadas para todas las UUT.

 Además de comenzar y finalizar cada prueba de lotes al mismo tiempo, el modelo de proceso por lotes le permite utilizar los pasos y la configuración de la sincronización por lotes para sincronizar aún más las pruebas entre UUT en el lote. Si hay determinadas partes de la prueba que deben ejecutarse al mismo tiempo para todas las UUT, puede definir secciones sincronizadas para un solo paso utilizando la configuración de paso, o para varios pasos utilizando el tipo de paso de sincronización por lotes.

Utilice la sincronización por lotes para asegurarse de que ciertas partes de la prueba estén sincronizadas para todas las UUT del lote

En todos los tipos de secciones de sincronización por lotes, todos los sockets entran y salen juntos de la sección.  Puede configurar aún más la sincronización para que se ejecute de forma secuencial o solo en un único hilo.

Para obtener más información sobre la sincronización por lotes, consulte el ejemplo Tipos de pasos de sincronización: sincronización por lotes.

Consideraciones de hardware para pruebas en paralelo

Al probar varias UUT en paralelo, el hardware de prueba disponible puede convertirse en un cuello de botella de rendimiento.  Al usar un recurso de hardware compartido, debe asegurarse de que solo un hilo acceda a un recurso de hardware compartido en un momento determinado para evitar conflictos de recursos.  Por lo general, utiliza los tipos de paso o la configuración de bloqueo para reservar un recurso compartido.  Sin embargo, si varios hilos esperan a un solo recurso para completar una prueba, muchas de las posibles mejoras de la prueba en paralelo no se realizarán.  Para mitigar esto, puede llevar a cabo las siguientes acciones:

• Utilizar los tipos de paso de programación automática para permitir que se ejecuten otras pruebas mientras espera a los recursos.
• Utilizar el generador de perfiles de ejecución para buscar el hardware que está causando el cuello de botella y añadir hardware de prueba adicional.

Uso de la programación automática

El tipo de paso Programación automática le permite configurar un conjunto de pruebas que se pueden ejecutar en cualquier orden para optimizar el tiempo de prueba y la utilización del hardware.  Cuando se ejecuta una sección programada automática con el modelo de proceso en paralelo o por lotes, cada socket ejecuta la primera sección que no requiere un recurso reservado. Por esta razón, el orden de ejecución puede variar entre diferentes ejecuciones de la misma prueba.

Utilice el planificador automático para optimizar la utilización del hardware cuando el orden de ejecución no es importante.

Utilice este enfoque cuando el orden de ejecución de las pruebas no sea importante. Si la prueba requiere que los resultados de la prueba se presenten en un orden específico, no use la programación automática.

Uso del generador de perfiles de ejecución

La herramienta Generador de perfiles de ejecución que incluye TestStand es útil para identificar qué hardware de prueba limita la velocidad de ejecución del sistema de pruebas.  Inicie el generador de perfiles desde el Editor de secuencias [Sequence Editor] a través de Herramientas » Ejecución de perfiles [Tools » Profile Execution].

El generador de perfiles le permite ver cuánto tiempo está activo cada recurso de hardware, lo que le permite tomar decisiones fundadas sobre el impacto de añadir hardware al sistema de pruebas.  En el perfil de ejemplo que se muestra a continuación, el DMM se utiliza en su totalidad mientras que el ámbito se utiliza solo al 66%.  Según este perfil, agregar un segundo DMM o un DMM con más canales mejoraría el tiempo de prueba de esta secuencia.

El generador de perfiles de ejecución le permite visualizar qué recursos son posibles cuellos de botella en la configuración de prueba.

Puede mejorar los tiempos de prueba al asegurarse de que interactúa con el hardware de la manera más eficiente posible.  En esta sección se analiza lo que hay que tener en cuenta a la hora de administrar referencias de hardware y técnicas de medición para mejorar el rendimiento.

Optimizar el rendimiento de medición del hardware

En todas las configuraciones de hardware que se proporcionan, existen varios factores comunes que pueden disminuir la efectividad de la prueba. Por ejemplo, puede usar un osciloscopio para medir el tiempo de subida, el tiempo de bajada, el RMS y los valores máximos de una señal. Si programa el osciloscopio para capturar la forma de onda completa, transferir la forma de onda al sistema de prueba y, a continuación, realizar el procesamiento posterior de los datos para extraer las mediciones deseadas, experimentará una disminución del rendimiento debido a la gran cantidad de datos que se transfieren. El rendimiento también se ve afectado por la latencia del bus de comunicación, por lo que debe tener en cuenta si su instrumento tiene una latencia alta, como una conexión LAN o en serie, o un bus de baja latencia como PCI o PXI.

Si configura el osciloscopio para medir el tiempo de subida, activar una adquisición, volver a leer el tiempo de subida del instrumento y repetir estos pasos con cada medición, debe reconfigurar y volver a activar el osciloscopio en cada medición. Esta opción también tiende a ser lenta e ineficiente.

Dado que muchos osciloscopios modernos tienen varios canales de medición, siga los pasos siguientes para ejecutar pruebas con mayor rapidez:

1. Establezca la prueba para configurar cuatro canales de medición (uno para cada una de las mediciones anteriores) en el osciloscopio.  
2. Active una sola adquisición.
3. Vuelva a leer cada uno de los cuatro canales de medición.

Administrar tiempos de vida útil de referencia de hardware

El hecho de abrir y cerrar sesiones con frecuencia en el hardware puede ralentizar el rendimiento, ya que, al iniciar la comunicación con un dispositivo, muchos controladores transfieren grandes cantidades de datos para verificar comunicaciones y configuraciones. Por lo tanto, es mejor iniciar el hardware solo una vez por prueba, mientras se mantiene una manija de sesión que se utiliza durante toda la prueba para acceder al hardware.

Para iniciar el hardware solo una vez en una prueba, puede usar la devolución de llamada del modelo de proceso ProcessSetup, que se ejecuta antes de todo el código de prueba.  En el caso de los modelos de proceso en paralelo y por lotes, ProcessSetup se ejecuta solo una vez, independientemente del número de sockets de prueba. Para depurar las consultas, puede usar la devolución de llamada ProcessCleanup, que se ejecuta una vez que se completan todas las pruebas. Para obtener más información sobre cómo crear y usar las devoluciones de llamada del modelo de proceso, consulte Utilizar las devoluciones de llamada en NI TestStand.

Para acceder a las sesiones de hardware abiertas en una devolución de llamada del modelo de proceso, puede usar una variable global de archivo que se comparte entre la secuencia de devolución de llamada y la MainSequence.  Como alternativa, puede usar el administrador de sesiones, que puede administrar de forma automática la vida útil de las sesiones de hardware mediante un objeto ActiveX.  Consulte los ejemplos del Administrador de sesión para obtener más información sobre el uso del administrador de sesión.

Hay varias formas de optimizar el impacto de la recopilación de resultados en el rendimiento del sistema.

Usar el registro sobre la marcha

Para los procesadores de resultados integrados, puede seleccionar la opción Sobre la marca [On-The-Fly] para hacer el registro cuando se ejecuta la secuencia, en lugar de al final de la secuencia de prueba.  Tenga en cuenta estas ventajas y desventajas al decidir si va a utilizar esta configuración.

Ventajas del registro sobre la marcha

• Permite al operador de pruebas ver el informe cuando se ejecuta la prueba.
• Conserva los resultados en el caso de un error crítico en el programa de prueba.
• Utiliza menos memoria si se usa con el ajuste Descartar resultados [Discard Results] o Desactivar resultados cuando no lo requiere el modelo [Disable Results when not Required by Model] en las opciones del modelo de proceso.  Cuando esta configuración está habilitada, los resultados ya procesados se eliminan de la recopilación de resultados para liberar memoria.  Para la generación de informes, también debe habilitar la opción Mostrar solo los últimos resultados [Only Display Latest Results] en la configuración de generación de informes para conservar la memoria de esta manera.  

Inconvenientes del registro sobre la marcha

• Disminuye la velocidad de la prueba debido al aumento de sobrecarga necesaria para registrar con mayor frecuencia.
• Es más difícil de personalizar, ya que el registro se implementa en un servidor independiente que no se puede modificar.

Si se admite la reducción de velocidad para obtener los beneficios del registro sobre la marcha, puede mitigar el impacto en el rendimiento al ajustar la configuración sobre la marcha.  Para acceder a esta configuración, haga lo siguiente:

1. Seleccione Configurar » Procesamiento de resultados [Configure » Result Processing].
2. Seleccione la casilla de verificación Mostrar más opciones [Show More Options] y, a continuación, haga clic en el botón Avanzado [Advanced].

Para mejorar el rendimiento, aumente el intervalo de procesamiento o el número máximo de resultados para disminuir la frecuencia con la que TestStand registra los resultados.  

Procesar de resultados fuera de línea

Para reducir el tiempo dedicado a generar resultados, puede registrar datos de resultados en un archivo de resultados fuera de línea, que es un formato de resultados sin procesar rápido y compacto que contiene toda la información que TestStand requiere para generar un informe o registrar una base de datos.  Dado que el archivo contiene solo datos de resultados sin procesar, tarda menos tiempo en procesar y, por lo tanto, puede mejorar el rendimiento de la prueba.

Use la Utilidad de procesamiento de resultados fuera de línea para procesar archivos de resultados sin procesar en un informe de prueba o para registrar los datos en una base de datos. Como es una utilidad independiente, puede ejecutarla por separado, lo que le permite procesar los resultados más adelante o en otro ordenador. Use esta utilidad cuando el rendimiento del sistema de pruebas sea más importante que generar informes de forma inmediata. Para obtener más información, consulte la ayuda de Utilidad de procesamiento de resultados fuera de línea de TestStand.

Optimizar el almacenamiento de datos

Los datos almacenados localmente en un disco duro se registran más rápido que los datos almacenados en una ubicación de red, aunque algunos mecanismos de transferencia de datos de red son más rápidos que otros. Por ejemplo, el uso de Microsoft Message Queues (MSMQ) para comunicarse con una base de datos crea archivos de datos intermedios locales que después se transfieren a través de la red. Esto suele ser más rápido y seguro que escribir directamente en la base de datos remota. Aunque TestStand no proporciona funcionalidad nativa para usar MSMQ, existen herramientas de terceros para implementar este tipo de comunicación.

Registrar solo los datos requeridos

Otro factor que hay que tener en cuenta es la cantidad de datos que se registran en el sistema. El rendimiento disminuye a medida que aumenta la cantidad de datos registrados. Para registrar solo los datos que necesita, puede deshabilitar la grabación de resultados para determinados pasos o secuencias.

Puede excluir los resultados de la grabación para pasos individuales al desactivar la casilla de la opción de Resultado de grabación [Record Result] (Paso»Propiedades»Opciones de ejecución [Step»Properties»Run Options]). También puede configurar toda una secuencia para excluir la grabación de resultados mediante el ajuste Desactivar grabación de resultados para todos los pasos [Disable Result Recording For All Steps] en el cuadro de diálogo Propiedades de secuencia [Sequence Properties].

Finalizar la prueba en caso de fallo

En un entorno de producción, es posible que solo necesite saber que una UUT ha fallado una prueba, en lugar de saber específicamente qué prueba ha fallado. En esos casos, puede finalizar cuando se produce el primer fallo para liberar recursos del sistema y obtener un análisis más detallado del fallo más adelante.  

Según la prueba, algunos fallos pueden ser más graves que otros. Es posible que desee finalizar la prueba solo cuando se producen fallos en determinados pasos.  Puede configurar el comportamiento del fallo para pasos o secuencias independientes.

Para finalizar la prueba en caso de fallo en un paso específico, haga lo siguiente:

1. En las propiedades del paso [Step properties], seleccione Publicar acción [Post Action].
2. En el menú En caso de error [On Fail], seleccione Finalizar ejecución [Terminate Execution]

Para finalizar la prueba en caso de fallo en una secuencia específica, haga lo siguiente:

1. Haga clic derecho en una secuencia en el panel de secuencias [Sequence] y seleccione Propiedades de secuencia [Sequence Properties].
2. Seleccione Ir a limpieza [Goto Cleanup] para la opción de error en el paso [On Step Failure].

También puede configurar este ajuste para estaciones de prueba concretas, por ejemplo, terminando pronto solo en las máquinas de prueba de producción, mientras completa siempre toda la prueba en las máquinas de diagnóstico fuera de la línea de producción.  Para configurar máquinas de prueba específicas para finalizar en caso de fallo de la prueba:

1. Seleccione Configurar » Opciones de estación [Configure » Station Options].
2. En la pestaña de ejecución, seleccione el ajuste Ir inmediatamente a la limpieza en el fallo de secuencia [Immediately Goto Cleanup on Sequence Failure].

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.