fbpx

Pruebas de rendimiento basadas en objetivos con LoadView

Las pruebas de rendimiento verifican principalmente la velocidad y fiabilidad de una aplicación y se dividen en pruebas de carga (basadas en objetivos) y pruebas de esfuerzo. Desde el auge de los métodos de desarrollo ágiles, ser capaz de reproducir los resultados de las pruebas de carga se ha convertido en una prioridad.

¿Cuáles son las razones de las pruebas de estrés?

La forma más fácil de configurar las pruebas de rendimiento es permitiendo que varios usuarios ejecuten scripts de prueba de forma iterativa. Este tipo de prueba se denomina prueba de esfuerzo y a menudo se utiliza para identificar puntos de interrupción en aplicaciones empresariales. El inconveniente es que el tiempo de respuesta real de la aplicación es principalmente responsable de la carga simulada y no se puede controlar el rendimiento real. En las pruebas de escalabilidad, esto no es un problema, pero para una comparación de rendimiento entre diferentes versiones puede ser problemático.

¿Cuáles son las razones de las pruebas de rendimiento basadas en objetivos?

La principal ventaja de este tipo de prueba es que permite mediciones de velocidad en condiciones realistas y reproducibles y límites de rendimiento. Las pruebas de rendimiento basadas en objetivos se usan a menudo para validar acuerdos de nivel de servicio en entornos de producción.

Considere la siguiente situación:

Supongamos que 20 usuarios simultáneos crearán 2.000 transacciones en la nueva aplicación CRM por hora. Tiene la tarea de crear una prueba de rendimiento que compruebe que el tiempo de respuesta de ocho segundos para esta aplicación podría lograrse en las cuatro versiones siguientes. Lo más probable es que una prueba de esfuerzo no permita la simulación exacta del rendimiento esperado en las cuatro pruebas de rendimiento de la versión porque no puede suponer que el tiempo de respuesta seguirá siendo el mismo que en la versión real.

Solución:

  1. Añadir ThinkTimes a sus scripts
  2. Busque la línea de base y el tiempo de ejecución de script de un solo usuario para obtener el tiempo de sesión
  3. Configure la carga de trabajo, incluidos los usuarios máximos, 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
  5. Revise el informe de prueba y compruebe si la aplicación que se está probando pudo manejar la carga dentro de los límites de tiempo de respuesta acordados
  6. Repita esta ejecución de prueba en las cuatro versiones siguientes y compruebe si la aplicación pudo contener umbrales de rendimiento y tiempo de respuesta

Consejos para configurar la herramienta EveryStep

ThinkTime (obligatorio)

Cree nuevas palabras clave en The EveryStep Web Recorder (ThinkTimes) o reutile las palabras clave existentes

Asegúrese de que los valores permitidos son puntos flotantes 0,0 – 999,99

Asegúrese de que los usuarios pueden agregar ThinkTimes manualmente a los scripts

Recuerde que ThinkTimes son tiempos de espera y añadidos por EveryStep Web Recorder automáticamente durante la grabación de las acciones del usuario.

Puede haber N ThinkTimes en un script

ThinkTimes se ignoran en ejecuciones de prueba de script único

ThinkTimes se utilizará en Calibración / Obtener línea de base

Los ThinkTimes no forman parte de las mediciones del tiempo de respuesta

Los ThinkTimes se ignoran en las pruebas de esfuerzo

Simultaneidad de usuario (opcional)

Nueva palabra clave «WaitFor (Number of users)» en EveryStep Web Recorder

Este es un punto de espera global que bloquea a los usuarios simulados en un determinado punto de los scripts hasta que el número esperado de usuarios haya llegado a esta sección del script

Umbrales de tiempo de respuesta (opcional)

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 única ejecución de prueba de usuario

ThinkTimes se usará como scripted

LoadView calculará el tiempo de sesión

Tiempo de sesión: tiempo de ejecución del script + ThinkTime

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

El cliente establece el tiempo de rampa

El cliente establece la tasa de transacción de objetivos

El cliente establece el tiempo de sesión objetivo

El sistema calcula el número de usuarios

El cliente decide si calcular los tiempos de respuesta durante el aumento o no

Ejecutar prueba (obligatorio)

LoadView ejecuta la prueba de acuerdo con la carga de trabajo/plan de ejecución configurado

LoadView recopila tiempos de respuesta de scripts o transacciones simuladas

LoadView ajusta dinámicamente ThinkTime para alcanzar el rendimiento esperado, si la aplicación sometida a prueba ralentiza que se reduzcan los Tiempos de reflexión. Si ThinkTimes es cero y el tiempo de sesión obtiene > el tiempo de sesión de objetivo, se generará 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.

Consejos para la integración con Dotcom-Monitor

EveryStep Web Recorder

Introducir nuevas palabras clave de ThinkTime

Ignorar ThinkTime durante las ejecuciones de prueba de un solo usuario

Añadir ThinkTime durante la grabación de guiones

Introducir nueva palabra clave WaitFor (usuario numérico)

Introducir 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

Calcular 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

Reemplazar plan de ejecución con la función De trabajo

Crear cuadro de diálogo de configuración de carga de trabajo para admitir pruebas de esfuerzo, objetivo de transacción y otros tipos

Especifique el tiempo de ampliación

Marque la casilla para calcular los tiempos de respuesta durante el aumento (sí/no)

Opción 2:

Utilice la función de configuración del plan de ejecución mejorada

Seleccionar tipo de prueba (estrés, basado en objetivos)

Establezca los detalles del objetivo de transacción

Especifique el tiempo de ampliación

Marque la casilla para calcular los tiempos de respuesta durante el aumento (sí/no)

Prueba de ejecución

Calcular el tiempo de ejecución real del script/tiempo de sesión

Ajuste dinámicamente Los ThinkTimes en función del tiempo real de la sesión

Aumentar la advertencia si no se pudo alcanzar el rendimiento esperado

Informe

Configure una sección para el tiempo de respuesta, real vs umbrales por temporizador

Configure una sección para el rendimiento, real frente a lo esperado

¿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 «Baseline»?

Una sola ejecución de usuario del dispositivo o script. Los tiempos de reflexión se utilizan en el parámetro. El tiempo de ejecución del script se calcula y se almacena como tiempo de sesión. También se calculan 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 ayuda a simular escenarios de usuario complejos, como situaciones de simultaneidad. Es muy útil si tiene que probar si cierta funcionalidad funciona correctamente si x número de usuarios están accediendo a un recurso al mismo tiempo.

¿Qué es la palabra clave SetBoundary?

Los SLA especifican límites de tiempo de respuesta para las acciones del usuario, como la búsqueda de un cliente. La palabra clave SetBoundary le ayuda a verificar la velocidad real de una determinada acción o temporizador. Si se infringe el límite permitido, aparece un mensaje de error que se registrará en el informe de prueba. La verificación de SLA es mucho más fácil con esta nueva palabra clave SetBoundary

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

  • Pruebas de rendimiento 100 por ciento comparables en diferentes versiones/ejecuciones
  • Característica para la simulación de patrones de carga regulares o picos
  • Confianza en que el sistema que se está probando puede manejar la carga esperada dentro de los límites acordados
  • Centrar la optimización del rendimiento en las acciones del usuario que violaron los límites acordados

¿Qué tipo de informes debe configurar?

  • Cree informes similares a los informes actuales
  • Promedio, Min, Max, Stddev, Percentile tiempos de respuesta
  • Transacciones ok, Transacciones fallidas
  • Tasa de errores
  • Todos los tiempos de respuesta deben ser sin el ThinkTimes

Limitaciones

Los tiempos de sesión de objetivos altos pueden provocar tiempos de espera de sesión y falsos positivos. Considere situaciones en las que el tiempo de espera de la sesión web es muy bajo, como 10 minutos. Si ejecuta una prueba de rendimiento basada en objetivos con un script simple que ejecuta un inicio de sesión y una búsqueda de cliente, debe colocar ThinkTime entre login y search. En esta situación hipotética, el tiempo de sesión debe ser 10 segundos el tiempo de sesión de meta 700 segundos. En este escenario, ThinkTime será mayor que el tiempo de espera de sesión de la aplicación que se está probando. Se producirá un error en todas las transacciones simuladas porque el script se ejecutará en el tiempo de espera de la sesión web y no podrá realizar la búsqueda del cliente.

¿Qué sucederá 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 es superior al tiempo de sesión de objetivo, no se puede alcanzar la tasa de transacción esperada.

LoadView observa el tiempo de sesión real durante la ejecución de la prueba y ajusta ThinkTimes para alcanzar la tasa de transacciones basada en objetivos esperada.

LoadView también muestra el mensaje de error en la pantalla de supervisión si el tiempo de sesión es mayor que el tiempo de sesión de objetivo.

LoadView también continúa con la ejecución de la prueba si no se puede lograr la tasa de transacciones de objetivo. En esta situación, la ejecución de prueba se marcará con el estado de error. La prueba mostraría claramente que no se pudo alcanzar el rendimiento esperado debido a la ralentización de los tiempos de respuesta e indicaría qué dispositivos se ven afectados.

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

Script / Dispositivo ST (seg)

No editable

GST (seg)

Entrada del usuario

Tph

Entrada del usuario

Usuario

No editable

Search_User 25 10 500 72
Inser_User 25 60 1000 216

Tiempo de aumento: 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 a 72