Pruebas de estrés (software)

Las pruebas de estrés son una actividad de prueba de software que determina la solidez del software al realizar pruebas más allá de los límites de 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 mayor énfasis en la solidez, la disponibilidad y el manejo de errores bajo una carga pesada, que en lo que se consideraría un comportamiento correcto en circunstancias normales.

Una prueba de estrés del sistema se refiere a pruebas que ponen mayor énfasis en la robustez , la disponibilidad y el manejo de errores bajo una carga pesada, en lugar de en lo que se consideraría un comportamiento correcto en circunstancias normales. En particular, los objetivos de dichas pruebas pueden ser garantizar que el software no se bloquee en condiciones de recursos computacionales insuficientes (como memoria o espacio en disco ), concurrencia inusualmente alta o ataques de denegación de servicio .

Ejemplos:

• Se puede someter a pruebas de estrés a un servidor web mediante scripts , bots y diversas herramientas de denegación de servicio para observar el rendimiento de un sitio web durante picos de carga. Estos ataques suelen durar menos de una hora o hasta que se encuentra un límite en la cantidad de datos que el servidor web puede tolerar.

Las pruebas de estrés pueden contrastarse con las pruebas de carga:

• Las pruebas de carga examinan todo el entorno y la base de datos, al tiempo que miden el tiempo de respuesta, mientras que las pruebas de estrés se centran en las transacciones identificadas, llevándolas a un nivel tal que interrumpan las transacciones o los sistemas.
• Durante las pruebas de estrés, si las transacciones se someten a un estrés selectivo, es posible que la base de datos no experimente mucha carga, pero las transacciones sí se sometan a un estrés intenso. Por otro lado, durante las pruebas de carga, la base de datos experimenta una carga intensa, mientras que algunas transacciones pueden no verse sometidas a un estrés intenso.
• La prueba de estrés del sistema, también conocida como prueba de estrés, implica cargar a los usuarios simultáneos más allá del nivel que el sistema puede soportar, de modo que se rompa en el eslabón más débil de todo el sistema.

Los fallos pueden estar relacionados con:

• Características de entornos que no son de producción, por ejemplo, pequeñas bases de datos de prueba.
• Falta total de pruebas de carga o estrés

Las razones para realizar pruebas de estrés incluyen:

• El software que se está probando es de "misión crítica", es decir, una falla del software (como una caída ) tendría consecuencias desastrosas.
• La cantidad de tiempo y recursos dedicados a las pruebas normalmente no es suficiente, con los métodos de prueba tradicionales, para probar todas las situaciones en las que se utilizará el software cuando se lance.
• Incluso si se dispone de tiempo y recursos suficientes para escribir las pruebas, puede que no sea posible determinar de antemano todas las distintas formas en que se utilizará el software. Esto es especialmente cierto en el caso de los sistemas operativos y el middleware , que acabarán siendo utilizados por un software que ni siquiera existe en el momento de la prueba.
• Los clientes pueden utilizar el software en computadoras que tengan 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 se refieren a todo el software: pueden ser archivos de datos, flujos y búferes de memoria, así como argumentos y opciones que se dan a un ejecutable de línea de comandos o entradas de usuario que desencadenan acciones en una aplicación GUI. Se pueden utilizar métodos de fuzzing y de prueba de mono para detectar problemas debido a la corrupción o incoherencia de los datos.
• La concurrencia es particularmente difícil de probar con los métodos de prueba tradicionales. Es posible que sea necesario realizar pruebas de estrés para detectar condiciones de competencia y bloqueos .
• 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 las fugas de memoria , pueden ser bastante benignos y difíciles de detectar en los breves períodos de tiempo en los que se realizan las pruebas. Sin embargo, estos errores pueden ser potencialmente graves. En cierto sentido, las pruebas de estrés durante un período de tiempo relativamente corto pueden considerarse como una simulación del funcionamiento normal durante un período de tiempo más largo.

La cobertura de rama (un tipo específico de cobertura de código ) es una métrica de la cantidad de ramas ejecutadas bajo prueba, donde "cobertura de rama del 100 %" significa que cada rama de un programa se ha ejecutado al menos una vez bajo alguna prueba. La cobertura de rama es una de las métricas más importantes para las pruebas de software; el software para el cual la cobertura de rama es baja generalmente no se considera que esté completamente probado. Tenga en cuenta que ^{[ editorializing ]} las métricas de cobertura de código son una propiedad de las pruebas para una pieza de software, no del software que se está probando.

Para lograr una cobertura de rama alta, a menudo es necesario escribir variaciones de prueba negativas , es decir, variaciones en las que se supone que el software fallará de alguna manera, además de las variaciones de prueba positivas habituales , que prueban el uso previsto. Un ejemplo de una variación negativa sería llamar a una función con parámetros ilegales. Sin embargo, existe un límite para la cobertura de rama que se puede lograr incluso con variaciones negativas, ya que algunas ramas solo se pueden usar para manejar 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 las ramas al generar las condiciones bajo las cuales se siguen ciertas ramas de manejo de errores. La cobertura se puede mejorar aún más mediante el uso de inyección de fallas .

• Se puede realizar pruebas de estrés a un servidor web mediante scripts , bots y varias herramientas de denegación de servicio para observar el rendimiento de un sitio web durante cargas máximas.

Las pruebas de estrés generalmente consisten en realizar pruebas más allá de límites específicos para determinar puntos de falla y probar la recuperación de fallas. ^{[1] [2]}

Las pruebas de carga implican un entorno controlado que pasa de cargas bajas a cargas altas. Las pruebas de estrés se centran en eventos más aleatorios, caos e imprevisibilidad. Si tomamos como ejemplo una aplicación web, a continuación se indican algunas formas en las que se puede introducir estrés: ^[1]

• duplicar el número de referencia para usuarios simultáneos/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 ejecución
• ejecutar procesos que consumen recursos (CPU, memoria, disco, red) en los servidores web y de bases de datos
• Observar cómo reacciona el sistema ante un fallo y se recupera.
  • ¿Guarda su estado?
  • ¿La aplicación se bloquea y se congela o falla sin problemas?
  • Al reiniciar, ¿es capaz de recuperarse del último estado bueno?
  • ¿El sistema muestra mensajes de error significativos al usuario y a los registros?
  • ¿Está comprometida la seguridad del sistema debido a fallos inesperados?

Un marco de prueba de software basado en patrones para la evaluación de la explotabilidad de las vulnerabilidades de corrupción de metadatos desarrollado por Deng Fenglei, Wang Jian, Zhang Bin, Feng Chao, Jiang Zhiyuan y Su Yunfei analiza cómo se presta cada vez más atención a la garantía y protección de la calidad del software. Sin embargo, el software actual, lamentablemente, aún no está protegido contra los ciberataques, especialmente en presencia de una organización insegura de los metadatos del montón. Los autores pretenden explorar si los metadatos del montón podrían ser corrompidos y explotados por ciberatacantes, y proponen RELAY, un marco de prueba de software para simular el comportamiento de explotación humana para la corrupción de metadatos a nivel de máquina. RELAY también hace uso de los menores recursos consumidos para resolver un problema de diseño de acuerdo con el patrón de explotación y genera la explotación final.

Una metodología para definir la granularidad de los objetos de aprendizaje desarrollada por BENITTI, Fabiane Barreto Vavassori. Los autores primero discuten cómo los objetos de aprendizaje son uno de los principales temas de investigación en la comunidad de aprendizaje electrónico en los últimos años y la granularidad es un factor clave para la reutilización de los objetos de aprendizaje. Luego, los autores presentan una metodología para definir la granularidad de los objetos de aprendizaje en el área de la informática, así como un estudio de caso en pruebas de software. Más tarde, los autores realizan cinco experimentos para evaluar el potencial de aprendizaje de los objetos de aprendizaje producidos, así como para demostrar la posibilidad de reutilización de los objetos de aprendizaje. Los resultados del experimento también se presentan en el artículo, que muestran que los objetos de aprendizaje promueven la comprensión y la aplicación de los conceptos.

Un artículo reciente, Verificación de la confiabilidad del software basado en el servicio en la nube, tuvo un efecto innovador y explora cómo la industria del software necesita una forma de medir la confiabilidad de cada componente del software. En este artículo, se propuso un método de verificación de garantía basado en el servicio en la nube . El artículo primero analiza qué tan confiable es cada componente y se definirá en términos de verificación de garantía del servicio del componente. Luego, en el artículo se definió un modelo de componente efectivo y, en función del modelo propuesto, se ilustra el proceso de verificación de un servicio de componente en una muestra de aplicación.

• Pruebas de software
• Este artículo trata sobre la prueba de la confiabilidad del software en cargas de trabajo inesperadas o poco frecuentes (estresadas). Consulte también los artículos estrechamente relacionados:
  • Pruebas de escalabilidad
  • Prueba de carga
  • Lista de herramientas de software para pruebas de carga en Pruebas de carga#Herramientas de pruebas de carga
• Prueba de estrés para una discusión general
• Prueba de caja negra
• Pruebas de rendimiento de software
• Análisis de escenarios
• Simulación
• Prueba de caja blanca
• Technischer Überwachungsverein (TÜV): pruebas y certificación de productos
• Pruebas de concurrencia con el verificador de modelos CHESS
• Jinx (que desapareció debido a una adquisición y cancelación del proyecto) automatizó las pruebas de estrés explorando automáticamente escenarios de ejecución poco probables.
• Prueba de estrés (hardware)