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 , poder 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 estrés y se utiliza a menudo para identificar puntos de ruptura 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:
- Añadir ThinkTimes a sus scripts
- 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
- 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
- Ejecute la prueba de rendimiento basada en objetivos para simular la carga esperada
- Revise el informe de prueba y compruebe si la aplicación sometida a prueba pudo manejar la carga dentro de los límites de tiempo de respuesta acordados
- 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