Introducción a las pruebas del software. Javier Gutiérrez / javierj@us.es

Introducción a las pruebas Objetivo: repasar las ideas principales sobre las pruebas del software.

Índice Introducción a las pruebas. Niveles de prueba. Automatización de las pruebas.

Introducción a las pruebas.

Introducción a las pruebas Ariane 5. Lanzado por primera vez el 4 de junio de 1996. Ariane 5. 36.7 segundos después explotó. …36.7 segundos después aquello parecía la celebración de la copa del Rey del Betis. En concreto el fallo fue un trozo de software que habían reutilizado del Ariane 4, pero que no habían probado en el Ariane 5. Motivo: Fallo software. La programación no se había probado lo suficiente.

Introducción a las pruebas Sistemas software: Mayor tamaño. Mayor complejidad. Menor tiempo de desarrollo. Mayor calidad. Pruebas: Más importancia y protagonismo día a día. Garantizan la calidad del software. Garantizan la satisfacción de los requisitos. Ahorran tiempo y recurso en el desarrollo. Su objetivo: localizar, para subsanarlas, el mayor número de deficiencias lo antes posible. Un reto a la Ingeniería de Software.

Introducción a las pruebas Definición de prueba: Verificación dinámica del comportamiento del software a partir de un conjunto finito de casos de prueba. Para probar un software necesitamos ejecutar ese software.

Introducción a las pruebas Definición de prueba: Validación: proceso de evaluar un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. 1 Verificación dinámica del comportamiento del software a partir de un conjunto finito de casos de prueba. Dos conceptos muy relacionados: Verificación: proceso de evaluar un sistema o componente para determinar si los productos de una determinada fase satisfacen las condiciones impuestas al comienzo de la fase. 2

Introducción a las pruebas Para probar un programa tenemos que ejecutarlo. La prueba tiene un límite. Verificación dinámica del comportamiento del software a partir de un conjunto finito de casos de prueba. No vale ejecutar el programa de cualquier manera. Vamos a empezar por el principio. ¿qué es una prueba?. Cuando viene tu madre y te dice: “niño, prueba est”, ¿eso qué significa?. dinámica : hay que ejecutar el programa. conjunto finito: un número concreto y, por regla general, pequeño. caso de prueba: no me vale con ejecutar el programa de cualquier manera. < Poner aquí algún dibuho de alguien probando algo. > < Reemplazar el clipart por un libro grande y polvoriento. >

Introducción a las pruebas Una prueba consta, al menos, de tres elementos: En este trabajo una prueba es es un conjunto de valores de prueba, accioens a realziar sobre el ssitema y el resultado esperado.

Introducción a las pruebas Veamos un ejemplo sencillo: ¿Funciona el teléfono?. Valores de prueba Acciones Resultado esperado 123-45-67-89 1. Descolgar auricular. 2. Marcar número de Pepote. 3. Esperar contestación. (Pepote): “Digameee”.

Introducción a las pruebas Veamos otro ejemplo sencillo: ¿Me está bien esta camisa? Valores de prueba Acciones Resultado esperado Mi cuerpo. 1. Ponerme la camisa. 2. Abrochármela. 3. Moverme un poco. 4. Mirarme al espejo. Cuidado con la etiqueta o con arrugarla por si hay que devolverla Elegancia y confort.

Introducción a las pruebas ¿Qué casos de prueba podemos escribir?. public int suma(int a, int b) { return a + b; } Valores de prueba Acciones Resultado esperado ??? Suma(a, b) Los casos de prueba son finitos (y cuantos menos, mejor). Poner aquí el caso

Introducción a las pruebas ¿Qué casos de prueba podemos escribir?. public int suma(int a, int b) { return a + b; } Valores de prueba Acciones Resultado esperado 0, 0 Suma(a, b) 0, b = no 0 b 3, 4 7 -2, -8 -10 -3, 6 3 Integer.MAX_VALUE, 6 -2147483643 Aquí la solución. Y algunas permutaciones más.

En conclusión Probar es ejecutar casos de prueba. Caso de prueba: entrada + acciones + salida salida obtenida == salida esperada salida obtenida != salida esperada ¿Un programa que pasa todos sus casos de prueba es un programa sin errores?. Ya hemos visto que no. Un programa que pasa todos sus casos de prueba puede tener errores y, además, muy graves.

En conclusión No Las pruebas sólo pueden encontrar los errores que buscan. Por esto es tan importante un buen diseño de pruebas. Una herramienta para garantizar la calidad, esto es, la correcta implementación de los requisitos en el sistema en desarrollo, son las pruebas del sistema.

Niveles de prueba

Niveles de prueba Aspectos que trataremos hoy FASES DE LA PRUEBA Diseño de las pruebas (¿técnicas?) Generación de casos de prueba (¿datos de prueba?) Definición del procedimiento de la prueba (¿cómo, donde?) Ejecución de la prueba Informe de la prueba (¿resultados?) TÉCNICAS DE PRUEBA Pruebas estructurales o de Caja Blanca. Pruebas funcionales o de caja negra. ESTRATEGIAS DE PRUEBA Pruebas unitarias. Pruebas de integración. Pruebas de sistema. Pruebas de aceptación. Pruebas de regresión. Aspectos que trataremos hoy

Niveles de prueba Las primeras pruebas a aplicar dentro del proceso de prueba del sistema software son las pruebas unitárias u de integración que verifican los componentes del sistema software y su inrerelación. Sin embargo, como hemos visto en una diapositiva anterior, esta spruebas no son suficiente para garantizar la calidad del sistema. Necesitamos una fase de pruebas que nos garantice que ese código sin errores realiza lo que se espera de él: la fase de pruebas del sistema.

Pruebas unitarias Herramientas: Cuando: Durante la construcción del sistema. Objetivo: Prueban el diseño y el comportamiento de cada uno de los componentes una vez construidos. Hacer dos divisiones, una para herramientas de aplicaciones de escritorio y otras

Pruebas unitarias Técnicas: Análisis de caminos. Partición de categorías. Mutaciones. Algoritmos genéricos. En general, han sido muy estudiadas.

Pruebas de integración Herramientas: Las mismas, vamos sustituyendo los mocks por las clases reales y, si es necesario, escribiendo más casos de prueba. Cuando: Durante la construcción del sistema Objetivo: Comprueban la correcta unión de los componentes entre sí a través de sus interfaces, y si cumplen con la funcionalidad establecida Hacer dos divisiones, una para herramientas de aplicaciones de escritorio y otras

Pruebas de integración Técnicas: Arriba abajo: El primer componente que se prueba es el primero de la jerarquía (A). Una de las ventajas es que las interfaces entre los distintos componentes se prueban en una fase temprana y con frecuencia. Abajo a arriba: Se prueban primero los componentes de más bajo nivel (E, F) Este tipo de enfoque permite un desarrollo más en paralelo, pero presenta mayores dificultades a la hora de planificar y de gestionar. Hacer dos divisiones, una para herramientas de aplicaciones de escritorio y otras

Pruebas de sistema Herramientas: Cuando: Durante la construcción del sistema (partes completas). Objetivo: Prueban a fondo el sistema, comprobando su funcionalidad e integridad globalmente, en un entorno lo más parecido posible al entorno final de producción. Técnicas: probar el sistema como lo hará el usuario final. Hacer dos divisiones, una para herramientas de aplicaciones de escritorio y otras

Pruebas de implantación Herramientas: Cuando: Durante la implantación en el entrono de producción. . Objetivo: Comprueban el correcto funcionamiento del sistema dentro del entorno real de producción (rendimiento, copias de seguridad, etc.). Herramientas: Las mismas. Las pruebas se vuelven a ejecutar en el entorno real de producción y se añaden nuevas pruebas. . Hacer dos divisiones, una para herramientas de aplicaciones de escritorio y otras

Pruebas de aceptación Herramientas: Herramientas: Cuando: Después de la implantación en el entorno de producción. Objetivo: Verifican que el sistema cumple con todos los requisitos indicados y permite que los usuarios del sistema den el visto bueno definitivo. Herramientas: Las mismas. Las pruebas se vuelven a ejecutar en el entorno real de producción y se añaden nuevas pruebas. . Hacer dos divisiones, una para herramientas de aplicaciones de escritorio y otras

Pruebas de regresión Herramientas: Las mismas. Cuando: Durante el mantenimiento del sistema. Objetivo: Comprobar que los cambios sobre un componente de un sistema de información, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados Herramientas: Las mismas. Hacer dos divisiones, una para herramientas de aplicaciones de escritorio y otras

Características de una buena prueba Ha de tener una alta probabilidad de encontrar un fallo. Cuanto más, mejor. No debe ser redundante. Si ya funciona, no lo probamos más. Debe ser la “mejor de la cosecha”. Si tenemos donde elegir, elegimos la mejor. No debería ser ni demasiado sencilla ni demasiado compleja. Si es muy sencilla no aporta nada, si es muy compleja a lo mejor no sabemos lo que ha fallado.

Automatización de las pruebas

Automatización de las pruebas Algunas palabras que hemos escuchado hablando de pruebas. “No sirven para nada” “Pérdida de tiempo” “Imposibles de mantener” “Engaño” “Descartadas al primer cambio” Estas son frases literales que he escuchado hablando sobre pruebas con algunas empresas. “Moda” ¿Por qué?.

Automatización de las pruebas Las pruebas son polémicas: No son parte de la solución. No se las entregamos a nuestros clientes. Incluso pueden darles a nuestros clientes una mala impresión. Nuestros clientes no nos las pagan. Difíciles de mantener. Sin embargo, las pruebas son imprescindibles. La automatización nos permite reducir costes.

Automatización de las pruebas ¿Qué significa automatizar?. ¿Qué podemos automatizar?. En este caso concreto: realizar de manera automática mediante herramientas software. Menos habitual, pocas técnicas y herramientas. El objetivo de esta presentación Diseño de las pruebas Codificación de las pruebas Ejecución de las pruebas Lo más habitual, muchas técnicas y herramientas Evaluación de resultados

Automatización de las pruebas Ventajas de la automatización: Mayor rapidez de ejecución. Menos recursos. Evitamos pruebas obsoletas

Automatización de las pruebas Inconvenientes: ¡Muy pocas herramientas!. Necesitan una “base” a menudo inexistente. Un conjunto pobre de pruebas.

Automatización de las pruebas Cuando automatizar y cuando no automatizar. Bien Mal. No buscamos automatizarlo absolutamente todo. Gastamos más en la automatización que en la pruebas en sí. Tenemos modelos y documentación del sistema. Construimos el sistema sobre la marcha. La primera respuesta es muy simple. No hemos de obsesiconarnos con la automatización. Hemos de automatizar cuando nos beneficie y no hemos de automatizar cuando los costes sean mayores que las ventajas. Nosotros controlamos las herramientas de prueba. Las herramientas de prueba nos controlan a nosotros.