El documento describe diferentes tipos de pruebas de software, incluyendo pruebas de unidad, integración, validación y sistema. Explica que las pruebas de unidad buscan errores en módulos individuales utilizando stubs y drivers, mientras que las pruebas de integración examinan la comunicación entre módulos. También discute estrategias como descendente, ascendente y sandwitch para las pruebas de integración, y cómo las pruebas de validación y sistema evalúan el software en entornos de desarrollo y cliente.
2. Prueba de software
Ejecución de un programa con la
intención de descubrir un error
técnica experimental para la búsqueda
de errores en los programas
4. Pruebas de unidad
Errores
interfaces entre módulos
interfaces entrada/salida
estructuras de datos locales
cálculos
flujo de control
caminos de procesamiento de errores
5. Pruebas de unidad
Necesitamos
drivers (conductores) driver
stubs (resguardos)
Unidad
bajo prueba
stub_C stub_A stub_Y
6. Pruebas de integración
Errores
comunicación a través de la interface
efectos colaterales perniciosos
acumulación notable de errores de cálculo
acceso incoherente a estructuras de datos
globales
tiempos de respuesta
8. Estrategia descendente
De arriba hacia abajo, avanzando
primero en profundidad
primero en anchura
tomamos el módulo principal como
driver
substituimos los módulos dependientes
por stubs
9. Estrategia descendente
(cont)
progresamos substituyendo stubs por
módulos reales
– realizando pruebas específicas para el
módulo
– repitiendo las realizadas previamente
(pruebas regresivas)
10. Estrategia ascendente
Agrupamos los módulos inferiores
(según funcionalidad p.e.)
preparamos un driver para cada grupo
y realizamos las pruebas
progresamos substituyendo los driver
por módulos reales
realizando pruebas específicas y
regresivas
11. A favor En contra
• Se prueban • Elaboración
descendente antes los stubs
módulos más
importantes
• si primero en
profundidad
quedan
probadas
antes ramas
completas
ascendente • Gran
incertidumbre
hasta el final
12. Estrategia sandwitch
Combinamos
estrategia descendente para los módulos
superiores (+ funcionales)
estrategia ascendente para los módulos
inferiores
intensificamos las pruebas regresivas
en los módulos críticos
13. Pruebas de validación
basarse en los criterios de aceptación
pruebas alfa (entorno de desarrollo)
pruebas beta (entorno del cliente)
Pruebas de sistema
recuperación
seguridad
resitencia
rendimiento
14. Técnicas de prueba
Ayudan a definir conjuntos de casos de
prueba aplicando un cierto criterio
los casos de prueba quedarán
determinados por los valores a asignar
a las entradas en su ejecución
16. Técnicas de prueba
técnicas de caja blanca
criterios basados en el contenido de los
módulos
técnicas de caja negra
criterios basados en las interfaces y las
especificaciones de los módulos
17. Técnicas de caja blanca
El criterio de selección de casos de
prueba buscará cierta cobertura
caminos independientes
valores de las condiciones
bucles dentro y fuera de sus límites
operacionales
estructuras de datos
los errores se esconden en los rincones y
se acumulan en las fronteras
18. Técnicas de caja negra
Permiten detectar
funcionamiento incorrecto o incompleto
errores interface
errores accesos estructuras de datos
externas
problemas de rendimiento
errores de inicio y terminación
19. Técnicas de caja negra
Cobertura
valores representativos de conjuntos
de datos
fronteras, valores o combinaciones de
valores conflictivos
capacidad de proceso