VI

PRUEBAS, CALIDAD
Y
MANTENIMIENTO
DEL SOFTWARE

6.1 PRUEBAS DEL SOFTWARE

Una vez generado el cdigo el software debe ser
probado para descubrir el mximo de errores
posibles antes de su entrega al cliente.
Es probado para descubrir errores cometidos sin
darse cuenta al realizar su diseo y construccin
La prueba requiere una mayor cantidad del
esfuerzo dedicado al proyecto que cualquier otra
actividad de ingeniera 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 ejecucin de un
programa con la intencin 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 disear pruebas que saque a la luz
diferentes clases de errores, hacindolo 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 tcnicas 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 integracin de todo el sistema de
cmputo.
Las pruebas deberan empezar por lo "pequeo" y
progresar hacia "lo grande" ( mdulos )

6.1 PRUEBAS DEL SOFTWARE

PRINCIPIOS
Diferentes tcnicas 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 deberan planificarse mucho antes de que
empiecen
La prueba y la depuracin son actividades diferentes,
pero ambas se incluyen en la estrategia de pruebas.

6.1 PRUEBAS DEL SOFTWARE

PRINCIPIOS
A todas las pruebas se les debera 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 deberan 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, ningn error
bloqueara la ejecucin de pruebas
Observabilidad: lo que se ve es lo que se prueba, se
genera una salida distinta para cada entrada, los
estados y variables estn visibles y se pueden
consultar durante la ejecucion, un resultado
incorrecto se identifica fcilmente, se informa de los
errores internos, el cdigo 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 combinacin 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 descomposicin : 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
rpido se hara, ( tipos: funcional, estructural y de
cdigo ) ej: mnimo de caractersticas 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 comprensin : cuanta mas informacin
tengamos, mas inteligentes sern las pruebas, se
entiende el diseo, las dependencias y la
documentacin, 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 lgica interna del programa utilizando tcnicas de
diseo de casos de prueba de "caja blanca"
los requisitos del software utilizando tcnicas de
diseo 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 mtodo obtiene casos de prueba que:
* garanticen que se ejercitan por lo menos una vez todos
los caminos independientes de cada mdulo.
* ejerciten todas las decisiones lgicas en sus vertientes
verdadera y falsa.
* ejecuten todos los bucles en sus lmites y con sus
lmites 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 inicializacin y de terminacin.

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 comunicacin 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. Nasas 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.

Cmo fu ? Por qu ?
Cunto cost ?
Qu se hizo ?