UNIDAD 3. DISEO Y REALIZACIN DE PRUEBAS

1. PLANIFICACIN DE PRUEBAS.

2. TIPOS DE PRUEBAS.

3. PROCEDIMIENTOS Y CASOS DE PRUEBA.

4. HERRAMIENTAS DE DEPURACIN.

5. VALIDACIONES.

6. PRUEBAS DE CDIGO.

7. NORMAS DE CALIDAD.

8. PRUEBAS UNITARIAS.

9. AUTOMATIZACIN DE LA PPRUEBA.

10. DOCUMENTACIN DE LA PRUEBA.

11. PLANIFICACIN DE LAS PPRUEBAS

Durante el proceso de desarrollo de software (Diseo, Implementacin y Mantenimiento) se necesario realizar un conjunto de pruebas para verificar que el software creado es correcto y cumple con las especificaciones (anlisis) del usuario.

Pruebas: Proceso para verificar y mostrar la calidad del software. Se utilizan para identificar posibles fallos de implementacin, calidad o usabilidad de un programa.

Mediante la realizacin de pruebas se realizan tareas de:

Verificacin: Comprueba que el software cumple los requisitos especificados.

Validacin: Comprueba que el software hace lo que el usuario deseaba. Debe estar verificado.

Ejemplo: Siguiendo un modelo en espiral las pruebas siguen las pautas.

1. Pruebas de unidad: Se analiza el cdigo especificado.

2. Prueba de integracin: Se mira el diseo y la construccin de la arquitectura del software.

3. Prueba de validacin: Se comprueba que el sistema cumple con lo establecido en el anlisis de requisitos de software.

4. Prueba del sistema: Se verifica el funcionamiento total del software y otros elementos del sistema.

2. TIPOS DE PRUEBAS

En la ingeniera del software tenemos 2 enfoques:

Pruebas de caja negra: Se prueba la interfaz externa de la aplicacin, es decir, los resultados de ejecutar la aplicacin son los esperados, en funcin de las entradas recibidas. Solo se conocen las entradas y las salidas de la aplicacin.

Pruebas de caja blanca: Se prueba internamente la aplicacin, usando su lgica. Se analiza y prueba el cdigo de la aplicacin, se debe conocer el cdigo para analizar los resultados.

Tipos de pruebas software:

Pruebas de unidad: Se prueba el funcionamiento de un mdulo.

Pruebas de carga: Comportamiento de la aplicacin bajo una cantidad de peticiones. P

Prueba de estrs: Se doblega el n de usuarios a la aplicacin y se ejecuta la prueba. U

Prueba de estabilidad: Determina si una aplicacin puede con una carga continuada. M

Pruebas de picos: Se vara el n de usuarios.

Prueba estructural: Analiza las rutas de ejecucin.

Prueba funcional: Entradas y salidas que producen las funciones.

Pruebas aleatorias: Se usan modelos para representar las posibles entradas.

Pruebas de regresin: Cualquier tipo de pruebas software para descubrir errores.

2.1. PRUEBAS FUNCIONALES (CAJA NEGRA).

Son actividades cuyo objetivo es verificar una accin funcional o especifica dentro del cdigo de una aplicacin.

En este tipo de pruebas se analizan las entradas y las salidas de cada componente, verificando que el resultado es el esperado. Solo se consideran las entradas y las salidas del sistema.

No se consideran: el cdigo desarrollado, el algoritmo, la eficiencia, las partes de cdigo innecesarias.

Las pruebas funcionales indicamos 3 tipos de pruebas:

Particiones equivalentes: Considera el menor n posible de casos de prueba, cada una con el mayor n posible de entradas diferentes.

Anlisis de valores limite: El caso de prueba se elige con valores de entrada en el limite de las clases de equivalencia.

Pruebas aleatorias: El caso de prueba utiliza generadores de prueba para generar un gran volumen de casos de prueba al azar, es decir, se generan entradas aleatorias para la aplicacin que hay que probar.

2.2. PRUEBAS ESTRUCTURALES (CAJA BLANCA)

Se fijan en los caminos a recorrer, para ver como el programa se ejecuta y as comprobar su correccin.

Se quiere verificar la estructura interna de cada componente de la aplicacin ejecucin de todas las instrucciones del programa, que todo cdigo sea usado, que los caminos lgicos se recorren, etc. -, con independencia de la funcionalidad.

No se considerarn: La correccin del resultado producido por los componentes internos.

Los criterios de cobertura son:

Cobertura de sentencias: Casos de prueba suficientes para que todas las instrucciones se ejecuten al menos una vez.

Cobertura de decisiones: Crear suficientes casos de prueba para que cada opcin resultado de una prueba lgica se evale al menos una vez a cierto y otra a falso.

Cobertura de condiciones: Crear suficientes casos de prueba para que cada elemento de una condicin, se evale la menos una vez a cierto y otra a falso.

Cobertura de condiciones y decisiones: cumple a la vez las dos anteriores.

Cobertura de caminos: Ejecutar al menos una vez cada secuencia de sentencias encadenadas desde la sentencia inicial hasta su sentencia final.

Cobertura del camino de prueba: Una variante que indica que cada bucle se debe ejecutar solo una vez y otra que aconseja que se pruebe cada bucle tres veces.

2.3. REGRESIN

Las pruebas software con xito, dan como resultado el descubrimiento de errores o fallos. La consecuencia es la modificacin del componente donde se ha detectado, pudiendo generar errores colaterales lo que nos obliga a repetir las pruebas.

Una prueba de regresin: comprueba que los cambios de un elemento de la aplicacin y que no introduce un comportamiento no deseado o errores adicionales en otros elementos.

Estas pruebas se deben realizar cada vez que hay un cambio en el sistema -corregir errores o mejoras-. Adems, de probar los elementos modificados/aadidos/funciones que realizan, se debe controlar no produzcan efectos negativos sobre otros elementos.

El conjunto de pruebas de regresin contiene 3 clases de prueba:

Pruebas que ejerciten todas las funciones del software,

Pruebas en las funciones que se van a ver afectadas por el cambio y

Pruebas en los componentes que han cambiado.

Las pruebas de regresin se disean para incluir solo aquellas que traten una o mas clases de errores en cada una de las funciones principales del programa.

3. PROCEDIMIENTOS Y CASOS DE PRUEBA

Un caso de prueba segn IEEE es un conjunto de entradas, condiciones de ejecucin y resultados esperados, desarrollados para un objetivo particular.

en el diseo de los casos de prueba, siempre es necesario asegurar que con ellos se obtiene un nivel aceptable de probabilidad de que se detectarn los errores existentes.

Las pruebas deben buscar un compromiso entre la cantidad de recursos que se consumirn en el proceso de prueba, y la probabilidad obtenida de que se detecten los errores existentes.

Procedimientos para el diseo de los casos de prueba:

Enfoque funcional o de caja negra.

Enfoque estructural o de caja blanca.

Enfoque aleatorio.

4. HERRAMIENTAS DE DEPURACIN

Cada IDE incluye una serie de herramientas de depuracin (como puntos de ruptura, ejecucin paso a paso de cada instruccin, ejecucin por procedimiento, inspeccin de variables), que permiten verificar el cdigo generado, ayudndonos a realizar pruebas tanto estructurales como funcionales.

Los tipos de errores pueden ser: errores lgicos o de compilacin.

De compilacin: El IDE proporciona informacin de donde se produce y como solucionarlo. El programa no se compila hasta que el programador no lo corrija.

Lgicos o bugs: El programa se compila con xito no hay errores sintcticos-, pero pueden provocar que el programa devuelva resultados no deseados, errneos o que provoquen que el programa termine antes de tiempo o no termine nunca.

Depurador: Supervisa la ejecucin de un programa para localizar y eliminar errores lgicos.

El depurador permite analizar el programa mientras se ejecuta: examinar y establecer los valores de las variables, suspender la ejecucin del programa, comprobar los valores devueltos por un mtodo, el resultado de una comparaci logica o relacional, etc.

4.1. PUNTOS DE RUPTURA

Se selecciona la lnea de cdigo donde queramos que el programa se pare, para a partir de ella, inspeccionar variables, o realizar una ejecucin paso a paso, para verificar la correccin del cdigo.

Los puntos de ruptura son marcadores en cualquier lnea de cdigo. Una vez insertado el punto de ruptura, e iniciada la depuracin, el programa a evaluar se ejecutara hasta la lnea marcada con el punto de ruptura.

4.2. TIPOS DE EJECUCIN

Para la depuracin se puede ejecutar un programa de diferentes formas.

Tipos de ejecucin:

Paso a paso o lnea a lnea para buscar y corregir errores: Ayuda a verificar que el cdigo de un mtodo se ejecuta de forma correcta.

Paso a paso por procedimiento: Nos permite introducir los parmetros que queramos a un mtodo o funcin, para que ese mtodo nos devuelva su resultado. Interesa su salida.

Ejecucin hasta una instruccin: El depurador ejecuta el programa y se detiene en la instruccin donde se encuentra el cursor, en ese punto, se puede seguir otro tipo de ejecucin.

Ejecucin de un programa hasta el final: Ejecuta las instrucciones de un programa hasta el final, sin detenernos en las instrucciones intermedias.

Los tipos de ejecucin se ajustarn a las necesidades de depuracin de cada momento. Si hemos probado un mtodo y sabemos que funciona correctamente, no es necesario realizar una ejecucin paso a paso en l.

4.3. EXAMINADORES DE VARIABLES

Una vez iniciado el proceso de depuracin, en general con la ejecucin paso a paso, el programa avanza instruccin por instruccin. Al mismo tiempo, las variables, toman diferentes valores.

Permiten comprobar los distintos valores que adquieren las variables, as como su tipo.

Netbeans tiene un panel llamado ventana de inspeccin, donde se agregan todas aquellas variables en las que haya inters inspeccionar su valor.

Los depuradores son programas que permiten analizar de manera exhaustiva y paso a paso, lo que pasa dentro del cdigo de un programa.

DEPURACIN EN NETBEANS

EJEMPLO: Programa que dispone de una clase vector que implementa algunos mtodos como insertar y ordenar

INICIO DE LA DEPURACIN:

LA DEPURACIN: