PRUEBAS Y DEPURACIN DE PROGRAMAS

1.- CONCEPTOS PRELIMINARES

Testing: Es el proceso de ejecutar un programa con la intencin de encontrar errores.
Debugging: Proceso de diagnosticar la naturaleza de un error y entonces corregirlo.
Premisas Bsicas:
Un buen caso de prueba, es aquel que tiene una alta probabilidad de detectar errores
no descubiertos.
Un caso de prueba exitoso es el que detecta los errores no descubiertos.
El testing no puede mostrar la ausencia de errores, slo demuestra los defectos
presentes en el software.
Los casos de prueba pueden planificarse y disearse antes de generar el cdigo.
Para que sean efectivos, los casos de pruebas deben ser realizados por un equipo
independiente.

2.- ESTRATEGIAS DE TESTING

2.1.- WHITE-BOX TESTING (Prueba de caja blanca)
Tambin llamada Prueba de Caja de Cristal, se basa en la lgica del programa,
examinando su estructura interna. Los datos de prueba se derivan a partir de la lgica
del programa y generalmente sin considerar las especificaciones.
La idea es ejecutar, mediante casos de pruebas, todos los posibles caminos de
flujo de control a travs del programa.
A pesar que esta estrategia presenta el problema que para programas grandes, las
combinaciones de posibles caminos tienden a ser infinitas, su uso se justifica por la
naturaleza de los siguientes errores de software:

 Los errores tienden a introducirse al disear funciones, condiciones o controles para

el manejo de casos especiales (Excepciones)
El flujo lgico de un programa no es intuitivo, es decir, a veces se cree que un
camino lgico tiene pocas posibilidades de ejecutarse, cuando en realidad no es as.
Los errores tipogrficos son aleatorios. Algunos errores de escritura se descubren al
realizar un anlisis sintctico, pero otros no se descubren hasta la ejecucin del
programa.

2.1.- BLACK-BOX TESTING (Prueba de caja negra)

Esta estrategia est orientada a los datos de entrada y salida, sin internarse en la
estructura lgica del programa. La idea es encontrar las circunstancias en las cuales el
programa no se comporta segn las especificaciones. Los datos de prueba se derivan a
partir de las especificaciones. Para lograr el objetivo, se deben usar como casos de
prueba, todas las posibles entradas, no slo las vlidas.
Esta estrategia intenta encontrar errores de las siguientes categoras:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores de estructuras de datos o en acceso a base de datos externas.
Errores de rendimiento.
Errores de iniciacin y de terminacin.
Su principal problema radica en que para programas muy grandes, las posibles
combinaciones de entrada tienden a infinito.
Ambas estrategias son complementarias, ya que buscan descubrir distintos tipos de
errores. Primero se aplica la prueba de caja blanca y posteriormente la prueba de caja
negra.

3.- NIVELES DE PRUEBA

Segn sea el tipo de error que se desea encontrar, y el estndar bajo el cual se testea
el sistema, existen distintos niveles de prueba, que a continuacin se detallan.

3.1.- TESTING DE UNIDAD

Es la verificacin de cada mdulo de programa aislado, independiente de otros
mdulos. El testing de unidad siempre est orientado a caja blanca y se puede realizar
en paralelo para mltiples mdulos. Las verificaciones que se realizan en el test de
unidad son las siguientes y en este orden:
1. Interfaz del mdulo.
2. Estructuras de datos locales.
3. Caminos de ejecucin independientes.
4. Caminos de manejo de errores.
5. Condiciones lmites.

3.2.- TESTING DE INTEGRACIN

Es la verificacin de las interfaces entre partes del sistema, sean estas mdulos,
componentes y/o subsistemas. Para realizar estas pruebas, existen diversas estrategias de
integracin, entre las que se encuentran:
a) Bottom-Up: Se comienza testeando los mdulos que no llaman a otros, se sigue con
los que llaman directamente a los previamente probados. Estos nuevos mdulos no
se prueban de manera aislada, sino en conjunto con los de ms bajo nivel. Esta
estrategia requiere el uso de un Module driver que es un mdulo que simula las
entradas que requiere el mdulo que se est probando.
b) Top-Down: El nico mdulo que se prueba en forma independiente es el tope,
despus se van incorporando los mdulos llamados por l. Se requiere el uso de
Stub modules que son mdulos que simulan las funciones de mdulos llamados que
aun no han sido probados.

c) Top-Down Modificado: Cada mdulo se testea independientemente antes de

integrarlo al sistema. Requiere el uso de mdulos drivers y stubs para cada mdulo.
d) Big Bang: Esta estrategia no es incremental como las anteriores, cada mdulo se
testea aislado y luego se integran todos de una vez. Se requieren drivers y stubs para
cada mdulo. Slo sirve para programas pequeos.
e) Sndwich: Se comienza aplicando a la vez los mtodos top-down y bottom-up. Est
orientado a sistemas grandes.
f) Sndwich Modificado: Los niveles inferiores se testean usando bottom-up y los
niveles superiores primero se testean en forma aislada y luego se les aplica topdown (Top-down modificado).

3.3.- TESTING DE ACEPTACIN

Es la validacin del sistema segn los requerimientos del usuario. Se utiliza la
estrategia de caja negra. Se busca validar los siguientes aspectos:
Si se satisfacen todos los requisitos funcionales.
Si se cumplen los requisitos de rendimiento.
Si la documentacin es correcta e inteligible.
Dado que la aceptacin del sistema depende del usuario, el test de aceptacin puede
consistir de varios meses de prueba por parte del usuario. Asociados a este nivel de
testing, existen dos pruebas:
a) Prueba Alfa: Se realiza en un entorno controlado por el desarrollador. Un cliente
usa el software en forma natural, observado por el desarrollador que registra los
errores y problemas de uso.
b) Prueba Beta: La realizan los usuarios finales del sistema, sin la presencia del
desarrollador, registrando los problemas que encuentra. Generalmente como
resultado, el desarrollador prepara otra versin del producto.

3.4.- TESTING DEL SISTEMA

Considerando que el software es slo un elemento del sistema, este nivel de
prueba busca testear la incorporacin del software a otros elementos tales como nuevo
hardware e informacin. Se realizan distintos tipos de pruebas:
a) Prueba de Recuperacin: Fuerza a fallar al software de muchas formas y verifica
que la recuperacin se realice en forma apropiada.
b) Prueba de Seguridad: Intenta verificar que los mecanismos de proteccin
incorporados al sistema, lo protegern de accesos impropios. Una buena prueba de
seguridad terminar por acceder al sistema ilegalmente. El rol del diseador del
sistema es lograr que el coste de la entrada ilegal sea mayor que el valor de la
informacin obtenida.
c) Prueba de Resistencia: Estn diseadas para enfrentar a los programas con
situaciones anormales, respecto al uso de recursos, frecuencias o volmenes.
d) Prueba de Rendimiento: Est diseada para probar el rendimiento del software en
tiempo de ejecucin dentro del contexto de un sistema integrado.

4.- DEPURACIN
La depuracin (debugging) es la consecuencia de una prueba efectiva. Es el
proceso que elimina los errores detectados durante el testing.
Muchas veces, los datos errneos detectados durante una prueba, slo son un
sntoma de una causa oculta. Si la causa no se encuentra, el depurador debe formular
hiptesis sobre ella , disear casos de prueba orientados a confirmar dichas sospechas y
volver a la correccin en forma iterativa.
Dificultades de la depuracin:
1. El sntoma y la causa pueden estar geogrficamente remotos, es decir, el sntoma
puede aparecer en un lugar del programa, mientras que la causa est localizada en
otra parte muy lejana. Los programas con alto acoplamiento generan este tipo de
dificultad.
2. El sntoma puede desaparecer temporalmente al corregir otro error.

3. El sntoma puede ser producido por una situacin que no es un error.

4. El sntoma puede ser causado por un error humano difcil de detectar.
5. El sntoma puede ser el resultado de problemas de temporizacin en lugar de
procesos.
6. Puede ser difcil reproducir exactamente las condiciones de entrada.
7. El sntoma puede aparecer en forma intermitente.
8. El sntoma puede deberse a causas distribuidas por varias tareas que se ejecutan en
varios procesadores.

5.- ESTRATEGIAS DE DEPURACIN

5.1.- FUERZA BRUTA
Es la ms comn, pero menos eficiente. Consiste principalmente en realizar
trazas de la ejecucin mediante una multitud de sentencias de impresin en el programa.
Aunque es muy probable encontrar el error, se desperdicia tiempo y esfuerzo.
5.2.- VUELTA ATRS
Es exitosa para programas pequeos. Se parte desde donde se descubri el
sntoma, hacia atrs, recorriendo manualmente el cdigo, hasta llegar al error. Mientras
mayor sea el cdigo, el nmero de posibles caminos de vuelta se torna inmanejable.
5.3.- ELIMINACIN DE CAUSAS
Los datos relacionados con la ocurrencia del error se organizan para determinar
posibles causas, y se realizan pruebas para eliminar cada hiptesis. Si alguna prueba da
indicios que alguna de estas hiptesis es la causa del error, se refinan los datos de
prueba hasta aislar el error.