Tema 38.docx

Tema 38. Pruebas de Caja Negra, de Caja Blanca, del Camino Básico y de Bucles (simples, anidados, concatenados y no estructurados). Pruebas Unitarias, de Integración, del Sistema, de Implantación, de Aceptación y de Regresión. [[https://www2.infor.uva.es/\~jvalvarez/docencia/tema7.pdf]](https://www...

Tema 38. Pruebas de Caja Negra, de Caja Blanca, del Camino Básico y de Bucles (simples, anidados, concatenados y no estructurados). Pruebas Unitarias, de Integración, del Sistema, de Implantación, de Aceptación y de Regresión. [[https://www2.infor.uva.es/\~jvalvarez/docencia/tema7.pdf]](https://www2.infor.uva.es/~jvalvarez/docencia/tema7.pdf) [[http://www.lsi.us.es/docencia/get.php?id=361]](http://www.lsi.us.es/docencia/get.php?id=361) [[http://di002.edv.uniovi.es/\~dediego/is/recursos/pru.pdf]](http://di002.edv.uniovi.es/~dediego/is/recursos/pru.pdf) Las pruebas del software se realizan en diferentes etapas del ciclo de vida y son un conjunto de actividades que se realizan con el objetivo de: - Identificar y corregir errores - Asegurar que el software cumpla con los requisitos y expectativas del usuario. - Evaluar la calidad y el rendimiento del software Las **pruebas de caja negra** son una técnica de prueba de software que se utiliza para evaluar el comportamiento funcional del software sin tener en cuenta su estructura interna. En este tipo de prueba, el tester no tiene acceso al código fuente del software y no conoce su diseño interno, por lo que las pruebas se basan únicamente en la entrada y salida del software. La prueba de caja negra se basa en coger los requisitos funcionales del software y desarrollar pruebas que validen que el software cumple con esos requisitos. En este tipo de prueba, el tester se enfoca en la entrada de datos al software, las salidas generadas por el software y los estados internos del software. Algunas técnicas comunes de prueba de caja negra son: - [Pruebas de equivalencia]: Esta técnica se basa en dividir las entradas posibles del software en clases de equivalencia, y luego seleccionar algunos valores de prueba de cada clase de equivalencia para validar el comportamiento del software. Una clase de equivalencia agrupa entradas que definen los estados válidos y no válidos del sistema. *Ejemplo: Código del banco. En blanco (es opcional) o número de tres dígitos.*  *Se deberá elegir un caso de prueba para cada clase de equivalencia válida y para cada clase de equivalencia no válida.* - [Pruebas de valores límite]: esta prueba es una extensión de las pruebas de equivalencia, solo se utiliza para valores numéricos y cuando los valores se encuentran ordenados. Una clase de equivalencia contiene un valor inicial y un valor final (un número mínimo y uno máximo) y son denominados como valores límite. *En el ejemplo anterior habría que probar en con los valores 100 y 999.* - [Tablas de decisión]: es una técnica utilizada para probar el comportamiento de un sistema utilizando diferentes combinaciones de entrada. Este es un enfoque donde las diferentes combinaciones de entrada y los resultados se muestran en forma tabular. - En las filas se colocan las condiciones y los resultados, donde las condiciones se ponen en la parte superior y los resultados en la parte inferior. - Cada columna corresponde a una regla la cual es definida por las combinaciones de entrada. - Los valores a colocarse son generalmente booleanos como V (verdadero) y F (Falso). Si hay un valor que no importa para obtener cierto resultado se puede marcar con un guion \"-\". - [Prueba de Transición de Estado] (State Transition Testing): En esta técnica las condiciones de entrada provocan cambios de estado. Es ideal para cuando el sistema bajo prueba depende de eventos o valores pasados y para cuando se debe probar un sistema que consta de una secuencia de eventos. Ventajas de las pruebas de caja negra: - La prueba es imparcial porque el diseñador y el evaluador son independientes entre sí. - El evaluador no necesita conocimientos de ningún lenguaje de programación específico. - La prueba se realiza desde el punto de vista del usuario, no del diseñador. - Los casos de prueba se pueden diseñar tan pronto como se completen las especificaciones. Desventajas de las pruebas de caja negra: - Los casos de prueba son difíciles de diseñar. - Probar cada flujo de entrada posible no es realista porque llevaría una cantidad de tiempo excesiva; por lo tanto, existen casuísticas que no se probarán. Las **pruebas de caja blanca**: El objetivo de las pruebas de caja blanca es realizar pruebas que cubran la estructura interna de un sistema, por estructura interna nos referimos a código, arquitectura y flujos de trabajo. En las pruebas de caja blanca, el código es visible para los testers, por lo que también se denominan pruebas de caja transparente o pruebas de caja abierta. L[as pruebas de caja blanca validan que el software cumple con los requisitos funcionales y no funcionales]. El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos una vez, todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como falsa. Puede ser impracticable realizar una prueba exhaustiva de todos los caminos de un programa. Por ello se han definido distintos criterios de cobertura lógica, que permiten decidir qué sentencias o caminos se deben examinar con los casos de prueba. Estos criterios son: [Cobertura lógica: ] - Cobertura de sentencias: Se escriben casos de prueba suficientes para que cada sentencia en el programa se ejecute, al menos, una vez. Este criterio es necesario, pero no suficiente, es un criterio débil. - Cobertura de decisión: Se escriben casos de prueba suficientes para que cada decisión en el programa se ejecute una vez con resultado verdadero y otra con el falso. Criterio más fuerte que el anterior, pero sigue siendo un criterio débil. - Cobertura de condición: Se escriben casos de prueba suficientes para que cada condición en una decisión tenga una vez resultado verdadero y otro falso. - Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada condición en una decisión tome todas las posibles salidas, al menos una vez, y cada decisión tome todas las posibles salidas, al menos una vez. - Cobertura múltiple: Se escriben casos de prueba suficientes para que todas las combinaciones posibles de resultados de cada condición de una decisión se invoquen al menos una vez. - Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos los caminos de un programa. Entendiendo camino como una secuencia de sentencias encadenadas desde la entrada del programa hasta su salida. Una de las técnicas empleadas para aplicar el criterio de cobertura de camino es la Prueba del Camino Básico. Ejemplos de criterios de coberturas: Se tienen dos decisiones con dos condiciones cada una. Condiciones: A, B, C, D D1 (A & B) D2 (C \|\| D) Cobertura de condición, pero no de condición/decisión: Pasaría si D1 siempre F y D2 siempre V pero las condiciones tienen un valor diferente por lo menos una vez. Primer caso podría ser: A = F y B = V, C = F y D = V Segundo caso podría ser: A = V y B = F, C = V y D = F Cobertura de condición/decisión (este criterio por definición incluye la cobertura de condición y de decisión a la vez): Pasaría si D1 una vez F y otra V igual que D2: Primer caso: A = F y B = F, C = F y D = F Segundo caso: A = V y B = V, C = V y D = V Cobertura múltiple: Para cada decisión todas las combinaciones de valores de las condiciones: Primer caso: A = V, B = V, C = V y D = V Segundo caso: A = V, B = F, C = V, D = F Tercer caso: A = F, B = V, C = F, D = V Cuarto caso: A = F, B = F, C= F, D = F [Pruebas del camino básico]: es una técnica de prueba de la Caja Blanca propuesta por [Tom McCabe](https://www.ecured.cu/index.php?title=Tom_McCabe&action=edit&redlink=1) para el criterio de cobertura de caminos. Esta técnica permite obtener una medida de la complejidad lógica de un diseño y usar esta medida como guía para la definición de un conjunto básico de pruebas. La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes por los cuales puede circular el flujo de control. Para obtener dicho conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula su complejidad ciclomática. Los pasos que se siguen para aplicar esta técnica son: - A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado. - Se calcula la complejidad ciclomática del grafo. - Se determina un conjunto básico de caminos independientes. - Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico. La aplicación de este criterio de cobertura asegura que los casos de prueba diseñados permiten que todas las sentencias del programa sean ejecutadas al menos una vez y que las decisiones sean probadas tanto para su valor verdadero como falso. En un Grafo de Flujo se cumple: - Existe solo un nodo de inicio - Existe solo un nodo final - Cada nodo representa una secuencia de instrucciones - Cada arco representa paso de control al siguiente nodo - Un nodo puede tener uno o más sucesores - Un nodo puede tener uno o más antecesores - Un nodo tendrá más de un sucesor si existen varios caminos posibles dependiendo de una condición La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva decisión. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente. Luego de tener elaborados los Grafos de Flujos y los caminos a recorrer, se preparan los casos de prueba que forzarán la ejecución de cada uno de esos caminos.  [P**ruebas de bucles**] son una técnica que se utiliza para evaluar la correcta ejecución de un bucle en un programa. Los bucles son comunes en la mayoría de los programas y su correcta implementación es esencial para garantizar el correcto funcionamiento del programa. - Bucles simples: Para realizar este tipo de prueba al [software](https://www.ecured.cu/Software) se le debe aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos para el bucle: - Pasar por alto totalmente el bucle. - Pasar una sola vez por el bucle. - Pasar dos veces por el bucle. - Hacer m pasos por el bucle con m \< n. - Hacer n-1, n y n+1 pasos por el bucle. - Bucles anidados: Si se empleara el mismo enfoque de prueba de bucles simples, a los bucles anidados, el número de pruebas aumentaría considerablemente, por lo cual se sugiere emplear el siguiente enfoque: - Bucles concatenados: Se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto (si el contador del bucle 1 se usa como valor inicial del bucle 2 entonces los bucles no son independientes, de lo contrario se debe emplear el enfoque de bucles anidados. - Bucles no estructurados: Esta clase de bucles se deben rediseñar para que se ajusten a las construcciones de la programación estructurada. Las pruebas de software se dividen en diferentes tipos según su objetivo y el nivel de detalle en el que se realizan. A continuación, describimos brevemente los principales tipos de pruebas de software: - [Pruebas Unitarias]: También conocidas como pruebas de componentes, son aquellas que se realizan a nivel de módulo o componente individual del software. Se diseñan para asegurar que cada módulo funciona correctamente de manera aislada y se realizan en una etapa temprana del ciclo de vida del software. Tanto las pruebas de caja blanca como las de caja negra han de aplicar para probar de la manera más completa posible un módulo. Nótese que las pruebas de caja negra (los casos de prueba) se pueden especificar antes de que módulo sea programado, no así las pruebas de caja blanca. - [Pruebas de Integración]: Son aquellas que se realizan para verificar la correcta interacción entre los diferentes componentes o módulos del software. Se realizan después de las pruebas unitarias y antes de las pruebas de sistema. A menudo hay una tendencia a intentar una integración no incremental; es decir, a combinar todos los módulos y probar todo el programa en su conjunto. El resultado puede ser un poco caótico con un gran conjunto de fallos y la consiguiente dificultad para identificar el módulo (o módulos) que los provocó. En contra, se puede aplicar una integración incremental en la que el programa se prueba en pequeñas porciones en las que los fallos son más fáciles de detectar. Existen dos tipos de integración incremental, la denominada ascendente y descendente: - Incrementales ascendente: empieza la construcción y la prueba con los módulos atómicos, es decir, módulos de los niveles más bajos de la estructura del programa. Dado que los módulos son integrados de abajo hacia arriba, el procesamiento requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de resguardo. - Incrementales descendente: inicia del módulo de control principal (de mayor nivel) para luego ir incorporando los módulos subordinados progresivamente. - [Pruebas de Sistema]: Son pruebas que se realizan a nivel de todo el sistema, una vez que todos los componentes o módulos (hardware, software, etc.) se han integrado, pero se realizan en el entorno de pruebas. Su objetivo es verificar que el software funciona correctamente en su totalidad, cumpliendo con todos los requisitos especificados. Concretamente se debe comprobar que: - Se cumplen los requisitos funcionales establecidos. - Se cumple con el funcionamiento y rendimiento de las interfaces hardware, software y de usuario. - La adecuación de la documentación de usuario. - Rendimiento y respuesta en condiciones límite y de sobrecarga. - [Pruebas de implantación]: Una vez que hayan sido realizadas las pruebas del sistema en el entorno de desarrollo, se llevan a cabo las verificaciones necesarias para asegurar que el sistema funcionará correctamente en el entorno de producción. Además de repetir las pruebas que se hicieron del sistema pero ahora con valores reales habrá que incorporar pruebas de seguridad. Tenemos que comprobar que se cumplen todos los requisitos de seguridad y verificar que los mecanismos de protección incorporados al sistema cumplen su objetivo. - [Pruebas de Aceptación]: Son pruebas que se realizan para verificar que el software cumple con los requisitos y expectativas del cliente o usuario final. El usuario debe ser el que realice las pruebas, ayudado por personas del equipo de pruebas, siendo deseable, que sea el mismo usuario quien aporte los casos de prueba. Estas pruebas se caracterizan por: - Participación activa del usuario, que debe ejecutar los casos de prueba ayudado por miembros del equipo de pruebas. - Están enfocadas a probar los requisitos de usuario, o mejor dicho a demostrar que no se cumplen los requisitos, los criterios de aceptación del contrato. Si no se consigue demostrar esto el cliente deberá aceptar el producto. - Corresponden a la fase final del proceso de desarrollo de software. - [Pruebas de Regresión]: Se efectuarán para comprobar que los cambios no han originado efectos adversos no intencionados o que se siguen cumpliendo los requisitos especificados. En las pruebas de regresión hay que: - Probar íntegramente los módulos que se han cambiado. - Decidir las pruebas a efectuar para los módulos que no han cambiado y que han sido afectados por los cambios producidos. Es importante destacar que estas pruebas no son excluyentes y se pueden realizar en combinación, dependiendo del nivel de complejidad del software y los requisitos específicos de calidad del proyecto. Principio del formulario