Pruebas de rendimiento basadas en objetivos

Las pruebas de rendimiento basadas en objetivos son una estrategia empleada en las pruebas de software, en particular las pruebas de rendimiento, para garantizar que los sistemas de software cumplan con objetivos de rendimiento específicos en diversas condiciones. En las pruebas de rendimiento basadas en objetivos, el proceso de pruebas se basa en metas u objetivos predefinidos en lugar de solo probar por el simple hecho de hacerlo.

Las pruebas basadas en objetivos funcionan mediante los siguientes pasos:

1. Definición de objetivos de rendimiento: El primer paso consiste en definir qué objetivos de rendimiento son importantes para el sistema de software que se está probando. Estos objetivos podrían incluir umbrales de tiempo de respuesta, requisitos de rendimiento, objetivos de utilización de recursos y pruebas comparativas de escalabilidad.
2. Diseño de escenarios de prueba: Los escenarios de prueba se diseñan en función de los objetivos de rendimiento definidos. Estos escenarios simulan diferentes comportamientos de usuario, cargas y configuraciones del sistema para evaluar el rendimiento del software en diversas condiciones. Por ejemplo, los escenarios pueden incluir períodos de uso máximo, cargas de transacciones pesadas o picos repentinos en la actividad del usuario.
3. Ejecución de pruebas: Los escenarios de prueba se ejecutan en el sistema de software bajo los requisitos de prueba. Durante esta fase, se miden y supervisan las métricas de rendimiento, como los tiempos de respuesta, el rendimiento, la utilización de recursos y la escalabilidad del sistema.
4. Análisis de resultados y mejoras: Los datos de rendimiento recopilados se analizan para evaluar si el sistema cumple con los objetivos predefinidos. Este análisis ayuda a identificar los cuellos de botella de rendimiento, las limitaciones de escalabilidad y las áreas en las que el sistema puede no cumplir los requisitos de rendimiento. Con base en el análisis de los resultados de las pruebas, realice las mejoras y optimizaciones necesarias en su sistema de software.
5. Repetir el proceso: Las pruebas de rendimiento basadas en objetivos son un proceso iterativo. Después de realizar mejoras, el ciclo de pruebas se repite para validar si se han alcanzado los objetivos de rendimiento e identificar cualquier nuevo problema de rendimiento que pueda haber surgido.

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

La importancia de definir objetivos de rendimiento

La definición de los objetivos de rendimiento es la piedra angular de las pruebas de rendimiento basadas en objetivos. Estos objetivos sirven como la vara de medir con la que se mide el rendimiento del software. Proporcionan un marco tangible para evaluar si el software cumple con sus requisitos de rendimiento en diversas condiciones, incluido el uso normal, las cargas máximas y los escenarios de estrés.

Razones clave para las pruebas de rendimiento basadas en objetivos

• Alinearse con las expectativas de las partes interesadas: Al definir objetivos de rendimiento específicos, se asegura de que el rendimiento de su software se alinee con las expectativas de las partes interesadas, incluidos los usuarios finales, los clientes y los patrocinadores del proyecto.
• Validación de los requisitos de rendimiento: Las pruebas basadas en objetivos ayudan a validar si su software cumple con sus requisitos de rendimiento, proporcionando métricas concretas para evaluar la adecuación del rendimiento.
• Optimización de la utilización de recursos: Las pruebas basadas en objetivos ayudan a optimizar la utilización de los recursos mediante la identificación de ineficiencias o la sobreutilización de los recursos del sistema, lo que conduce a una asignación de recursos más eficiente y a un ahorro de costes.
• Escalabilidad: Al medir el rendimiento bajo cargas crecientes o simultaneidad de usuarios, las pruebas basadas en objetivos evalúan la escalabilidad de su software, lo que garantiza que pueda manejar bases de usuarios y cargas de trabajo en crecimiento.
• Mitigación de riesgos: Las pruebas proactivas con respecto a los objetivos de rendimiento predefinidos ayudan a identificar y mitigar los riesgos relacionados con el rendimiento antes de implementar el software, lo que reduce la probabilidad de tiempo de inactividad, insatisfacción del usuario o pérdidas financieras.

Caso de uso basado en objetivos: Problema

Supongamos que 20 usuarios simultáneos generan 2.000 transacciones por hora en la nueva aplicación CRM. Su objetivo es diseñar una prueba de rendimiento que garantice un tiempo de respuesta de ocho segundos para las próximas cuatro versiones. Es posible que las pruebas de esfuerzo no reproduzcan con precisión el rendimiento esperado en estas próximas versiones, ya que los tiempos de respuesta podrían variar con respecto a la versión actual.

Caso de uso basado en objetivos: Solución

1. Integre ThinkTimes en sus scripts para introducir pausas entre las acciones del usuario.
2. Determine la línea de base y mida el tiempo de ejecución de los scripts de un solo usuario para calcular el tiempo de sesión.
3. Configure los parámetros de la carga de trabajo, incluidos el número máximo de usuarios, la tasa de transacciones basada en objetivos y el tiempo de transacción basado en objetivos.
4. Ejecute la prueba de rendimiento basada en objetivos para simular la carga esperada en la aplicación.
5. Revise el informe de prueba para comprobar si la aplicación logró controlar la carga dentro de los límites de tiempo de respuesta predefinidos.
6. Repita la ejecución de prueba en las cuatro versiones siguientes para evaluar si la aplicación mantiene los umbrales de rendimiento y tiempo de respuesta a lo largo del tiempo.

Recomendaciones y sugerencias para configurar la herramienta EveryStep de LoadView

ThinkTime (obligatorio):

• Cree nuevas palabras clave en EveryStep Web Recorder (ThinkTimes) o reutilice las palabras clave existentes.
• Asegúrese de que los valores permitidos sean puntos flotantes de 0,0 a 999,99.
• Permita que los usuarios agreguen manualmente ThinkTimes a los scripts.
• Recuerde que ThinkTimes representa los tiempos de espera y EveryStep Web Recorder lo agrega automáticamente durante la grabación de las acciones del usuario.
• Pueden existir varios ThinkTimes en un script.
• Los ThinkTimes no se tienen en cuenta en las ejecuciones de prueba de un solo script.
• ThinkTimes se utilizará en Calibration/Get Baseline.
• ThinkTimes no contribuye a las mediciones del tiempo de respuesta.
• Los ThinkTimes se ignoran en las pruebas de estrés.

Simultaneidad de usuarios (opcional):

• Introduzca 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 de script específica hasta que el número esperado de usuarios alcance esta parte del script.

Umbrales de tiempo de respuesta (opcional):

• Implemente la nueva palabra clave SetBoundary en EveryStep Web Recorder.
• Sintaxis: SetBoundary(Timername, Bound 1, Bound 2).

Línea de base/calibración (obligatorio):

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

Configurar la carga de trabajo/plan de ejecución (obligatorio):

• Los clientes especifican el tiempo de puesta en marcha.
• Los clientes definen su tasa de transacción objetivo.
• Los clientes establecen el tiempo objetivo de la sesión.
• El sistema calcula el número de usuarios.
• Los clientes deciden si calculan o no los tiempos de respuesta durante la puesta en marcha.

Ejecutar prueba (obligatorio):

• LoadView ejecuta la prueba de acuerdo con la carga de trabajo o el plan de ejecución configurados.
• LoadView recopila los tiempos de respuesta de scripts o transacciones simulados.
• LoadView ajusta dinámicamente ThinkTime para lograr el rendimiento esperado; si la aplicación sometida a prueba se ralentiza, los ThinkTimes se reducen. Si ThinkTimes es cero y el tiempo de sesión supera el tiempo de sesión objetivo, se genera un mensaje de error que indica que no se pudo alcanzar el rendimiento esperado.
• LoadView calcula los tiempos de respuesta de las transacciones y temporizadores reales sin ThinkTimes.

Recomendaciones y consejos para la integración con Dotcom-Monitor

EveryStep Web Recorder

• Presentamos las nuevas palabras clave de ThinkTime.
• Omita ThinkTime durante las ejecuciones de prueba de un solo usuario.
• Agregue ThinkTime durante la grabación de guiones.
• Introduzca la nueva palabra clave WaitFor(Número de usuario).
• Introduzca la nueva palabra clave SetBoundary(TimerName, B1, B2).
• La palabra clave WaitFor debe agregarse manualmente a los scripts creados.
• Utilice la palabra clave SetBoundary.

Calibración/Obtener línea de base

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

Plan de ejecución/carga de trabajo

Opción 1:

• Agregue una nueva característica de configuración de carga de trabajo.
• Reemplace el plan de ejecución por la característica Carga de trabajo.
• Cree un cuadro de diálogo de configuración de carga de trabajo para admitir pruebas de esfuerzo, objetivos de transacción y otros tipos.
• Especifique el tiempo de puesta en marcha.
• Marque la casilla para calcular los tiempos de respuesta durante la aceleración (sí/no).

Opción 2:

• Utilice la característica de configuración del plan de ejecución mejorado.
• Seleccione el tipo de prueba (estrés, basada en objetivos).
• Establezca los detalles del objetivo de la transacción.
• Especifique el tiempo de puesta en marcha.
• Marque la casilla para calcular los tiempos de respuesta durante la aceleración (sí/no).

Prueba de ejecución

• Calcule el tiempo real de ejecución del script/tiempo de sesión.
• Ajuste dinámicamente ThinkTimes en función del tiempo real de la sesión.
• Genere una advertencia si no se pudo alcanzar el rendimiento esperado.

Informe

• Configure una sección para el tiempo de respuesta, real frente a umbrales por temporizador.
• Configure una sección para el rendimiento, real frente a esperado.

Consejos para la integración con Dotcom-Monitor: Preguntas frecuentes

¿Cuáles son las entradas de usuario?

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

¿Qué es la línea de base?

Una sola ejecución del dispositivo o script por parte de un solo usuario, incorporando ThinkTimes. El tiempo de ejecución del script se calcula y almacena como tiempo de sesión, junto con detalles adicionales como los recursos de ejecución necesarios.

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

• Calcular el tiempo de sesión durante la calibración
• Utilice ThinkTimes para alcanzar el tiempo de sesión de meta solicitado
• Recalcular el tiempo de sesión real durante la ejecución de la prueba
• Ajuste dinámicamente ThinkTimes dependiendo del tiempo real de la sesión
• Mensaje de error de registro si el tiempo de ejecución del script es > el tiempo de sesión del objetivo
• Especifique el número de usuarios máximos en el cálculo de la carga de trabajo

¿Qué es la palabra clave WaitFor?

Esto simula escenarios de usuario complejos, en particular situaciones de simultaneidad, lo que resulta útil para probar si cierta funcionalidad funciona correctamente con varios usuarios que acceden a un recurso simultáneamente.

¿Qué es la palabra clave SetBoundary?

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

¿Cuáles deben ser sus objetivos para su prueba de carga?

• Garantice pruebas de rendimiento 100 % comparables en diferentes versiones/ejecuciones.
• Incluya funciones para simular patrones de carga regulares o picos.
• Logre la confianza de que el sistema bajo prueba puede manejar la carga esperada dentro de los límites acordados.
• Centra la optimización del rendimiento en las acciones del usuario que infringen los límites acordados.

¿Qué tipo de informes debe configurar?

• Cree informes similares a los informes actuales.
• Incluya los tiempos de respuesta promedio, mínimo, máximo, estándar y percentil.
• Realizar un seguimiento de las transacciones correctamente, Transacciones fallidas y Tasa de error.
• Todos los tiempos de respuesta deben ser sin la inclusión de ThinkTimes.

Limitaciones

Los tiempos de sesión de objetivos altos pueden provocar tiempos de espera de sesión y falsos positivos. Es fundamental tener en cuenta los escenarios en los que los tiempos de espera de las sesiones web son bajos, lo que garantiza que los ThinkTimes estén colocados correctamente para evitar errores debido a los tiempos de espera de las sesiones.

¿Qué pasará si no alcanzamos la meta?

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

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

• Tiempo de puesta en marcha: 15 minutos
• Medir los tiempos de respuesta durante la rampa: Sí / No
  ST: Tiempo de sesión
• GST: Tiempo de la sesión de gol
• TPH: Transacciones por hora
• Usuario: Calculado por LoadView (3600 / TPH) * GST = 72