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:
Las pruebas de estrés pueden contrastarse con las pruebas de carga:
Los fallos pueden estar relacionados con:
Las razones para realizar pruebas de estrés incluyen:
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 debe 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 .
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]
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 ataques cibernéticos, 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.