Las pruebas de estrés son una actividad de prueba de software que determina la solidez del software probando más allá de los límites del funcionamiento normal. Las pruebas de estrés son particularmente importantes para el software "de misión crítica ", pero se utilizan para todo tipo de software. Las pruebas de estrés suelen poner más énfasis en la robustez, la disponibilidad y el manejo de errores bajo una carga pesada, que en lo que se consideraría un comportamiento correcto en circunstancias normales.
Experiencia de campo
Las fallas pueden estar relacionadas con:
- características de entornos que no son de producción, por ejemplo, pequeñas bases de datos de prueba
- ausencia total de pruebas de carga o estrés
Razón fundamental
Las razones de las pruebas de estrés incluyen:
- El software que se está probando es de "misión crítica", es decir, una falla del software (como un bloqueo ) tendría consecuencias desastrosas.
- La cantidad de tiempo y recursos dedicados a las pruebas no suele ser suficiente, con los métodos de prueba tradicionales, para probar todas las situaciones en las que se utilizará el software cuando se lance.
- Incluso con el tiempo y los recursos suficientes para escribir las pruebas, es posible que no sea posible determinar de antemano todas las diferentes formas en que se utilizará el software. Esto es particularmente cierto para los sistemas operativos y middleware , que eventualmente serán utilizados por software que ni siquiera existe en el momento de la prueba.
- Los clientes pueden usar el software en computadoras que tienen significativamente menos recursos computacionales (como memoria o espacio en disco ) que las computadoras utilizadas para las pruebas.
- No se puede garantizar la integridad de los datos de entrada. Los datos de entrada son para todo el software: pueden ser archivos de datos, flujos y búferes de memoria, así como argumentos y opciones dados a un ejecutable de línea de comando o entradas de usuario que desencadenan acciones en una aplicación GUI. Los métodos de prueba de fuzzing y monkey se pueden utilizar para encontrar problemas debido a la corrupción o la incoherencia de los datos.
- La simultaneidad es particularmente difícil de probar con los métodos de prueba tradicionales. Puede ser necesario realizar pruebas de estrés para encontrar condiciones de carrera y puntos muertos .
- El software, como los servidores web, a los que se podrá acceder a través de Internet, puede estar sujeto a ataques de denegación de servicio .
- En condiciones normales, ciertos tipos de errores , como pérdidas de memoria , pueden ser bastante benignos y difíciles de detectar durante los cortos períodos de tiempo en los que se realizan las pruebas. Sin embargo, estos errores aún pueden ser potencialmente graves. En cierto sentido, las pruebas de resistencia durante un período de tiempo relativamente corto pueden verse como una simulación del funcionamiento normal durante un período de tiempo más largo.
Relación con la cobertura de la sucursal
La cobertura de sucursales (un tipo específico de cobertura de código ) es una métrica del número de sucursales ejecutadas bajo prueba, donde "100% de cobertura de sucursales" significa que cada sucursal de un programa se ha ejecutado al menos una vez bajo alguna prueba. La cobertura de sucursales es una de las métricas más importantes para las pruebas de software; El software para el que la cobertura de sucursales es baja generalmente no se considera probado a fondo. Tenga en cuenta que lasmétricas de cobertura de código [ editorializando ] son una propiedad de las pruebas para una pieza de software, no del software que se está probando.
Lograr una alta cobertura de sucursales a menudo implica escribir variaciones de prueba negativas , es decir, variaciones en las que se supone que el software falla de alguna manera, además de las variaciones de prueba positivas habituales , que prueban el uso previsto. Un ejemplo de variación negativa sería llamar a una función con parámetros ilegales. Sin embargo, existe un límite en la cobertura de sucursales que se puede lograr incluso con variaciones negativas, ya que algunas sucursales solo se pueden usar para el manejo de errores que están fuera del control de la prueba. Por ejemplo, una prueba normalmente no tendría control sobre la asignación de memoria, por lo que las ramas que manejan un error de "memoria insuficiente" son difíciles de probar.
Las pruebas de estrés pueden lograr una mayor cobertura de sucursales al producir las condiciones bajo las cuales se siguen ciertas sucursales de manejo de errores. La cobertura se puede mejorar aún más mediante la inyección de fallos .
Ejemplos de
- Un servidor web puede someterse a una prueba de estrés utilizando scripts , bots y varias herramientas de denegación de servicio para observar el rendimiento de un sitio web durante los picos de carga.
Prueba de carga frente a prueba de esfuerzo
Las pruebas de estrés generalmente consisten en probar más allá de los límites especificados para determinar los puntos de falla y probar la recuperación de la falla. [1] [2]
Las pruebas de carga implican un entorno controlado que se mueve de cargas bajas a cargas altas. Las pruebas de estrés se enfocan en eventos más aleatorios, caos e imprevisibilidad. Usando una aplicación web como ejemplo, aquí hay formas en que se podría introducir el estrés: [1]
- duplicar el número de referencia para usuarios concurrentes / conexiones HTTP
- apagar y reiniciar aleatoriamente los puertos en los conmutadores / enrutadores de red que conectan los servidores (a través de comandos SNMP, por ejemplo)
- desconecte la base de datos y luego reiníciela
- reconstruir una matriz RAID mientras el sistema está en funcionamiento
- ejecutar procesos que consuman recursos (CPU, memoria, disco, red) en la Web y servidores de bases de datos
- Observe cómo reacciona el sistema ante fallas y se recupera.
- ¿Salva su estado?
- ¿La aplicación se bloquea y se congela o falla correctamente?
- Al reiniciar, ¿puede recuperarse del último buen estado?
- ¿El sistema envía mensajes de error significativos al usuario y a los registros?
- ¿Está comprometida la seguridad del sistema debido a fallas inesperadas?
Ver también
- Pruebas de software
- Este artículo cubre las pruebas de confiabilidad del software bajo cargas de trabajo inesperadas o raras (estresadas). Ver también los estrechamente relacionados:
- Prueba de escalabilidad
- Prueba de carga
- Lista de herramientas de software para pruebas de carga en pruebas de carga # Herramientas de prueba de carga
- Prueba de estrés para una discusión general
- Prueba de caja negra
- Prueba de rendimiento del software
- Análisis de escenario
- Simulación
- Prueba de caja blanca
- Technischer Überwachungsverein (TÜV) - prueba y certificación de productos
- Prueba de simultaneidad usando el verificador de modelos CHESS
- Jinx (desaparecido debido a la adquisición y cancelación del proyecto) automatizó las pruebas de estrés mediante la exploración automática de escenarios de ejecución poco probables.
- Prueba de esfuerzo (hardware)
Referencias
- ^ a b Gheorghiu, Grig. "Rendimiento frente a carga frente a pruebas de estrés" . Pruebas ágiles . Consultado el 25 de febrero de 2013 .
- ^ Chan, H Anthony (2004). "Pruebas de estrés aceleradas para hardware y software" (PDF) . Simposio anual sobre confiabilidad y mantenibilidad, 2004 - RAMS . Los Ángeles, CA: IEEE. págs. 346–351. doi : 10.1109 / RAMS.2004.1324530 . ISBN 0-7803-8215-3. Consultado el 19 de octubre de 2020 .