Introducción a las Pruebas de Programas

Created by

@JovialBeauty

Study Notes

Los sistemas de software cada vez son más grandes y complejos.
El desarrollo de software requiere menos tiempo y mayor calidad.
Las pruebas garantizan la calidad del software y la satisfacción de los requisitos.
Se ahorra tiempo y recursos durante el desarrollo.
La detección temprana de errores es crucial.

Una buena prueba debe tener una alta probabilidad de encontrar fallas.
Una buena prueba debe centrarse en probar si el software hace lo que debe y lo que no debe hacer.
Una buena prueba no debe ser redundante.
Una buena prueba debería tener la mayor probabilidad posible de encontrar fallas.
No se deben combinar varias pruebas para no enmascarar errores.

Pruebas unitarias: se realizan a nivel de método para comprobar si funcionan correctamente de forma aislada.
Ventajas: se ejecutan rápidamente, forzan a crear clases menos acopladas.
Framework de pruebas: como JUnit en Java.

Se prueban las interacciones entre dos o más unidades del software.
Se verifica el correcto funcionamiento de los componentes de la aplicación en conjunto.
Son dependientes del entorno.

Se prueba el sistema completo una vez que se han realizado las pruebas de integración.
Se comprueba si el software cumple con la función para la que fue pensado.
Se verifica si el diseño del software es correcto
Se pueden automatizar con herramientas como Selenium.
Pruebas de carga: Se evalúa la respuesta del sistema ante un número determinado de peticiones.
Pruebas de estrés: Se somete al sistema a situaciones extremas para ver cómo se comporta y si se recupera.

Son las pruebas finales para verificar si el software cumple con las expectativas del usuario.

Caja negra: las pruebas se basan en la interfaz del método (entradas y salidas) sin conocer el código interno.
Caja blanca: las pruebas se diseñan considerando la estructura del método y su lógica interna.

Se identifican clases de equivalencia para las entradas de un programa, donde se espera que el comportamiento sea similar.
Se deben crear clases válidas y no válidas.
Se seleccionan entradas representativas.

Se centran en los valores extremos de las entradas, ya que se supone que los errores suelen aparecer en esos puntos.
Se incluyen valores justo por encima o por debajo de los límites válidos. Ejemplo: validación de datos en un rango

El objetivo es verificar si los métodos get y set funcionan correctamente.
Se valida que las modificaciones en los atributos se reflejen correctamente en el objeto.
Se comparan los valores antes y después de la modificación.

No Modal: Puede recibir cualquier mensaje en cualquier momento.
Modal: Tiene restricciones en la recepción de mensajes.
- Uni-Modal: las restricciones dependen del orden de mensajes
- Quasi-Modal: las restricciones dependen del estado del objeto
- Modal: las restricciones dependen del orden y estado del objeto.

Son condiciones que deben cumplirse para que la clase funcione correctamente.
Proveen un guía para diseñar casos de prueba que validen el estado actual del sistema.