Pruebas

de integracin
OO
MA RLON SA NT IA GO VI N LUD EA
INGENIERA D E SOFT WA RE II
Introduccin
Menos comprendidas y las ms evitadas.
PI orientadas a objetos son se enfocan en la interaccin
entre unidades. Por ejemplo interaccin entre objetos o
llamadas a otros mtodos dentro de otro
Las pruebas de integracin se ven dificultadas por el
polimorfismo
Introduccin
Segn Binder, las pruebas de integracin pueden
determinar problemas de los siguientes tipos:
Problemas de configuracin: versiones inadecuadas.
Funciones faltantes, traslapadas o que tienen conflictos.
uso incorrecto e inconsistente de archivos y bases de datos.
Violaciones de integridad de datos.
Llamadas a un mtodo equivocado.
Un cliente enva un mensaje que viola las precondiciones del servidor
Introduccin
Segn Binder, las pruebas de integracin pueden
determinar problemas de los siguientes tipos:
Objeto equivocado como destinatario en caso de polimorfismo.
Parmetros errneos o valores equivocados.
Problemas de precisin enparmetros.
Fallas causadas por mal manejo de memoria.
Uso incorrecto del sistema operativo o de la mquina virtual.
Conflictos entre componentes.
Recursos insuficientes
Enfoques: Pruebas de integracin
En el caso de software orientado a objetos ,
cuando se usa algn mtodo derivado de los casos de
uso, stos brindan de manera prctica la forma de
realizar las pruebas de integracin, guiandose por los
diagramas de colaboracin o los diagramas de
secuencia asociados con cada caso de uso
Caso de uso como unidad de pruebas de
integracin
Casos de uso como la unidad mnima de funcionalidad.
Para el diseo se realizan un conjunto de diagramas de
colaboracin o de secuencia.
Se acostumbra construir un diagrama para el caso tpico
exitoso y otro para un caso alterno, generalmente una falla
tpica.
Nos reifiriremos a los diagramas de secuencia para las
prubas de integracin
Caso de uso como unidad de pruebas de
integracin
Un diagrama de secuencia presenta varios elementos
importantes para las pruebas de integracin.
El conjunto de clases (objetos) que interactan
Las interacciones entre los objetos, mostradas como secuencias
de mensajes que activan mtodos.
Cada caso de uso ameritar varios casos de prueba; al menos
uno por cada diagrama de secuencia. Se origina por dos
elementos:
El estado de los diferentes componentes.
Los distintos valores que pueden tener los diversos parmetros
de los mtodos involucrados
Casos de uso: estado de los elementos
Un diagrama de secuencia muestra: objetos que pueden
representar clases internas, archivos o bases de datos.
Pueden existir otros elementos como: existencia de una
red, presencia o ausencia de otros elementos de software(
SO, procesos externos )
Todos los elementos influyen dentro de la ejecucin del
software afectando la interaccin entre los objetos, algo
que no importaba a nivel de pruebas de unidad.
Casos de uso: estado de los elementos
De stos elementos interesar bsicamente su estado,
expresado en forma de proposiciones lgicas. Por ejemplo.
El objeto X est presente.
El archivo est presente y abierto.
La tabla est presente pero no accesible.
La red est desconectada.
El objeto Y existe, pero es de una versin anterior a la espereda.
Existen al menos 10 procesos corriendo al mismo tiempo.
Casos de uso: estado de los elementos
Tipo de elemento Posibles estados

objeto Existe, no existe, existe pero es una versin

inadecuada

Recurso compartido (archivo, BD) Existe, no existe, no es accesible (falta de

autorizacin, exceso de usuarios, bloqueado)

Dispositivo (red, impresora) Listo, en problemas, desconectado

Casos de uso: Valores de parmetros

Si un mtodo carece de parmetros, bastar un caso de

prueba que lo invoque.
En caso de existir parmetros, existirn valores aceptables
y no aceptables, stos pueden dividirse en subconjuntos con
comportamientos similares (particiones).
Casos de uso: Conjuntos de datos
adecuados
ValoresA al conjunto de valores
que pueden recibir los parmetros
del mtodo MetA y este conjunto
se descompone en dos: AtraviesaB
y NoAtraviesaB. El primero es el
conjunto de valores que estn en
ValoresA y que producen una
llamada a MetB. El segundo
incluye valores que estn en
ValoresA pero nunca generan
llamadas a MetB
Generacin de casos de prueba
Para cada diagrama de secuencia, generar los estados posibles
de los elementos involucrados.
Para cada mtodo de las interacciones incluidas en el
diagrama de secuencia determinar los conjuntos de valores
adecuados, segn las particiones internas y segn si permiten
continuar la cadena de llamadas a otras clases involucradas y
seleccionar valores representativos.
Con cada estado y cada representante de conjunto de datos se
forma un caso de prueba, combinando los diferentes valores de
cada categora
Ejemplo: Identificacin de usuario
usando una clase TClave
Ejemplo: Identificacin de usuario
usando una clase TClave
Ejemplo: Identificacin de usuario usando una
clase Tclave (Estados identificables)
Tres clases explicitamente
definidas y un componente
externo que es la base de datos
Elemento Estados
MySQL.
UIClave Presente, ausente
Opera en un solo equipo por lo
que no interviene una red. TClave Presente, ausente
En el caso de la bd puede Dilogos Presente, ausente
suceder que no est instalado
MySQL, que la base de datos no Base de datos Activa, con problemas
exista, que la clave no sea correcta
y otros estados indeseables
Con problemas
Ejemplo: Identificacin de usuario usando una
clase Tclave (Valores adecuados)
La llamada inicial cuando el Valores de entrada estados
actor oprime el botn Listo y Juan, orion7 Nombre y contrasea
se lanza el mtodo asociado al registradas
evento: identificalo, con dos Juan, qwerty Nombre registrado,
parmetros nombre y contrasea mal
contrasea que toma de Juan Falta contrasea
campos de la interfaz. Estos , orion7 Falta nombre
parmetros pasan sin cambio a Ulises, dft7h Nombre no registrado
la clase Tclave y de sta el
primero pasa tal cual a la base
de datos
Ejemplo: Identificacin de usuario usando una
clase Tclave (Casos de prueba detallados)
Entrada Condiciones de entrada Salida esperada Condicione
s de salida
Juan, orion7 UIClave ausente Falla de ejecucin
Juan, orion7 Tclave ausente Falla de ejecucin
Juan, orion7 Base de datos con problema Falla de ejecucin
Juan, orion7 Dilogos ausente Falla de ejecucin
Juan, orion7 IUClave presente Tclave presente, base de datos Mensaje de bienvenida
activa
Juan, qwerty IUClave presente Tclave presente, base de datos Mensaje de error en
activa contrasea
juan IUClave presente Tclave presente, base de datos Mensaje de error en
activa contrasea
, orion7 IUClave presente Tclave presente, base de datos Mensaje de error en
activa nombre
Ulises, df7h IUClave presente Tclave presente, base de datos Mensaje de error en
activa nombre
Ejemplo: Identificacin de usuario
usando una clase Tclave (Conclusin)
Para automatizar las pruebas de integracion
orientadas a objetos se pueden emplear las mismas
herramientas de la prueba unidad, pero los casos de
prueba sern un poco ms largas en alguna ocasin y
la verificacin de resultados puede requerir mas de
una comprobacin
Pruebas de sistema
Las pruebas de sistema son importantes cuando se ha
concluido con la implementacin del producto.
Versiones realizadas por el desarrollador y otras por el
cliente
Pruebas pueden ser funcionales, as como pruebas de
rendimiento, de estrs, de seguridad, de instalacin y otras.
Pruebas del sistema: Pruebas funcionales
Tienen como gua los
requerimientos establecidos por el
cliente y se busca analizar si lo
satisfacen.
Pruebas de sistema: Por el desarrollador
Se dividen en Alfa y Beta:
Las primeras se realizan en las instalaciones del desarrollador
Las segundas en las instalaciones del cliente, pero bajo
control del desarrollador.
Las pruebas que el cliente realiza se suelen denominar
pruebas de aceptacin