INGENIERÍA DEL SOFTWARE II PRUEBAS Y VALIDACIONES DE

SOFTWARE

Profesor Osmar Mavarez

INGENIERÍA DEL SOFTWARE PRUEBAS Y VALIDACIONES DE SOFTWARE

UNIDAD I

CONTENIDO • Definición • Objetivos de las pruebas de software • Principios de las pruebas de software. • Error, defecto y fallas • Pruebas de caja blanca y de caja negra. • Estrategias de aplicación de prueba de unidad,

integración, sistema, y de aceptación • Etapas involucradas en las pruebas de software. • Evaluación de resultados

1.- DEFINICIÓN DE LAS PRUEBAS DE SOFTWARE

Son técnicas donde se analiza el comportamiento de un producto (software), para encontrar la mayor cantidad de errores y fallos posibles, con la finalidad de asegurar la calidad del mismo, en términos de funcionalidad, usabilidad, consistencia, tolerancias a fallos, integridad, seguridad, etc.

2.- Objetivos de las pruebas de software.

La prueba de software es un elemento crítico para la garantía del correcto funcionamiento del software. Entre sus objetivos están: • Detectar defectos en el software. • Verificar la integración adecuada de los componentes. • Verificar que todos los requisitos se han implementado

correctamente. • Identificar y asegurar que los defectos encontrados se

han corregido antes de entregar el software al cliente. • Diseñar casos de prueba que sistemáticamente saquen

a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

3.- Principios de las pruebas de software.

Las pruebas se rigen por una serie de principios, una buena comprensión de estos facilitará el posterior uso de los métodos en un efectivo diseño de casos de prueba. A continuación, se citan: 1. La prueba puede ser usada para mostrar la presencia de errores, pero nunca su

ausencia. 2. La principal dificultad del proceso de prueba es decidir cuándo parar. 3. Evitar casos de pruebas no planificados, no reusables y triviales a menos que el

programa sea verdaderamente sencillo. 4. Una parte necesaria de un caso de prueba es la definición del resultado

esperado. 5. Los casos de pruebas tienen que ser escritos no solo para condiciones de entrada

válidas y esperadas sino también para condiciones no válidas e inesperadas. 6. El número de errores sin descubrir es directamente proporcional al número de

errores descubiertos. Estas leyes que definen básicamente la aplicación de las pruebas de software ayudan a refinar el producto de software a través de las etapas involucradas.

4.- ERROR, DEFECTO Y FALLAS Un error de programación se puede dar al momento en que

el desarrollador asigna 2 valores a una misma variable, o cometido en la lógica de programación.

En el momento en que se compila el código, se arma la versión y se instala en un ambiente, ese software contiene defectos, ¿Cuáles?, no lo sabemos si no hasta ejecutar nuestras pruebas, en el momento en que el sistema falla, se manifiesta mediante un mensaje de error el cual

capturamos para reportar un fallo.

ERROR, DEFECTO Y FALLAS

• En resumen, un error introduce un defecto en el software que a su vez causa un fallo al momento de ejecutar pruebas.

5.- PRUEBAS DE CAJA BLANCA Y DE CAJA NEGRA.

A. PRUEBAS DE CAJA BLANCA Se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Las pruebas de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran: 1. La cobertura de caminos (pruebas que hagan que se

recorran todos los posibles caminos de ejecución). 2. Pruebas sobre las expresiones lógico-aritméticas. 3. Pruebas de camino de datos (definición-uso de

variables). 4. Comprobación de bucles

PRUEBAS DE CAJA BLANCA

PRUEBAS DE CAJA NEGRA

Se centra en las funciones, entradas y salidas. Intenta encontrar errores de las siguientes categorías:

• Funciones Incorrectas o ausentes.

• Errores de Interfaz.

• Errores en estructuras de datos o acceso a base de datos externas.

• Errores de rendimiento.

• Errores de inicialización y de terminación

PRUEBAS DE CAJA NEGRA

6.- ESTRATEGIAS DE APLICACIÓN DE PRUEBA DE UNIDAD, INTEGRACIÓN, SISTEMA, Y DE ACEPTACIÓN

6.1.- PRUEBAS DE UNIDAD. Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado. Las pruebas de unidad es un proceso para probar los subprogramas, las subrutinas, los procedimientos individuales o las clases en un programa. Es decir, es mejor probar primero los bloques desarrollados más pequeños del programa, que inicialmente probar el software en su totalidad.

6.2.- PRUEBAS DE INTEGRACIÓN.

El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las especificaciones necesarias.

6.2.- PRUEBAS DE INTEGRACIÓN.

Los tipos fundamentales de integración son los siguientes: • Integración incremental: se combina el

siguiente componente que se debe probar con el conjunto de componentes que ya están probados y se va incrementando progresivamente el número de componentes a probar.

6.3 PRUEBAS DE SISTEMA. Las pruebas de sistema buscan discrepancias entre el programa y

sus objetivos o requerimientos, enfocándose en los errores hechos durante la transición del proceso al diseñar la especificación funcional. Esto hace a las pruebas de sistema un proceso vital de pruebas, ya que, en términos del producto, número de errores hechos, y severidad de esos errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayoría de los errores.

Las pruebas del sistema tienen un propósito particular: para comparar el sistema o el programa con sus objetivos originales (Requerimientos funcionales y no funcionales).

6.3 PRUEBAS DE SISTEMA. Dado este propósito, se presentan dos implicaciones:

• Las pruebas de sistema no se limitan a los sistemas. Si el producto es un programa, la prueba del sistema es el proceso de procurar demostrar cómo el programa, en su totalidad, no resuelve sus objetivos o requerimientos.

• Las pruebas de sistema, por definición, son imposibles si no están los requerimientos por escrito, mensurables para el producto.

• Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integración del sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.

6.4 PRUEBAS DE ACEPTACIÓN.

El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.

6.4 PRUEBAS DE ACEPTACIÓN.

La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las verificaciones a realizar y los casos de prueba asociados.

Dicho plan está diseñado para asegurar que se satisfacen todos los requisitos funcionales especificados por el usuario teniendo en cuenta también los requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos y procesos, así como a los distintos recursos del sistema.

7.- ETAPAS INVOLUCRADAS EN LAS PRUEBAS DE SOFTWARE.

1. Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su objetivo, para qué exactamente se hace la prueba.

2. Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se va a utilizar para medir la calidad y qué clase de elementos de prueba se deben usar.

3. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de datos o situaciones de prueba que se utilizarán para ejecutar la unidad que se prueba o para revelar algo sobre el atributo de calidad que se está midiendo.

4. Determinar cuáles deberían ser los resultados esperados de los casos de prueba y crear el documento que los contenga.

5. Ejecutar los casos de prueba.

8.- EVALUACIÓN DE RESULTADOS

Comparar los resultados de la prueba con los resultados esperados.

Cualquier discrepancia entre ellos significa un error.

Típicamente el error está en el sistema o unidad probada, pero también puede ser generado por algún aspecto del mismo proceso de prueba.