VI PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

VI
PRUEBAS, CALIDAD
Y
MANTENIMIENTO
DEL SOFTWARE
6.1 PRUEBAS DEL SOFTWARE
Una vez generado el código el software debe ser
probado para descubrir el máximo de errores
posibles antes de su entrega al cliente.
Es probado para descubrir errores cometidos sin
darse cuenta al realizar su diseño y construcción
La prueba requiere una mayor cantidad del
esfuerzo dedicado al proyecto que cualquier otra
actividad de ingeniería del software
6.1 PRUEBAS DEL SOFTWARE
OBJETIVOS
El ingeniero crea una serie de casos de prueba que
intentan "demoler" el software que ha sido construido.
Tiene como objetivos:
(1) La prueba es un proceso de ejecución de un
programa con la intención de descubrir un error.
(2) Un buen caso de prueba es aquel que tiene una alta
probabilidad de mostrar un error no descubierto hasta
entonces.
(3) Una prueba tiene éxito si descubre un error no
detectado hasta entonces.
6.1 PRUEBAS DEL SOFTWARE
OBJETIVOS
Por lo tanto hay que diseñar pruebas que saque a la luz
diferentes clases de errores, haciéndolo con la menor
cantidad de tiempo y esfuerzo.
Inclusive tiene como ventaja ver hasta qué punto las
funciones parecen funcionar de acuerdo con las
especificaciones y cumplir así los requisitos de
rendimiento
6.1 PRUEBAS DEL SOFTWARE
PRINCIPIOS
Æ Para realizar pruebas efectivas un equipo de software
debe efectuar revisiones técnicas formales y efectivas.
Esto elimina muchos errores antes de empezar las
pruebas.
ÆLa prueba comienza al nivel de componentes y trabaja
“hacia fuera”, hacia la integración de todo el sistema de
cómputo.
ÆLas pruebas deberían empezar por lo "pequeño" y
progresar hacia "lo grande" ( módulos )
6.1 PRUEBAS DEL SOFTWARE
PRINCIPIOS
Æ Diferentes técnicas de prueba son apropiadas en
diferentes momentos.
ÆLa prueba la dirige el desarrollador del software y en
proyectos grandes un grupo independiente de pruebas.
ÆLas pruebas deberían planificarse mucho antes de que
empiecen
Æ La prueba y la depuración son actividades diferentes,
pero ambas se incluyen en la estrategia de pruebas.
6.1 PRUEBAS DEL SOFTWARE
PRINCIPIOS
ÆA todas las pruebas se les debería poder hacer un
seguimiento hasta los requisitos del cliente
ÆNo son posibles las pruebas exhaustivas ( imposible
ejecutar todas las combinaciones de caminos )
ÆPasa ser mas eficaces, las pruebas deberían ser
realizadas por un equipo independiente
6.1 PRUEBAS DEL SOFTWARE
PRINCIPIOS
Psicologicamente
constructivas.
el analisis y diseno son tareas
El ingeniero se siente orgulloso de lo que acaba de
construir.
Un error es disenar y ejecutar pruebas que solamente
demuestren el buen funcionamiento del programa en
lugar de descubrir errores.
6.2 FACILIDAD DE PRUEBA
La facilidad de prueba es la facilidad con que se puede
probar un programa de computadora.
6.2 FACILIDAD DE PRUEBA
CARACTERISTICAS
Operatividad:
“cuanto mejor funcione, con mayor
eficiencia podra probarse”, si el sistema tiene pocos
errores al disenarse con calidad, ningún error
bloqueara la ejecución de pruebas
Observabilidad: “lo que se ve es lo que se prueba”, se
genera una salida distinta para cada entrada, los
estados y variables están visibles y se pueden
consultar durante la ejecucion, un resultado
incorrecto se identifica fácilmente, se informa de los
errores internos, el código fuente es accesible
6.2 FACILIDAD DE PRUEBA
CARACTERISTICAS
Controlabilidad: “cuanto mejor se controle el software,
mejor se automatizaran y mejoraran las pruebas”, se
controlan directamente los estados y variables de
software y hardware. Todos los resultados posibles se
generan con alguna combinación de entrada, los
formatos de entrada y resultados son consistentes y
estructurados; las pruebas se pueden especificar,
automatizar y reproducir.
6.2 FACILIDAD DE PRUEBA
CARACTERISTICAS
Capacidad de descomposición : controlando el ámbito
de las pruebas podemos aislar los problemas y llevar
a cabo mejores pruebas, al usar modularidad, se
pueden probar independientemente.
Simplicidad : “cuanto menos haya que probar, mas
rápido se hara”, ( tipos: funcional, estructural y de
código ) ej: mínimo de características para cumplir
con los requisitos, arquitectura modular, estandar
para facil inspeccion y mantenimiento.
6.2 FACILIDAD DE PRUEBA
CARACTERISTICAS
Estabilidad: “cuanto menos cambios haya, menores
alteraciones habra en la prueba”, los cambios son
infrecuentes, controlados y no invalidan las pruebas
existentes, el software se recupera bien de las fallas.
Facilidad de comprensión : “cuanta mas información
tengamos, mas inteligentes serán las pruebas”, se
entiende el diseño, las dependencias y la
documentación, si son especificas, detalladas y
exactos.
6.2 FACILIDAD DE PRUEBA
BUENA PRUEBA
Æ si tiene una elevada probabilidad de encontrar un error
Æ si no es redundante ( sin repetir )
Æ debe ser la mejor de su clase ( altas probabilidades
encontrar errores )
Æ no debe ser ni muy simple ni demasiado compleja
6.3 CASOS DE PRUEBA
CAJA BLANCA Y CAJA NEGRA
Hay dos maneras de probar cualquier producto:
1) Si se conoce la funcion especifica para la que se
diseno el producto se aplican pruebas que
demuestren que cada funcion es plenamente
operacional, mientras se buscan los errores de cada
funcion.
2) Si se conoce el funcionamiento interno el producto, se
aplican pruebas para asegurar que todas las piezas
encajen, es decir, que las operaciones internas se
realicen de acuerdo con las especificaciones.
6.3 CASOS DE PRUEBA
CAJA BLANCA Y CAJA NEGRA
El software debe probarse desde dos perspectivas
diferentes:
Æ la lógica interna del programa utilizando técnicas de
diseño de casos de prueba de "caja blanca"
Æ los requisitos del software utilizando técnicas de
diseño de casos de prueba de "caja negra"
6.3 CASOS DE PRUEBA
CAJA BLANCA Y CAJA NEGRA
Æ Las pruebas de caja blanca se basan en un examen
cercano
al
detalle
procedural,
examinando
condiciones y ciclos.
Æ La pruebas de caja negra se aplican a la interfaz del
software, examinando el aspecto funcional del
sistema.
6.3 CASOS DE PRUEBA
CAJA BLANCA
Este método obtiene casos de prueba que:
* garanticen que se ejercitan por lo menos una vez todos
los caminos independientes de cada módulo.
* ejerciten todas las decisiones lógicas en sus vertientes
verdadera y falsa.
* ejecuten todos los bucles en sus límites y con sus
límites operacionales.
* y ejerciten las estructuras internas de datos para
asegurar su validez.
6.3 CASOS DE PRUEBA
CAJA BLANCA
Tipos de Prueba:
•
•
Prueba de la Ruta Basica
Pruebas de la estructura de control
• Prueba de condicion
• Prueba del flujo de datos
• Prueba de bucles
6.3 CASOS DE PRUEBA
CAJA NEGRA
Es un complemento que intenta descubrir diferentes
errores que la otra prueba realiza, tales como:
•
•
•
•
•
funciones incorrectas ó ausentes
errores de interfaz
errores en estructuras de datos ó en accesos a bases
de datos externas
errores de rendimiento
errores de inicialización y de terminación.
6.3 CASOS DE PRUEBA
CAJA NEGRA
Tipos de Prueba:
•
•
•
•
•
•
•
•
Metodos graficos de prueba
Particion Equivalente
Analisis de valores limite
Prueba de tabla ortogonal
Pruebas de interfaces graficas
Prueba de arquitectura cliente/servidor
• Pruebas de servidor
• Pruebas de base de datos
• Preubas de transaccion
• Pruebas de comunicación de red
Pruebas de documentacion
Pruebas de sistemas de tiempo real
6.4 ESTRATEGIAS DE PRUEBA
Prueba del sistema
Prueba de validacion
Prueba de integracion
Prueba de Unidad
Codigo
Diseno
Requisitos
Ingenieria del Sitema
6.4 ESTRATEGIAS DE PRUEBA
1. Nasa’s The Voyager bug (sent the probe into the sun).
2. The AT&T bug that took out 1/3 of US telephones.
3. The DCS bug that took out the other 1/3 a few months
later.
4. The Intel Pentium chip bug (it was software, not
hardware).
5. The Ariane V bug.
Cómo fué ? Por qué ?
Cuánto costó ?
Qué se hizo ?