Sistemas

Guía mínima de prueba de software orientado a objetos

Juan Manuel Fernández Peña

1 . Pruebas de Integración
orientadas a objetos
Las pruebas de integración han sido, hasta ahora, las menos estudiadas y
comprendidas y las más evitadas. Aún en empresas que dan poco valor a las
pruebas, los desarrolladores realizan pruebas de unidad, aún cuando sean
informales. También se efectúan algunaspruebas de sistema, al menos poco
antes de entregar el software. Sin embargo, las pruebas de integración no se ven
como necesarias.
Las pruebas de integración orientadas a objetos se enfocan a la interacción entre
unidades, suponiendo que cada una fue probada a nivel de unidad. A este nivel se
mezclan aspectos estructurales que relacionan las maneras de interactuar de las
unidades y tambiénlos aspectos típicamente funcionales.
Las pruebas de integración se ven dificultadas por el polimorfismo y la liga tardía
al tiempo de ejecución. También, en sistemas distribuidos, el uso de objetos
remotos resulta problemático.
Según Binder, las pruebas de integración pueden determinar problemas de los
tipos siguientes:
a) Problemas de configuración: se producen fallas debido a que lasversiones
de los diferentes elementos pueden resultar incompatibles, por mal control
de versiones, o por usar una versión equivocada.
b) Funciones faltantes, traslapadas o que tienen conflictos: Una clase puede
invocar un método de otra que aún no está implementado o que fue
olvidado; también puede suceder que la función invocada no realice lo que
se deseaba.
c) Uso incorrecto o inconsistentede archivos y bases de datos: Los archivos y
bases de datos son elementos importantes al integrar un sistema, pero
pueden estar ausentes o tener claves imprevistas o restricción en el número
de usuarios concurrentes o formatos diferentes al previsto.
d) Violaciones a la integridad de los datos: Al manejar bases de datos, si no se
respetan las restricciones de integridad, se producirán erroresque quizá no
se anticiparon al crear las clases.
e) Llamadas a método equivocado, debido a errores de codificación o a liga
inesperada al tiempo de ejecución: Como los objetos usan liga dinámica y a
veces los nombres de los métodos no dicen su función, es posible invocar
métodos equivocados; el polimorfismo lo agrava, ya que no se sabe con
exactitud qué objeto será el que interactúe en unmomento dado.
f) Una unidad cliente envía un mensaje que viola las precondiciones del
servidor: por ignorancia o descuido, es posible que una clase solicite un
1

Guía mínima de prueba de software orientado a objetos

g)

h)

i)

j)

k)

l)

m)

Juan Manuel Fernández Peña

servicio pero no cumpla las reglas debidas en los parámetros que se envía
y eso provoca el rechazo dela clase que debe proporcionar el servicio; por
ejemplo esperaba un número positivo y recibe uno negativo.
Objeto equivocado como destinatario en caso de polimorfismo: se esperaba
un objeto (por ejemplo un cuadrado) y llegó otro (por ejemplo un triángulo o
una elipse) y no se sabe qué hacer con él.
Parámetros erróneos o valores equivocados: los parámetros esperados no
corresponden a losenviados; por ejemplo esperaban un entero y llegó un
real; otro caso sería que falten parámetros; también puede suceder que el
valor no corresponda al rango permitido. Algunos de estos problemas no se
notan al compilar debido a la liga dinámica.
Problema de precisión en parámetros: similar al anterior, pero con tipos
parecidos; puede suceder que esperaba un entero de 16 bits y recibe uno
de 32 oviceversa.
Fallas causadas por mal manejo de memoria: en ocasiones una clase crea
y destruye objetos de otra clase y puede originar problemas si no lo hace
correctamente (en lenguajes como Java esto es poco frecuente).
Uso incorrecto de servicios del S.O., ORB1 o de máquina virtual (como la de
Java): similares a los anteriores, pero referidos a invocaciones de servicios
del sistema...