Pruebas de Software

Las pruebas de software son la ejecución dinámica de un programa con entradas seleccionadas para detectar defectos y obtener la confianza de que el software se comporta según lo previsto.

Definition

Las pruebas de software son la actividad de diseñar y ejecutar casos de prueba —entradas emparejadas con resultados esperados— para revelar discrepancias entre el comportamiento real y el requerido, y para estimar la fiabilidad del software.

Scope

Este tema abarca los niveles de prueba (unidad, integración, sistema, aceptación); técnicas de caja negra como la partición de equivalencia, el análisis de valores límite y las pruebas combinatorias; técnicas de caja blanca impulsadas por criterios de cobertura de código; pruebas de regresión, rendimiento y exploratorias; automatización de pruebas; y la teoría de la adecuación y cobertura de las pruebas.

Core questions

• ¿Cómo se seleccionan casos de prueba efectivos de un espacio de entrada intratablemente grande?
• ¿Qué criterios de cobertura miden la adecuación de un conjunto de pruebas?
• ¿Cómo se complementan entre sí los niveles de prueba, desde la unidad hasta la aceptación?
• ¿Cómo se pueden automatizar e integrar las pruebas en el proceso de entrega?

Key theories

Diseño de pruebas de caja negra y caja blanca

Las técnicas de caja negra derivan pruebas de la especificación mediante partición y análisis de límites, mientras que las técnicas de caja blanca derivan pruebas de la estructura del código guiadas por criterios de cobertura; ambas son complementarias.

Criterios de cobertura y adecuación de pruebas

Los criterios de adecuación, como la cobertura de sentencias, ramas y condiciones, y los criterios basados en modelos sobre grafos de flujo de control y de datos, proporcionan objetivos medibles sobre la exhaustividad con la que un conjunto de pruebas ejercita un programa.

Clinical relevance

Las pruebas son el medio más ampliamente practicado para asegurar que el software se comporta correctamente antes de su lanzamiento; las pruebas automatizadas bien diseñadas detectan las regresiones tempranamente, apoyan la refactorización y la entrega continua, y son fundamentales para un software fiable.

Evidence & guidelines

ISO/IEC/IEEE 29119 proporciona estándares internacionales para los procesos, la documentación y las técnicas de prueba de software, y el área de conocimiento de Pruebas de Software de SWEBOK ofrece una visión general consensuada.

History

Las pruebas maduraron desde la depuración ad hoc hasta convertirse en una disciplina con el tratamiento sistemático de Myers en 1979; la teoría de la cobertura, las pruebas basadas en modelos y la automatización de pruebas se desarrollaron durante las décadas siguientes, y el desarrollo impulsado por pruebas y la integración continua hicieron de las pruebas automatizadas una práctica ágil central.

Debates

Cuánto vale la pena la automatización de pruebas

Se debate el equilibrio adecuado entre las pruebas unitarias, de integración y de extremo a extremo automatizadas; la pirámide de pruebas favorece muchas pruebas unitarias rápidas sobre las lentas de extremo a extremo, pero los críticos señalan que este equilibrio depende del tipo de sistema y del riesgo.

Key figures

• Glenford Myers
• Paul Ammann
• Jeff Offutt
• Boris Beizer

Seminal works

• myers2011
• ammann2016
• swebok2014

Frequently asked questions

¿Por qué no podemos probar todas las entradas posibles?

El espacio de entradas y rutas de ejecución posibles es astronómicamente grande o infinito para la mayoría de los programas, por lo que las pruebas exhaustivas son inviables; en su lugar, las pruebas seleccionan casos representativos y límite utilizando técnicas sistemáticas para maximizar la detección de defectos por prueba.

¿Cuál es la diferencia entre los niveles de prueba?

Las pruebas unitarias ejercitan componentes individuales de forma aislada, las pruebas de integración verifican sus interacciones, las pruebas de sistema evalúan el sistema completo frente a sus requisitos, y las pruebas de aceptación confirman que satisface las necesidades del usuario; cada nivel se dirige a diferentes tipos de defectos.