TIPOS DE PRUEBAS

PRUEBA DE INTEGRACIN La prueba de integracin es una tcnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin.

Integracin descendente Se integran los mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal (programa principal). Los mdulos subordinados al mdulo de control principal se van incorporando en la estructura, bien de forma primero en profundidad, o bien de forma primero en anchura.

Integracin primero en profundidad: integra todos los mdulos de un camino de control principal de la estructura. Por ejemplo, si se elige el camino de la izquierda se integrarn primero los mdulos M1, M2 y M5. A continuacin, se integrar M8 o M6. A continuacin se construyen los caminos de control central y derecho.

 Integracin primero en anchura: incorpora todos los mdulos directamente subordinados a cada nivel, movindose por la estructura de forma horizontal. Por ejemplo: Los primeros mdulos que se integran son M2, M3 y M4. A continuacin, sigue el siguiente nivel de control, M5, M6, M7 y por ltimo M8.

El proceso de integracin se realiza en cinco pasos:

1. Se usa el mdulo de control principal como controlador de la prueba, disponiendo de resguardos para todo los mdulos directamente subordinados al mdulo de control principal. 2. Dependiendo del enfoque de integracin elegido se van sustituyendo uno a uno los resguardos subordinados por los mdulos reales. 1. Se llevan a cabo pruebas cada vez que se integra un nuevo mdulo. 2. Tras terminar cada conjunto de prueba, se reemplaza otro resguardo con el mdulo real. 3. Se hace la prueba de regresin para asegurarse de que no se han introducido errores nuevos.

El proceso contina desde el paso dos hasta que se haya construido la estructura del programa entero.

Integracin ascendente

Empieza la construccin y la prueba con los niveles ms bajos de la estructura del programa. Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados siempre est disponible y se elimina la necesidad de resguardos.

Se puede implementar una estrategia de integracin ascendente mediante los siguientes pasos: 1. Se combina los mdulos de bajo nivel en grupos que realicen una subfuncin especfica del software. 2. se describe un controlador (un programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba. 3. Se prueba el grupo. 4. Se eliminan los controladores y se combinan los grupos movindose hacia arriba por la estructura del programa.

La integracin sigue el esquema de la siguiente figura:

Se combinan los mdulos para formar los grupos 1,2 y 3. Cada uno de los grupos se somete a prueba mediante un controlador (mostrado como un bloque punteado). Los mdulos de los grupos 1 y 2 son subordinados Ma. Los

controladores D1 y D2 se eliminan y los grupos interaccionan directamente con Ma. De forma similar, se elimina el controlador D3 del grupo 3 antes de la integracin con el mdulo Mb. Tanto Ma como Mb se integraran finalmente con el mdulo Mc y as sucesivamente.

Prueba de regresin La prueba de regresin consiste en volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados. La prueba de regresin es la actividad que ayuda a asegurar que los cambios no introducen un comportamiento no deseado o errores adicionales. El conjunto de pruebas de regresin contiene tres clases diferentes de casos de prueba: o Una muestra representativa de pruebas que ejercite todas las funciones del software; o Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio; o Pruebas que se centran en los componentes del software que han cambiado.

Prueba de humo Esta prueba es utilizada cuando se ha desarrollado un producto software empaquetado. Es diseado como un mecanismo para proyectos crticos por tiempo, permitiendo que el equipo de software valore su proyecto sobre una base slida. La prueba de humo comprende las siguientes actividades:

1. Los componentes software que han sido traducidos al cdigo se integran en una construccin. Una construccin incluye fichas de datos, libreras, mdulos reutilizables y componentes de ingeniera que se requieren para implementar una o ms funciones del producto. 2. Se disea una serie de pruebas para descubrir errores que impiden a la construccin realizar su funcin adecuadamente. El objetivo ser descubrir errores bloqueantes que tengan la mayor probabilidad de impedir al proyecto de software el cumplimiento de su planificacin.

3. Es habitual en la prueba de humo que la construccin se integre con otras construcciones y que se aplica una prueba de humo al producto completo. La integracin puede hacerse bien de forma descendente o ascendente. La prueba de humo facilita una serie de beneficios cuando se aplica sobre proyectos de ingeniera de software complejos y crticos por su duracin: o Se minimiza los riesgos de integracin. o Se perfecciona la calidad del producto final. o Se simplifican el diagnstico y la correccin de errores. o El progreso es fcil de observar.

PRUEBA DE VALIDACIN La validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. La validacin del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Se llevan a cabo dos pruebas: Prueba Alfa Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas Alfa se llevan a cabo en un entorno controlado. Prueba Beta Se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. El desarrollador no est presente en esta prueba. La prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que encuentran durante la prueba e informa al desarrollador. Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y as prepara una versin del producto de software para toda la clase de clientes

PRUEBA DEL SISTEMA Su propsito primordial es ejercitar profundamente el sistema, verificando que se hayan integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. Comprende las siguientes pruebas: Prueba de recuperacin Esta prueba fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente.

Prueba de seguridad Intenta verificar que los mecanismos de proteccin incorporadas en el sistema lo protegern, de hecho, de accesos impropios.

Prueba de resistencia (stress) Ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo:

1. 2.

Disear pruebas especiales que generen 10 interrupciones por segundo, cuando las normales son una o dos; Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo responden las funciones de entrada. Ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos. Disear casos de prueba que puedan dar problemas en un sistema operativo virtual. Disear casos de prueba que produzcan excesivas bsquedas de datos residentes en disco.

3. 4. 5.

Esencialmente, el responsable de la prueba intenta romper el programa.

Prueba de rendimiento Permite probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proceso de la prueba. Para llevar a cabo esta prueba, deben estar integrados completamente todos elementos del sistema.