¿Qué son las pruebas de resistencia en las pruebas de software? (con ejemplo)

⚡ Resumen inteligente

Las pruebas de resistencia ejecutan una aplicación bajo una carga normal durante un período prolongado para determinar si su rendimiento se degrada con el tiempo. Es la prueba que detecta los defectos que una prueba de carga de una hora no puede revelar.

  • 🕒 Carga sostenida: Se esperaba que el tráfico de producción se mantuviera durante horas o días en lugar de minutos.
  • 📉 Enfoque en la degradación: La cuestión es si los tiempos de respuesta aumentan progresivamente, no si el objetivo se alcanza una sola vez.
  • ???? Hallazgos comunes: Fugas de memoria, agotamiento del grupo de conexiones y crecimiento ilimitado del registro o la caché.
  • 📊 Conjunto de monitoreo: Memoria, CPU, tiempo de respuesta, rendimiento y conexiones a la base de datos durante toda la ejecución.
  • 🛠️ Estampación: Las herramientas de carga estándar gestionan el tráfico, mientras que las herramientas APM registran las curvas de recursos.
  • 🇧🇷 Compensación: Los resultados son valiosos, pero tardan en obtenerse, lo que limita la frecuencia con la que se puede ejecutar la prueba.

¿Qué son las pruebas de resistencia?

¿Qué son las pruebas de resistencia?

Pruebas de resistencia Es un tipo de prueba de software no funcional en el que se prueba un software con una carga elevada prolongada durante un período de tiempo significativo para evaluar el comportamiento de la aplicación de software en condiciones de uso sostenido. El objetivo principal de las pruebas de resistencia es garantizar que la aplicación sea lo suficientemente capaz de manejar una carga prolongada sin ningún deterioro del tiempo de respuesta.

Este tipo de prueba se realiza en la última etapa del ciclo de ejecución de rendimiento. Las pruebas de resistencia son un proceso largo y, a veces, duran incluso hasta un año. Esto puede incluir la aplicación de cargas externas, como tráfico de Internet o acciones del usuario. Esto hace que las pruebas de resistencia difieran de las Prueba de carga, que suele finalizar en un par de horas aproximadamente.

Resistencia significa capacidad, por lo que, en otras palabras, puede denominar pruebas de resistencia como pruebas de capacidad.

Objetivos de las pruebas de resistencia

  • El objetivo principal de las pruebas de resistencia es comprobar si hay pérdidas de memoria.
  • Descubrir cómo funciona el sistema en condiciones de uso sostenido.
  • Para garantizar que después de un período prolongado, el tiempo de respuesta del sistema siga siendo el mismo o mejor que al inicio de la prueba.
  • Determinar la cantidad de usuarios y/o transacciones que un sistema determinado admitirá y cumplirá con los objetivos de rendimiento.
  • Para gestionar las cargas futuras, debemos comprender cuántos recursos adicionales (como la capacidad del procesador, la capacidad del disco, el uso de la memoria o el ancho de banda de la red) son necesarios para soportar el uso en el futuro.
  • Las pruebas de resistencia generalmente se realizan sobrecargando el sistema o reduciendo ciertos recursos del sistema y evaluando las consecuencias.
  • Se realiza para garantizar que no se produzcan defectos o pérdidas de memoria después de lo que se considera un período de uso relativamente "normal".

Qué monitorizar en las pruebas de resistencia

Pruebas de resistencia

En las pruebas de resistencia se prueban los siguientes aspectos:

  • Prueba de pérdida de memoria– Se realizan comprobaciones para verificar si hay alguna pérdida de memoria en la aplicación, lo que puede causar fallas en el sistema o en el sistema operativo.
  • Prueba de cierre de conexión entre la capa del sistema. – Si la conexión entre las capas del sistema no se cierra correctamente, se pueden bloquear algunos o todos los módulos del sistema.
  • La conexión de la base de datos de prueba se cerró correctamente– Si la conexión a la base de datos no se cierra correctamente, puede provocar un fallo del sistema.
  • Tiempo de respuesta de la prueba – Se prueba el tiempo de respuesta del sistema, ya que la aplicación se vuelve menos eficiente como resultado del uso prolongado del sistema.

Cómo realizar pruebas de resistencia

A continuación se muestra el enfoque de prueba básico para la prueba de resistencia.

  • Entorno de prueba – Identifique el hardware, software, sistema operativo requerido para las pruebas de resistencia, asignando roles y responsabilidades dentro del equipo, etc. El entorno debe estar listo antes de la ejecución de la prueba. También es necesario estimar el tamaño de producción de bases de datos comunes y el crecimiento anual. Esto es necesario, por lo que debe probar cómo responderá su aplicación después de un año, dos o cinco.
  • Creación del plan de prueba, escenarios – Según la naturaleza de las pruebas: manual, automática o una combinación de ambas, Caso de prueba Se deben planificar el diseño, las revisiones y la ejecución. Las pruebas para estresar el sistema, pruebas de punto de ruptura, etc. también deben ser parte del plan de pruebas. Las pruebas para estresar el sistema determinan el punto de ruptura en la aplicación.
  • Estimación de prueba – Proporcione una estimación de cuánto tiempo llevará completar la fase de prueba. Debe analizarse en función del número de probadores involucrados y del número de ciclos de prueba necesarios.
  • Análisis de riesgo - Analizar el riesgo y tomar las medidas adecuadas para su prevención. Priorización de los casos de prueba según el factor de riesgo e identificación de los siguientes riesgos y problemas que el evaluador puede realizar durante la prueba de resistencia.
  • ¿El rendimiento se mantendrá constante a lo largo del tiempo?
  • ¿Hay otros problemas menores que aún no se han detectado?
  • ¿Existe interferencia externa que no se abordó?
  • Calendario de pruebas - Determinar el presupuesto, entregables dentro de los plazos. Como Pruebas de resistencia aplica una disposición de carga enorme pero natural de transacciones al sistema/aplicación durante un período de tiempo continuo.

Ejemplo de prueba de resistencia

Aunque Prueba de esfuerzo lleva el sistema probado a sus límites, Pruebas de resistencia lleva la aplicación al límite con el tiempo.

Por ejemplo, los problemas más complejos —fugas de memoria, uso excesivo del servidor de base de datos y sistemas que no responden— ocurren cuando el software se ejecuta durante un período prolongado. Si se omiten las pruebas de resistencia, las probabilidades de detectar estos defectos antes de la implementación son muy bajas.

Herramientas de prueba de resistencia

Ventajas de las pruebas de resistencia

  • Ayuda a determinar cómo puede manejar la carga de trabajo el sistema bajo carga.
  • Proporciona datos precisos que el cliente puede utilizar para validar o mejorar sus necesidades de infraestructura.
  • Identifica problemas de rendimiento que pueden ocurrir después de que un sistema haya estado funcionando a un nivel alto durante un período de tiempo más largo.
  • Los problemas típicos se identifican en pruebas de rendimiento específicas más pequeñas, lo que significa que garantiza que la aplicación permanezca disponible incluso cuando hay una carga enorme en un lapso de tiempo muy corto.
  • La prueba de resistencia también se utiliza para comprobar si hay alguna degradación del rendimiento después de un largo período de ejecución.

Desventajas de las pruebas de resistencia

  • A menudo es difícil definir cuánto estrés vale la pena aplicar.
  • Las pruebas de resistencia podrían causar fallas en la aplicación y/o en la red que pueden resultar en una interrupción significativa si Entorno de prueba no están aislados.
  • La pérdida o corrupción permanente de datos puede ocurrir al sobrecargar el sistema.
  • La utilización de recursos sigue siendo muy alta una vez que se elimina el estrés.
  • Algunos componentes de la aplicación no responden.
  • El usuario final observa las excepciones no controladas.

Cómo encaja esta prueba en la familia de pruebas de rendimiento

Las pruebas de rendimiento son un término general. Las variantes que se describen a continuación solo difieren en la forma de la carga aplicada y la duración de la misma, razón por la cual suelen confundirse entre sí.

Tipo de prueba Patrón de carga Pregunta que responde
Prueba de carga Carga máxima prevista, corta duración ¿El sistema cumple sus objetivos en condiciones normales de tráfico máximo?
Prueba de esfuerzo Aumentado más allá de la capacidad hasta el fallo ¿Dónde falla y lo hace de forma elegante?
prueba de picos Aumento repentino y extremo, seguido de una remisión. ¿Sobrevive y se recupera de un impacto de tráfico?
Pruebas de resistencia La carga normal se mantuvo durante muchas horas. ¿El rendimiento se degrada con el tiempo?
Prueba de remojo Carga sostenida durante un período prolongado ¿Hay fugas de memoria o agotamiento de recursos?
Prueba de estabilidad Carga variable en función de las condiciones ¿El sistema sigue siendo fiable a medida que cambian las condiciones?
Pruebas de volumen Usuarios normales, volumen de datos muy grande ¿Puede soportar el crecimiento de la base de datos?

Las pruebas de resistencia y las pruebas de inmersión se suelen tratar como sinónimos. En el uso común, se utilizan para evaluar si ambas pruebas soportan una carga sostenida durante un período prolongado. Cuando los equipos las distinguen, las pruebas de resistencia se centran en si los tiempos de respuesta aumentan, mientras que las pruebas de estrés se centran en el consumo de recursos como la memoria, los descriptores de archivo y los grupos de conexiones. Generalmente, ejecutar una de estas pruebas proporciona evidencia para ambas.

Métricas clave para registrar durante la prueba

Una prueba de rendimiento es tan buena como lo que se registra durante su ejecución. Captura estos seis parámetros tanto en el servidor como en el cliente, y luego compáralos con la línea base en lugar de guiarte por una intuición.

Métrico Lo que te dice Señal de advertencia
Tiempo promedio de respuesta Experiencia de usuario típica Cualquier desviación ascendente a lo largo de la carrera
tiempo de respuesta del percentil 95 La experiencia de los usuarios más lentos Muy por encima del promedio, lo que significa inconsistencia.
Throughput Solicitudes procesadas por segundo Caída mientras la carga permanece constante
Tasa de error Porcentaje de solicitudes fallidas o con tiempo de espera agotado Cualquier aumento por encima del umbral acordado
Uso de CPU y memoria margen de recursos del servidor Memoria que asciende y nunca regresa
Conexiones de base de datos e hilos Agotamiento de la piscina Recuentos que crecen constantemente sin liberación

Lee el promedio y el percentil juntos. Un promedio de 800 ms con un percentil 95 de 900 ms describe un sistema consistente. El mismo promedio con un percentil 95 de 9 segundos significa que uno de cada veinte usuarios está teniendo problemas, y el promedio lo está ocultando.

Fíjate en la forma, no solo en el valor. En cualquier prueba de larga duración, una línea de recursos plana indica que la prueba ha superado la prueba, mientras que una línea ascendente indica una fuga, incluso cuando el número absoluto todavía se encuentra cómodamente dentro del límite en el momento en que finaliza la ejecución.

Pruebas de resistencia: Conclusiones clave

  • In Ingeniería de SoftwareLas pruebas de resistencia son un subconjunto de las pruebas de carga.
  • Las pruebas de resistencia son un proceso largo y, a veces, duran incluso hasta un año.
  • Se realizan controles para verificar
  • Prueba de pérdida de memoria
  • Tiempo de respuesta de la prueba
  • Probar la conexión de la base de datos, etc.

Preguntas Frecuentes

Las pruebas de carga verifican que el sistema cumpla con sus objetivos a carga máxima durante un período corto. Las pruebas de resistencia mantienen una carga normal durante horas para determinar si dichos objetivos se mantienen al final del período.

Cualquier tendencia ascendente sostenida en el tiempo de respuesta o el uso de recursos, incluso si no se supera ningún umbral, constituye un defecto. Esta tendencia es la causa del problema, ya que eventualmente sobrepasará el límite en producción.

Una vez superadas las pruebas funcionales y de carga, y con la suficiente antelación como para que se pueda solucionar cualquier fuga de memoria detectada, ejecutar la prueba la noche anterior al lanzamiento no deja tiempo para actuar en función del resultado.

La monitorización basada en IA detecta el punto en el que una métrica cambia de tendencia y la correlaciona con despliegues o trabajos programados, convirtiendo horas de gráficos en un posible sospechoso.

Puede ayudar a priorizar. Los modelos de riesgo resaltan qué versiones afectan al código propenso a fugas de memoria, de modo que las ejecuciones completas se reservan para los cambios que tienen más probabilidades de necesitarlas.

Resumir este post con: