Ud3 Contornos - Adriano
Ud3 Contornos - Adriano
Ud3 Contornos - Adriano
2. TIPOS DE PRUEBA
Pruebas de Caja Negra: programa probado usando su interfaz externa, siendo
fundamental la comprobación de que los resultados de la ejecución son los
esperados.
Pruebas de Caja Blanca: se prueba la aplicación desde dentro, usando la lógica de
la misma.
Tipos de pruebas de software:
- Pruebas de unidad: se prueba el correcto funcionamiento de un módulo de
código.
- Pruebas de carga: evalúa el rendimiento de una aplicación bajo la carga
esperada de usuarios concurrentes y transacciones, revelando los tiempos de
respuesta y posibles cuellos de botella.
- Prueba de estrés: se utiliza para evaluar la resistencia de una aplicación
aumentando gradualmente el número de usuarios hasta que se rompe,
revelando su capacidad bajo cargas extremas y ayudando a prever su
rendimiento en situaciones de carga real.
- Prueba de estabilidad: determina si la aplicación puede aguantar una carga
esperada de manera continua.
- Prueba de picos: observa el comportamiento del sistema variando
drásticamente el número de usuarios conectados.
- Prueba estructural: se centra en la estructura interna del programa.
- Prueba funcional: se centra en las funciones, entradas y salidas que recibe
y produce un módulo de código
- Pruebas aleatorias: utiliza modelos que representen las posibles entradas al
programa y a partir de ellos crea los casos de prueba.
- Pruebas de regresión: detectan errores causados por cambios recientes en
el software que no existían previamente.
5. VALIDACIONES
Hay que tener en cuenta, que estamos desarrollando una aplicación para terceros, y
que son estos los que deciden si la aplicación se ajusta a los requerimientos
establecidos en el análisis.
La validación del software se logra a través de pruebas de caja negra que
comprueban la conformidad con los requisitos establecidos. Un plan de prueba
define los tipos de pruebas necesarias, mientras que un procedimiento de prueba
detalla casos específicos para descubrir errores y asegurar el cumplimiento de
requisitos funcionales, de rendimiento y otros como portabilidad y mantenimiento.
Durante la validación del software, los casos de prueba pueden resultar en
características aceptables según las especificaciones o en la detección de
desviaciones, generando una lista de deficiencias que rara vez pueden corregirse
antes de la finalización planificada del proyecto.
6. PRUEBAS DE CÓDIGO
Una prueba de código implica ejecutar un programa bajo condiciones especificadas
para detectar errores, con resultados registrados y evaluados.
Se diseñan casos de prueba utilizando tres enfoques principales:
- Estructural (caja blanca), que analiza la estructura interna y los caminos de
ejecución.
- Funcional (caja negra), que se centra en las funciones y las entradas y
salidas.
- Aleatorio, que utiliza modelos para generar casos de prueba que simulan las
entradas habituales del programa.
6.1 CUBRIMIENTO
Con este tipo de prueba, lo que se pretende, es comprobar que todas las funciones,
sentencias, decisiones, y condiciones, se van a ejecutar.
8. PRUEBAS UNITARIAS
Las pruebas unitarias tienen como objetivo verificar el correcto funcionamiento de
módulos de código individualmente, asegurando que cada método se prueba de
manera independiente.
En el diseño de los casos de pruebas unitarias, habrá que tener en cuenta los
siguientes requisitos:
- Automatizable: sin intervención manual.
- Completas: deben cubrir la mayor cantidad de código.
- Repetibles: no se deben crear pruebas que sólo pueden ser ejecutadas una
sola vez.
- Independientes: la ejecución de una prueba no debe afectar a la ejecución
de otra.
- Profesionales: las pruebas deben ser consideradas igual que el código, con
la misma profesionalidad, documentación, etc.
Las pruebas individuales nos proporcionan cinco ventajas básicas:
- Fomentan el cambio.
- Simplifica la integración.
- Documenta el código.
- Separación de la interfaz y la implementación.
- Los errores están más acotados y son más fáciles de localizar.