Pruebas de Rendimiento Basadas en Objetivos

La prueba de rendimiento basada en objetivos es una estrategia empleada en las pruebas de software, particularmente en las pruebas de rendimiento, para asegurar que los sistemas de software cumplan con objetivos específicos de rendimiento bajo diversas condiciones. En la prueba de rendimiento basada en objetivos, el proceso de prueba se guía por metas u objetivos predefinidos en lugar de simplemente probar por probar.

La prueba basada en objetivos funciona mediante los siguientes pasos:

1. Definición de Objetivos de Rendimiento: El primer paso implica definir qué objetivos de rendimiento son importantes para el sistema de software que se está probando. Estos objetivos pueden incluir umbrales de tiempo de respuesta, requisitos de rendimiento, objetivos de utilización de recursos y benchmarks de escalabilidad.
2. Diseño de Escenarios de Prueba: Los escenarios de prueba se diseñan en base a los objetivos de rendimiento definidos. Estos escenarios simulan diferentes comportamientos de usuario, cargas y configuraciones del sistema para evaluar cómo funciona el software bajo distintas condiciones. Por ejemplo, los escenarios pueden incluir periodos de uso máximo, cargas altas de transacciones o picos repentinos en la actividad de usuarios.
3. Ejecución de Pruebas: Los escenarios de prueba se ejecutan en el sistema de software bajo los requerimientos de prueba. Durante esta fase, se miden y supervisan métricas de rendimiento como tiempos de respuesta, rendimiento, utilización de recursos y escalabilidad del sistema.
4. Análisis de Resultados y Mejora: Se analizan los datos de rendimiento recopilados para evaluar si el sistema cumple con los objetivos predefinidos. Este análisis ayuda a identificar cuellos de botella, limitaciones de escalabilidad y áreas donde el sistema podría no cumplir con los requisitos de rendimiento. Con base en el análisis de resultados, se realizan las mejoras y optimizaciones necesarias en el sistema de software.
5. Repetición del Proceso: La prueba de rendimiento basada en objetivos es un proceso iterativo. Después de realizar mejoras, se repite el ciclo de prueba para validar si se alcanzaron los objetivos de rendimiento y para identificar cualquier nuevo problema de rendimiento que pueda haber surgido.

Las pruebas de rendimiento se enfocan principalmente en verificar la velocidad y la fiabilidad de una aplicación, divididas en pruebas de carga (orientadas a objetivos) y pruebas de estrés. Con el auge de los métodos de desarrollo ágil, se ha vuelto crucial garantizar que los resultados de las pruebas de carga puedan reproducirse fácilmente.

La Importancia de Definir Objetivos de Rendimiento

Definir objetivos de rendimiento es la base fundamental de la prueba de rendimiento basada en objetivos. Estos objetivos sirven como la medida contra la que se evalúa el rendimiento del software. Proporcionan un marco tangible para evaluar si el software cumple con sus requisitos de rendimiento bajo varias condiciones, incluyendo uso normal, cargas máximas y escenarios de estrés.

Razones Clave para la Prueba de Rendimiento Basada en Objetivos

• Alineación con las Expectativas de los Stakeholders: Al definir objetivos específicos de rendimiento, aseguras que el rendimiento de tu software esté alineado con las expectativas de los stakeholders, incluidos los usuarios finales, clientes y patrocinadores del proyecto.
• Validación de Requisitos de Rendimiento: La prueba basada en objetivos ayuda a validar si tu software cumple con sus requisitos de rendimiento, proporcionando métricas concretas para evaluar la adecuación del rendimiento.
• Optimización del Uso de Recursos: La prueba basada en objetivos contribuye a optimizar el uso de recursos al identificar ineficiencias o sobreutilización de recursos del sistema, lo que conduce a una asignación más eficiente y ahorro de costos.
• Escalabilidad: Midiendo el rendimiento bajo cargas crecientes o concurrencia de usuarios, la prueba basada en objetivos evalúa la escalabilidad del software, asegurando que pueda manejar bases de usuarios y cargas de trabajo crecientes.
• Mitigación de Riesgos: Probar de manera proactiva contra objetivos de rendimiento predefinidos ayuda a identificar y mitigar riesgos relacionados con el rendimiento antes del despliegue del software, reduciendo la probabilidad de tiempos de inactividad, insatisfacción de usuarios o pérdidas económicas.

Caso de Uso Basado en Objetivos: Problema

Supongamos que 20 usuarios concurrentes generan 2,000 transacciones por hora en tu nueva aplicación CRM. Tu objetivo es diseñar una prueba de rendimiento que garantice un tiempo de respuesta de ocho segundos para las próximas cuatro versiones. Las pruebas de estrés pueden no replicar con precisión el rendimiento esperado en estas futuras versiones, ya que los tiempos de respuesta podrían variar respecto a la versión actual.

Caso de Uso Basado en Objetivos: Solución

1. Integra ThinkTimes en tus scripts para introducir pausas entre acciones de usuario.
2. Determina la base y mide el tiempo de ejecución de scripts de un solo usuario para calcular el tiempo de sesión.
3. Configura parámetros de carga de trabajo, incluyendo usuarios máximos, tasa de transacciones basada en objetivos y tiempo de transacción basada en objetivos.
4. Ejecuta la prueba de rendimiento basada en objetivos para simular la carga esperada en la aplicación.
5. Revisa el informe de prueba para verificar si la aplicación logró gestionar la carga dentro de los límites de tiempo de respuesta predefinidos.
6. Repite la ejecución de la prueba en las siguientes cuatro versiones para evaluar si la aplicación mantiene el rendimiento y los umbrales de tiempo de respuesta a lo largo del tiempo.

Recomendaciones y Consejos para Configurar la Herramienta EveryStep de LoadView

ThinkTime (requerido):

• Crea nuevas palabras clave en The EveryStep Web Recorder (ThinkTimes) o reutiliza palabras clave existentes.
• Asegúrate de que los valores permitidos sean puntos flotantes 0.0 – 999.99.
• Permite que los usuarios agreguen ThinkTimes manualmente a los scripts.
• Recuerda que ThinkTimes representa tiempos de espera y se añade automáticamente por EveryStep Web Recorder durante la grabación de acciones de usuario.
• Se pueden tener múltiples ThinkTimes en un mismo script.
• Los ThinkTimes se ignoran en ejecuciones de prueba de un solo script.
• Los ThinkTimes se utilizarán en la Calibración/Obtención de línea base.
• Los ThinkTimes no contribuyen a las mediciones de tiempo de respuesta.
• Los ThinkTimes se ignoran en pruebas de estrés.

Concurrencia de Usuarios (opcional):

• Introduce una nueva palabra clave “WaitFor (Número de usuarios)” en EveryStep Web Recorder.
• Este punto de espera global bloquea a los usuarios simulados en una sección específica del script hasta que el número esperado de usuarios alcance esa parte del script.

Umbrales de Tiempo de Respuesta (opcional):

• Implementa la nueva palabra clave SetBoundary en EveryStep Web Recorder.
• Sintaxis: SetBoundary(NombreDelTemporizador, Límite 1, Límite 2).

Línea Base/Calibración (requerido):

• LoadView ejecuta una prueba con un solo usuario.
• Los ThinkTimes se utilizarán tal como están guionizados.
• LoadView calcula el tiempo de sesión: Tiempo de Sesión = tiempo de ejecución del script + ThinkTime.

Configurar Carga de Trabajo/Plan de Ejecución (requerido):

• Los clientes especifican el tiempo de aumento gradual (ramp-up).
• Los clientes definen su tasa transaccional objetivo.
• Los clientes establecen el tiempo de sesión objetivo.
• El sistema calcula el número de usuarios.
• Los clientes deciden si calcular tiempos de respuesta durante el aumento gradual o no.

Ejecutar Prueba (requerido):

• LoadView ejecuta la prueba según la carga de trabajo/plan de ejecución configurado.
• LoadView recopila los tiempos de respuesta de scripts o transacciones simuladas.
• LoadView ajusta dinámicamente ThinkTime para alcanzar el rendimiento esperado; si la aplicación bajo prueba se ralentiza, los ThinkTimes se reducen. Si los ThinkTimes son cero y el tiempo de sesión excede el tiempo de sesión objetivo, se muestra un mensaje de error indicando que no se pudo alcanzar el rendimiento esperado.
• LoadView calcula los tiempos de respuesta de transacciones y temporizadores reales sin incluir los ThinkTimes.

Recomendaciones y Consejos para Integrar con Dotcom-Monitor

EveryStep Web Recorder

• Introducción de nuevas palabras clave ThinkTime.
• Ignorar ThinkTime durante ejecuciones de prueba con un solo usuario.
• Agregar ThinkTime durante la grabación del script.
• Introducción de la nueva palabra clave WaitFor (Número de usuarios).
• Introducción de la nueva palabra clave SetBoundary (NombreTemporizador, B1, B2).
• La palabra clave WaitFor debe añadirse manualmente a los scripts creados.
• Utilizar la palabra clave SetBoundary.

Calibración/Obtención de Línea Base

• Calcular el tiempo de sesión durante la calibración.

Plan de Ejecución/Carga de Trabajo

Opción 1:

• Agregar una nueva funcionalidad de configuración de carga de trabajo.
• Reemplazar el plan de ejecución por la característica de carga de trabajo.
• Crear un diálogo de configuración de carga de trabajo para soportar pruebas de estrés, objetivos de transacción y otros tipos.
• Especificar el tiempo de aumento gradual.
• Marcar la casilla para calcular tiempos de respuesta durante el aumento gradual (sí/no).

Opción 2:

• Usar la característica mejorada de configuración del plan de ejecución.
• Seleccionar el tipo de prueba (estrés, basada en objetivos).
• Establecer los detalles del objetivo de transacción.
• Especificar el tiempo de aumento gradual.
• Marcar la casilla para calcular tiempos de respuesta durante el aumento gradual (sí/no).

Ejecutar Prueba

• Calcular tiempo real de ejecución del script/tiempo de sesión.
• Ajustar dinámicamente los ThinkTimes basados en tiempo real de sesión.
• Generar una advertencia si no se pudo alcanzar el rendimiento esperado.

Informe

• Configurar una sección para tiempo de respuesta, real vs. umbrales por temporizador.
• Configurar una sección para rendimiento, real vs. esperado.

Consejos para Integrar con Dotcom-Monitor: Preguntas Frecuentes

¿Cuáles son las Entradas del Usuario?

• ThinkTimes (punto flotante, >0)
• Transacciones objetivo por hora (entero)
• Número máximo de usuarios (entero)
• Tiempo de aumento gradual (minutos)
• Calcular tiempo de respuesta durante el aumento gradual (Sí / No)

¿Qué es la Línea Base?

Una ejecución con un solo usuario del dispositivo o script, incorporando ThinkTimes. Se calcula y almacena el tiempo de ejecución del script como tiempo de sesión, junto con detalles adicionales como los recursos de ejecución requeridos.

¿Cómo puedes ajustar dinámicamente la prueba de carga si la velocidad de transacción cambia en el sistema objetivo?

• Calcular tiempo de sesión durante la calibración.
• Usar ThinkTimes para alcanzar el tiempo de sesión objetivo solicitado.
• Recalcular el tiempo real de sesión durante la ejecución de la prueba.
• Ajustar dinámicamente los ThinkTimes según el tiempo real de sesión.
• Registrar mensaje de error si el tiempo de ejecución del script es mayor al tiempo de sesión objetivo.
• Especificar el número máximo de usuarios en el cálculo de carga de trabajo.

¿Qué es la palabra clave WaitFor?

Esto simula escenarios complejos de usuarios, particularmente situaciones de concurrencia, lo cual es útil para probar si cierta funcionalidad funciona correctamente cuando varios usuarios acceden a un recurso simultáneamente.

¿Qué es la palabra clave SetBoundary?

Ayuda a verificar la velocidad real de una acción o temporizador contra los límites de tiempo de respuesta SLA especificados. Si se viola el límite permitido, aparece un mensaje de error que se registra en el informe de prueba, facilitando la verificación del SLA.

¿Cuáles deberían ser tus objetivos para la prueba de carga?

• Asegurar pruebas de rendimiento 100% comparables entre diferentes versiones/ejecuciones.
• Incluir funciones para simular patrones regulares o picos de carga.
• Lograr la confianza de que el sistema bajo prueba puede manejar la carga esperada dentro de los límites acordados.
• Enfocar la optimización de rendimiento en acciones de usuario que violen los límites acordados.

¿Qué tipo de informes deberías configurar?

• Crear informes similares a los informes actuales.
• Incluir tiempos de respuesta promedio, mínimo, máximo, desviación estándar y percentiles.
• Rastrear transacciones exitosas, transacciones fallidas y tasa de error.
• Todos los tiempos de respuesta deben ser sin inclusión de ThinkTimes.

Limitaciones

Tiempos de sesión muy altos pueden conducir a expiraciones de sesión y falsos positivos. Es crucial considerar escenarios donde los tiempos de expiración de sesión web sean bajos, asegurando que los ThinkTimes estén adecuadamente ubicados para evitar fallas por expiración de sesión.

¿Qué sucederá si no alcanzamos el objetivo?

• Si el tiempo de respuesta de una aplicación bajo prueba se ralentiza y el tiempo de sesión excede el tiempo de sesión objetivo, no se podrá alcanzar la tasa transaccional esperada.
• LoadView monitorea el tiempo real de sesión durante la ejecución de la prueba y ajusta los ThinkTimes para intentar alcanzar la tasa transaccional basada en objetivos esperada.
• LoadView muestra mensajes de error en la pantalla de monitoreo si el tiempo de sesión excede el tiempo de sesión objetivo.
• LoadView continúa con la ejecución de la prueba si no se puede alcanzar la tasa transaccional objetivo, marcando la ejecución como fallida e indicando los dispositivos afectados en el informe.

¿Cómo es una carga de trabajo basada en objetivos de ejemplo?

•  Tiempo de aumento gradual: 15 minutos
• Medir tiempos de respuesta durante aumento gradual: Sí / No
  ST: Tiempo de Sesión
• GST: Tiempo de Sesión Objetivo
• TPH: Transacciones por hora
• Usuario: Calculado por LoadView (3600 / TPH) * GST = 72