Tema 2 Pruebas (Parte 2) 2023/2024 - PDF

TEMA 2 PRUEBAS PARTE 2 Programación Orientada a Objetos Curso 2023/2024  ÍNDICE PARTE 2 Introducción Pruebas de programas Características Clasificación En función de su ámbito En función de su técnica Pru...

TEMA 2 PRUEBAS PARTE 2 Programación Orientada a Objetos Curso 2023/2024  ÍNDICE PARTE 2 Introducción Pruebas de programas Características Clasificación En función de su ámbito En función de su técnica Pruebas unitarias de caja negra Partición de equivalencia Análisis de valores límite Ejemplo 1 Ejemplo 2 (clase) Modalidades de clase Ejemplo JUnit (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 2  INTRODUCCIÓN SISTEMAS SOFTWARE PRUEBAS Mayor tamaño Más importancia día a día Más complejos Garantizan la calidad del software Menor tiempo de desarrollo Garantizan la satisfacción de los requisitos Mayor calidad Ahorran tiempo y recurso en el desarrollo Localizar el mayor número de deficiencias lo antes posible (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 3  PRUEBAS DE PROGRAMAS Un fallo es cualquier situación inesperada que se produce durante la ejecución de un programa Un error es cualquier elemento de software que es incorrecto desde un punto de vista sintáctico o semántico. Los errores pueden provocar fallos, pero no siempre lo hacen Llamaremos prueba al proceso de ejecutar un programa para localizar errores. Una prueba, en general, identifica los fallos que son síntoma de errores Depuración es el proceso de identificar y eliminar uno o varios errores a partir de un fallo. (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 4  PRUEBAS DE PROGRAMAS: CARACTERÍSTICAS Objetivo: ▪ No aseguramos la ausencia de defectos en el software, únicamente podemos demostrar que existen defectos en el software Diseñaremos pruebas que, sistemáticamente, saquen a la luz diferentes clases de errores, en la menor cantidad de tiempo y esfuerzo Normalmente, deberían hacerse por un equipo independiente del que lo ha desarrollado. ▪ Es difícil que esto ocurra en las unitarias (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 5  PRUEBAS DE PROGRAMAS: CARACTERÍSTICAS Una buena prueba debe tener una alta probabilidad de encontrar un fallo. ▪ Hay que saber dónde puede fallar el software Una buena prueba debe centrarse en : ▪ Probar si el software no hace lo que debe hacer ▪ Probar si el software hace lo que no debe hacer Una buena prueba no debe ser redundante. Una buena prueba debería ser la mejor, es decir, que tuviera la mayor probabilidad de encontrar una clase entera de errores. No se deberían combinar varias pruebas en una porque enmascara errores. (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 6  ÍNDICE PARTE 2 Introducción Pruebas de programas Características Clasificación En función de su ámbito En función de su técnica Pruebas unitarias de caja negra Partición de equivalencia Análisis de valores límite Ejemplo 1 Ejemplo 2 (clase) Modalidades de clase Ejemplo JUnit (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 7  TIPOS DE PRUEBAS En función de su ámbito ▪ De aceptación ▪ De sistema ▪ De integración ▪ Unitarias En función de su técnica ▪ Caja blanca ▪ Caja negra (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 8  EN FUNCIÓN DE SU ÁMBITO Necesidades del Pruebas de METODOLOGÍAS DE PRUEBA PROCESO DE DESARROLLO usuario aceptación Pruebas de SOFTWARE Requisitos sistema Diseño Pruebas de integración Codificación Pruebas unitarias (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 9  EN FUNCIÓN DE SU ÁMBITO 2 Pruebas unitarias Las encontramos en el nivel de codificación. Con ellas probamos las unidades del software, normalmente métodos. ▪ Por ejemplo, escribimos estas pruebas para comprobar si un método de una clase funciona correctamente de forma aislada. ▪ Nos interesa cómo funciona la unidad, no la interacción entre componentes. ▪ La ventaja de las pruebas unitarias es que los tests tardan menos tiempo en ejecutarse, por lo que se tiende a lanzarlos más a menudo. o Además, las pruebas unitarias te fuerzan a escribir clases menos acopladas (con menos dependencias las unas de las otras), lo que mejora el diseño del software. o Para automatizar y realizar este tipo de pruebas se utilizan framework de tests, por ejemplo JUnit en el caso de Java. Fail: El test está mal hecho Error: Hay un error en tu programa y se ha detectado por el test (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 10  EN FUNCIÓN DE SU ÁMBITO Necesidades del Pruebas de METODOLOGÍAS DE PRUEBA PROCESO DE DESARROLLO usuario aceptación Pruebas de SOFTWARE Requisitos sistema Diseño Pruebas de integración Codificación Pruebas unitarias (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 11  EN FUNCIÓN DE SU ÁMBITO 3 Pruebas de integración En este caso probamos cómo es la interacción entre dos o más unidades del software. Este tipo de pruebas verifican que los componentes de la aplicación funcionan correctamente actuando en conjunto. Este tipo de pruebas son dependientes del entorno en el que se ejecutan. ▪ Si fallan, puede ser porque el código esté bien, pero que haya un cambio en el entorno. ▪ Con JUnit se puede realizar pruebas de integración (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 12  EN FUNCIÓN DE SU ÁMBITO Necesidades del Pruebas de METODOLOGÍAS DE PRUEBA PROCESO DE DESARROLLO usuario aceptación Pruebas de SOFTWARE Requisitos sistema Diseño Pruebas de integración Codificación Pruebas unitarias (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 13  EN FUNCIÓN DE SU ÁMBITO 4 Pruebas de sistema En estas pruebas se prueba todo el sistema software al completo una vez que se han pasado las pruebas de integración. Pruebas funcionales ▪ Se comprueba que el software que se ha creado cumple con la función para la que se había pensado. ▪ Es decir, si ante una serie de entradas el software devuelve los resultados que nosotros esperábamos. No se comprueba si el software esté bien hecho, o si el diseño del software es el correcto. ▪ Estas pruebas se pueden hacer a mano o bien automatizarse con alguna herramienta como Selenium,etc. Pruebas de carga ▪ Son un tipo de prueba de rendimiento del sistema. Se observa la respuesta de la aplicación ante un determinado número de peticiones. Pruebas de estrés ▪ Este es otro tipo de prueba de rendimiento del sistema. ▪ El objetivo de estas pruebas es someter al software a situaciones extremas, intentar que el sistema se caiga, para ver cómo se comporta, si es capaz de recuperarse etc. (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 14  EN FUNCIÓN DE SU ÁMBITO Necesidades del Pruebas de METODOLOGÍAS DE PRUEBA PROCESO DE DESARROLLO usuario aceptación Pruebas de SOFTWARE Requisitos sistema Diseño Pruebas de integración Codificación Pruebas unitarias (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 15  EN FUNCIÓN DE SU ÁMBITO 5 Pruebas de aceptación Por último, las pruebas de aceptación se realizan para comprobar si el software cumple con las expectativas del usuario- cliente. (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 16  TIPOS DE PRUEBAS En función de su ámbito ▪ De aceptación ▪ De sistema ▪ De integración ▪ Unitarias En función de su técnica ▪ Caja blanca ▪ Caja negra (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 17  EN FUNCIÓN DE SU TÉCNICA CAJA NEGRA CAJA BLANCA (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 18  EN FUNCIÓN DE SU TÉCNICA Técnicas de caja negra o funcionales ▪ Los casos de prueba se basan en la interfaz del método, es decir , en las entradas y salidas. Técnicas de caja blanca o estructurales ▪ Los casos de prueba se seleccionan minuciosamente en función de la estructura del método y de su lógica. ▪ Se debe conocer su código ▪ Se debe garantizar que todos los caminos de ejecución del programa (bucles, condición..) quedan cubiertos (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 19  ÍNDICE PARTE 2 Introducción Pruebas de programas Características Clasificación En función de su ámbito En función de su técnica Pruebas unitarias de caja negra Partición de equivalencia Análisis de valores límite Ejemplo 1 Ejemplo 2 (clase) Modalidades de clase Ejemplo JUnit (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 20  PRUEBAS UNITARIAS DE CAJA NEGRA Son las que vamos a desarrollar en este tema, porque ▪ Es a nivel de codificación (nuestro nivel) ▪ Analizaremos cada método o No necesitamos conocer el código sino solo la interfaz del método o Entradas y salidas Entradas correctas deberían obtener salidas correctas Entradas incorrectas deberían provocar el lanzamiento de una excepción o un error de un Aserto Entradas determinadas => Salidas esperadas vs Salidas obtenidas (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 21  PRUEBAS UNITARIAS DE CAJA NEGRA En vez de analizar una gran cantidad de combinaciones de entradas y salidas: ▪ Particiones de equivalencia Test JUnit ▪ Análisis de valores límite (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 22  PARTICIONES DE EQUIVALENCIA Clase de equivalencia para un programa es un conjunto de datos de entrada para el mismo de los que podemos esperar un comportamiento homogéneo. ▪ Las clases pueden ser: o válida cuando los datos representan entradas válidas para el programa o no válida en cualquier otro caso. (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 23  PARTICIONES DE EQUIVALENCIA Clase de equivalencia ▪ ▪ (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 24  CONDICIONES DE ENTRADA La condición de entrada especifica Un rango de valores ▪ Una válida (dentro del rango) y dos no válidas(una por encima y otra por debajo) Una cantidad de valores ▪ Una válida (con el número de valores especificados) y dos no válidas (más o menor valores) Un valor entre un conjunto de valores ▪ Tantas clases válidas como valores posibles y una no válida (valores declarados como no posibles) Un dato debe ser ▪ Un válida (lo es) y otra no válida (no lo es) (c). M. Gonzalo-Tasis, Depto de Informática, UVa oct.-23 25  CONDICIONES DE ENTRADA La condición de entrada especifica Un rango de valores : contador entre 1 y 999 ▪ Una clase de equivalencia válida que contemple los valores del rango o 1