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 a las pruebas del software Motivación Tipos de errores Estrategias de pruebas Bibliografía 1
Índice a las pruebas del software Motivación Tipos de errores Estrategias de pruebas Bibliografía 2
Para qué probamos el software? Para comprobar si funciona correctamente. Para detectar errores. Principiante Experto Definición Testing is the process of executing a program with the intent of finding errors. G.J. Myers 3
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) 2 64 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 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
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. Importancia de las pruebas 5
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. 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
Importancia de las pruebas Cuanto más tarde detectemos un error, más caro resultará repararlo. Origen y coste de las pruebas Software Engineering Institute; Carnegie Mellon University; Handbook CMU/SEI-96-HB-002 7
Tipos de pruebas Funcionales: Buscar errores relacionados con la funcionalidad del sistema. No funcionales: Rendimiento. Seguridad. Usabilidad. Fiabilidad, etc. Tipos de pruebas 8
Tipos de pruebas Pruebas unitarias. Diseñadas para probar una parte pequeña y específica de funcionalidad. Ej: un método.. 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 a las pruebas del software Motivación Tipos de errores Estrategias de pruebas Bibliografía 9
Motivación Componente A Unidad de medida: Km Componente B Unidad de medida: Millas Mars Climate Orbiter, 1999 Motivación 125 millones de dólares 10
Motivación A C B ERROR: Dónde está el problema? A, B o C? Debemos asumir que los subsistemas han sido probados previamente y funcionan correctamente. Índice a las pruebas del software Motivación Tipos de errores Estrategias de pruebas Bibliografía 11
Tipos de errores Errores de programación entre componentes Errores de interoperabilidad Tipos de errores Errores de programación entre componentes Errores de interoperabilidad 12
Tipos de errores Componente A int facturacion() {... return total; } Componente B int impuestos() {... return total; } facturacion()=0 impuestos()=0 int calculo() {... return 365/(facturacion() + impuestos()); } 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
Tipos de errores Bloqueo mutuo o abrazo mortal (deadlock) Tipos de errores Bloqueo activo (livelock) 14
Tipos de errores Errores de programación entre componentes Errores de interoperabilidad Tipos de errores Errores de interoperabilidad a nivel de sistema 15
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. Tipos de errores Errores de interoperabilidad a nivel de especificación System A Petition ACK System B System A Petition Petition System B 16
Índice a las pruebas del software Motivación Tipos de errores Estrategias de pruebas Bibliografía 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
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 ) Estrategias Integración descendente. La integración se realiza partiendo del programa principal y moviéndonos hacia abajo por la jerarquía de control. M 1 (main) M 2 M 3 M 4 M 5 M 6 M 7 M 8 18
Estrategias Integración descendente - En profundidad. La integración se realiza por ramas. Cada rama suele implementar una funcionalidad específica. M 1 (main) M 2 M 3 M 4 M 5 M 6 M 7 Ramas: M 1, M 2, M 5, M 8 M 1, M 2, M 6 M 8 M 1, M 3, M 7 M 1, M 4 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? M 1 (main) M 2 M 3 M 4 M 5 M 6 M 7 M 8 19
Estrategias Stubs: Componentes de mentira que imitan el comportamiento de componentes aún no implementados (implementan su interfaz). M 1 (main) M 2 M 3 M 4 M 5 M 6 M 7 M 8 En OO suele utilizarse el término Mock object para referirse a este concepto (con sutiles diferencias). Estrategias Integración descendente - En anchura. La integración se realiza por niveles moviéndose en horizontal por la estructura de control. M 1 (main) M 2 M 3 M 4 M 5 M 6 M 7 Niveles: M 8 M 1, M 2, M 3, M 4 M 1, M 2, M 3, M 4, M 5, M 6, M 7 M 1, M 2, M 3, M 4, M 5, M 6, M 7, M 8 20
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. M 1 (main) M 2 M 3 M 4 M 5 M 6 M 7 M 8 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
Estrategias Integración de sandwich ( Sandwich testing ) Integración ascendente + Integración descendente Índice a las pruebas del software Motivación Tipos de errores Estrategias de pruebas Bibliografía 22
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 onthis 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