Pruebas de Integración - Departamento de Lenguajes y Sistemas

19/05/2013
Departamento de Lenguajes y
Sistemas Informáticos
BLOQUE II: Integración de Sistemas Software
Pruebas de Integración
Tema 10
Arquitectura e Integración de Sistemas Software
Curso 2012/2013
Índice


Introducción a las pruebas del software
Pruebas de integración




Motivación
Tipos de errores
Estrategias de pruebas
Bibliografía
1
19/05/2013
Índice


Introducción a las pruebas del software
Pruebas de integración




Motivación
Tipos de errores
Estrategias de pruebas
Bibliografía
Introducción
2
19/05/2013
Introducción
¿Para qué probamos el software?
Para comprobar si
funciona
correctamente.
Para detectar
errores.
Principiante
Experto
Introducción
Definición
“Testing is the process of executing a program with the
intent of finding errors.”
G.J. Myers
3
19/05/2013
Introducción
 Las pruebas software no permiten garantizar que un programa no
contiene errores.
 Demasiadas combinaciones. No se puede probar todo.
 Ejemplo: Suma de 2 enteros (32 bits)  ¡264 casos de prueba!
“Program testing can be a very effective way to show
the presence of bugs, but it is hopelessly inadequate for
showing their absence.”
Dijkstra, 1972
Introducción
¿Cuál es el objetivo de las pruebas?
A. Detectar el mayor número posible de errores con la mínima
cantidad de tiempo y esfuerzo.
B. Aumentar nuestra confianza en que el programa cumple los
requisitos.
C. Demostrar que un programa funciona correctamente.
4
19/05/2013
Introducción
Proceso general de prueba
Oracle
Entrada
Sistema
Salida
¿Correcto?
Éxito/Fallo
Oracle: Mecanismo que nos permite saber si el resultado de
una prueba es correcto o no. Nos permite saber el resultado
esperado.
Introducción
Importancia de las pruebas
5
19/05/2013
Introducción
Importancia de las pruebas
Complejidad del software:
 Producto intangible.
 Desarrollo a medida.
JDK7
1.142.342 líneas de código.
92.671 métodos.
11.158 clases.
456 paquetes.
Introducción
Importancia de las pruebas
Las pruebas pueden consumir hasta el 50% del coste total
del sistema. En sistemas críticos este porcentaje es mayor.
6
19/05/2013
Introducción
Importancia de las pruebas
Cuanto más tarde
detectemos un error, más
caro resultará repararlo.
Introducción
Origen y coste de las pruebas
Software Engineering Institute; Carnegie Mellon University; Handbook CMU/SEI-96-HB-002
7
19/05/2013
Introducción
Tipos de pruebas
Funcionales: Buscar errores
relacionados con la
funcionalidad del sistema.
No funcionales:
 Rendimiento.
 Seguridad.
 Usabilidad.
 Fiabilidad, etc.
Introducción
Tipos de pruebas
8
19/05/2013
Introducción
Tipos de pruebas
 Pruebas unitarias. Diseñadas para probar una parte pequeña y específica
de funcionalidad. Ej: un método.
 Pruebas de integración. Diseñadas para probar la interacción entre los
distintos componentes de un sistema.
 Pruebas de sistema. Diseñadas para probar el sistema en su totalidad
como si de una caja negra se tratase.
 Pruebas de aceptación. Diseñadas para verificar que el sistema cumple
con los requisitos exigidos por el usuario.
Índice


Introducción a las pruebas del software
Pruebas de integración




Motivación
Tipos de errores
Estrategias de pruebas
Bibliografía
9
19/05/2013
Pruebas de integración
Motivación
Componente A
Unidad de medida: Km
Componente B
Unidad de medida: Millas
Mars Climate Orbiter, 1999
Pruebas de integración
Motivación
125 millones de dólares
10
19/05/2013
Pruebas de integración
Motivación
B
A
C
ERROR: ¿Dónde está el problema? ¿A, B o C?
Debemos asumir que los subsistemas han sido probados
previamente y funcionan correctamente.
Índice


Introducción a las pruebas del software
Pruebas de integración




Motivación
Tipos de errores
Estrategias de pruebas
Bibliografía
11
19/05/2013
Pruebas de integración
Tipos de errores
Errores de programación entre componentes
Errores de interoperabilidad
Pruebas de integración
Tipos de errores
Errores de programación entre componentes
Errores de interoperabilidad
12
19/05/2013
Pruebas de integración
Tipos de errores
Componente A
Componente B
int facturacion() {
...
return total;
}
int impuestos() {
...
return total;
}
facturacion()=0
impuestos()=0
int calculo() {
...
return 365/(facturacion() + impuestos());
}
Pruebas de integración
Tipos de errores
 Ejemplo
libxml + zlib
“If you are using libxml version 2.7.6 or earlier, you will need to update libxml
to version 2.7.7 or later before installing zlib version 1.2.4 or later. libxml 2.7.6
and earlier made unnecessary assumptions about the undocumented
internal structure of zlib that were changed in zlib 1.2.4 and result in libxml
crashing. This was fixed in libxml 2.7.7” [http://www.zlib.net/]
13
19/05/2013
Pruebas de integración
Tipos de errores
• Bloqueo mutuo o abrazo mortal (deadlock)
Pruebas de integración
Tipos de errores
• Bloqueo activo (livelock)
14
19/05/2013
Pruebas de integración
Tipos de errores
Errores de programación entre componentes
Errores de interoperabilidad
Pruebas de integración
Tipos de errores
 Errores de interoperabilidad a nivel de sistema
15
19/05/2013
Pruebas de integración
Tipos de errores
• Errores de interoperabilidad a nivel de lenguaje de
programación
A veces los lenguajes de programación son
compatibles con excepciones que pueden
crear problemas. Ej. VB con VC y la
representación coma flotante.
Pruebas de integración
Tipos de errores
 Errores de interoperabilidad a nivel de especificación
Petition
System A
ACK
System B
Petition
System A
Petition
System B
16
19/05/2013
Índice


Introducción a las pruebas del software
Pruebas de integración




Motivación
Tipos de errores
Estrategias de pruebas
Bibliografía
Pruebas de integración
Estrategias
 Pruebas no incrementales (“Big bang approach”). Se integran todos
los componentes y entonces se prueba el sistema como un todo. No es
una técnica recomendada pues dificulta el aislamiento de errores.
17
19/05/2013
Pruebas de integración
Estrategias
 Pruebas incrementales. El programa es construido y probado en
pequeños incrementos. Facilita el aislamiento de errores y la
pruebas sistemáticas.
 Estrategias para pruebas incrementales:
 Integración descendente (“Top-down”)
 En profundidad (“Depth-first”)
 En anchura (“Breadth-first”)
 Integración ascendente (“Bottom-up”)
Pruebas de integración
Estrategias
 Integración descendente. La integración se realiza partiendo del
programa principal y moviéndonos hacia abajo por la jerarquía de control.
M1 (main)
M2
M5
M3
M6
M4
M7
M8
18
19/05/2013
Pruebas de integración
Estrategias
 Integración descendente - En profundidad. La integración se realiza por
ramas. Cada rama suele implementar una funcionalidad específica.
M1 (main)
M2
M5
M3
M6
M7
M8
M4
Ramas:
•
M1, M2, M5, M8
•
M1, M2, M6
•
M1, M3, M7
•
M1, M4
Pruebas de integración
Estrategias
 ¿Qué ocurre si algún módulo/componente aún no ha sido implementado
pero es necesario para probar la integración de otros componentes?
M1 (main)
M2
M5
M3
M6
M4
M7
M8
19
19/05/2013
Pruebas de integración
Estrategias
 Stubs: Componentes de “mentira” que imitan el comportamiento de
componentes aún no implementados (implementan su interfaz).
M1 (main)
M2
M5
M3
M6
M4
M7
En OO suele utilizarse el término Mock object para
referirse a este concepto (con sutiles diferencias).
M8
Pruebas de integración
Estrategias
 Integración descendente - En anchura. La integración se realiza por
niveles moviéndose en horizontal por la estructura de control.
M1 (main)
M2
M5
M3
M6
M4
M7
Niveles:
M8
•
M1, M2, M3, M4
•
M1, M2, M3, M4, M5, M6, M7
•
M1, M2, M3, M4, M5, M6, M7, M8
20
19/05/2013
Pruebas de integración
Estrategias
 Integración ascendente. La integración se realiza partiendo de módulos
atómicos situados en los nodos finales de la jerarquía de control. No suele
necesitar el uso de stubs.
M1 (main)
M2
M5
M3
M6
M4
M7
M8
Pruebas de integración
Estrategias
Integración descendente:
 Permite verificar los puntos de control o decisión al principio del proceso de
prueba.
 La integración en profundidad permite probar funcionalidades completas lo
cual aumenta la confianza.
 Puede requerir el uso de muchos stubs.
Integración ascendente:
 Se elimina la necesidad de usar stubs.
 Es necesario el uso de controladores de prueba (“drivers”) a fin de coordinar
la entrada y salida de casos de prueba.
21
19/05/2013
Pruebas de integración
Estrategias
Integración de sandwich (“Sandwich testing”)
Integración ascendente
+
Integración descendente
Índice


Introducción a las pruebas del software
Pruebas de integración




Motivación
Tipos de errores
Estrategias de pruebas
Bibliografía
22
19/05/2013
Bibliografía
Pressman R. Software Engineering: A Practitioner’s
Approach. McGraw-Hill. 2009 (7th edition)
G. Myers. The art of software testing. Wiley, 2004.
Gao, Jerry; Tsai, H.S.; Wu, Ye. Testing and Quality
Assurance for Component-Based Software. Artech
House Publishers
Disclaimer and Terms of Use
All material displayed on this presentation is for teaching and personal use only.
Many of the images that have been used in the presentation are Royalty Free
images taken from http://www.everystockphoto.com/. Other images have been
sourced directly from the Public domain, from where in most cases it is unclear
whether copyright has been explicitly claimed. Our intention is not to infringe
any artist’s copyright, whether written or visual. We do not claim ownership of
any image that has been freely obtained from the public domain. In the event
that we have freely obtained an image or quotation that has been placed in the
public domain and in doing so have inadvertently used a copyrighted image
without the copyright holder’s express permission we ask that the copyright
holder writes to us directly, upon which we will contact the copyright holder to
request full written permission to use the quote or images.
23