Pruebas de Software

Analisis de Sistemas II
Modulo III
Pruebas de Software
Prueas Unitarias
Pruebas Caja Blanca
Pruebas de Caja Negra
Estrategias de Prueba de Software
Proporciona una guía que
describe los pasos que deben
realizarse como parte de la
prueba, cuándo se planean y se
llevan a cabo dichos pasos, y
cuánto esfuerzo, tiempo y
recursos se requerirán.
Características
• Para realizar una prueba efectiva, debe realizar revisiones
técnicas efectivas.
• La prueba comienza en los componentes y opera “hacia
afuera”, hacia la integración de todo el sistema de cómputo.
• Diferentes técnicas de prueba son adecuadas para distintos
enfoques de ingeniería de software y en diferentes
momentos en el tiempo.
• Las pruebas las realiza el desarrollador del software y (para
proyectos grandes) un grupo de prueba independiente.
• Prueba y depuración son actividades diferentes, pero la
depuración debe incluirse en cualquier estrategia de
prueba.
Verificación y Validación
Se refiere al Es un conjunto
conjunto de tareas diferente de tareas
que garantizan que aseguran que el
que el software software que se
construye sigue los
implementa
requerimientos del
correctamente
cliente.
una función
específica.
VyV actividades SQA
• revisiones técnicas, • análisis de algoritmos,
• auditorías de calidad y • pruebas de desarrollo,
configuración, • pruebas de usabilidad,
• monitoreo de • pruebas de calificación,
rendimiento, • pruebas de aceptación y
• simulación, • pruebas de instalación.
• estudio de factibilidad,
• revisión de
documentación,
• revisión de base de datos,
Pruebas de unidad

Prueba de Integración

Pruebas de orden superior

Prueba de validación

Prueba de sistema
Cuándo terminan las pruebas?
“nunca se termina de
probar; la carga
simplemente pasa de
usted (el ingeniero de
software) al usuario final”
Aspectos estratégicos
• Especifican los requerimientos del producto en
forma cuantificable mucho antes de comenzar
con las pruebas.
• Establecen de manera explícita los objetivos de
las pruebas.
• Entienden a los usuarios del software y
desarrollan un perfil para cada categoría de
usuario.
• Desarrollan un plan de prueba que enfatice
“pruebas de ciclo rápido”.
Aspectos estratégicos
• Construyen software “robusto” que esté
diseñado para probarse a sí mismo.
• Usan revisiones técnicas efectivas como
filtro previo a las pruebas.
• Realizan revisiones técnicas para valorar
la estrategia de prueba y los casos de
prueba.
• Desarrollan un enfoque de mejora
continuo para el proceso de prueba.
Prueba de Unidad
•Enfoca los esfuerzos de
verificación en la unidad
más pequeña del diseño de
software: el componente o
módulo de software.
 Las pruebas de
unidad por lo
general se
consideran como
adjuntas al paso de
codificación.
Pruebas de Integración
Son una técnica sistemática
para construir la arquitectura
del software mientras se
llevan a cabo pruebas para
descubrir errores asociados
con la interfaz.
Validación exitosa
Cuando el software
funciona en una forma
que cumpla con las
expectativas
razonables del cliente
Las pruebas de software representan
el porcentaje más grande de esfuerzo
técnico en el proceso de software.
Sin importar el tipo de software que
se construya, una estrategia para
planificar, ejecutar y controlar
pruebas sistemáticas comienza por
considerar pequeños elementos del
software y moverse hacia afuera,
hacia el programa como un todo.
Pruebas de Caja Blanca
Llamada prueba de caja de
vidrio, es una filosofía de
diseño de casos de prueba que
usa la estructura de control
descrita como parte del diseño a
nivel de componentes para
derivar casos de prueba.
Deriva casos de prueba que:
• 1) garanticen que todas las rutas independientes
dentro de un módulo se revisaron al menos una
vez,
• 2) revisen todas las decisiones lógicas en sus
lados verdadero y falso,
• 3) ejecuten todos los bucles en sus fronteras y
dentro de sus fronteras operativas y
• 4) revisen estructuras de datos internas para
garantizar su validez.
Pruebas de Caja Negra
Llamadas pruebas de
comportamiento, se enfocan en los
requerimientos funcionales del
software; es decir, permiten derivar
conjuntos de condiciones de entrada
que revisarán por completo todos los
requerimientos funcionales para un
programa.