PRUEBA DE INTEGRACIÓN
La prueba de integración es una técnica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción.
Integración descendente
Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el módulo de control principal (programa principal). Los módulos subordinados al módulo de control principal se van incorporando en la estructura, bien de forma primero en profundidad, o bien de forma primero en anchura.
· Integración primero en profundidad: integra todos los módulos de un camino de control principal de la estructura.
Por ejemplo, si se elige el camino de la izquierda se integrarán primero los módulos M1, M2 y M5. A continuación, se integrará M8 o M6. A continuación se construyen los caminos de control central y derecho.
· Integración primero en anchura: incorpora todos los módulos directamente subordinados a cada nivel, moviéndose por la estructura de forma horizontal.
Por ejemplo: Los primeros módulos que se integran son M2, M3 y M4. A continuación, sigue el siguiente nivel de control, M5, M6, M7 y por último M8.
El proceso de integración se realiza en cinco pasos:
1. Se usa el módulo de control principal como controlador de la prueba, disponiendo de resguardos para todo los módulos directamente subordinados al módulo de control principal.
2. Dependiendo del enfoque de integración elegido se van sustituyendo uno a uno los resguardos subordinados por los módulos reales.
1. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.
2. Tras terminar cada conjunto de prueba, se reemplaza otro resguardo con el módulo real.
3. Se hace la prueba de regresión para asegurarse de que no se han introducido errores nuevos.
El proceso continúa desde el paso dos hasta que se haya construido la estructura del programa entero.
Integración ascendente
Empieza la construcción y la prueba con los niveles más bajos de la estructura del programa. Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponible y se elimina la necesidad de resguardos.
Se puede implementar una estrategia de integración ascendente mediante los siguientes pasos:
1. Se combina los módulos de bajo nivel en grupos que realicen una subfunción específica 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 moviéndose hacia arriba por la estructura del programa.
La integración sigue el esquema de la siguiente figura:
Se combinan los módulos 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 módulos 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 integración con el módulo Mb. Tanto Ma como Mb se integraran finalmente con el módulo Mcy así sucesivamente.
Prueba de regresión
La prueba de regresión 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 regresión es la actividad que ayuda a asegurar que los cambios no introducen un comportamiento no deseado o errores adicionales.
El conjunto de pruebas de regresión 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 diseñado como un mecanismo para proyectos críticos por tiempo, permitiendo que el equipo de software valore su proyecto sobre una base sólida. La prueba de humo comprende las siguientes actividades:
1. Los componentes software que han sido traducidos al código se integran en una “construcción”. Una construcción incluye fichas de datos, librerías, módulos reutilizables y componentes de ingeniería que se requieren para implementar una o más funciones del producto.
2. Se diseña una serie de pruebas para descubrir errores que impiden a la construcción realizar su función adecuadamente. El objetivo será descubrir errores “bloqueantes” que tengan la mayor probabilidad de impedir al proyecto de software el cumplimiento de su planificación.
3. Es habitual en la prueba de humo que la construcción se integre con otras construcciones y que se aplica una prueba de humo al producto completo. La integración puede hacerse bien de forma descendente o ascendente.
La prueba de humo facilita una serie de beneficios cuando se aplica sobre proyectos de ingeniería de software complejos y críticos por su duración:
o Se minimiza los riesgos de integración.
o Se perfecciona la calidad del producto final.
o Se simplifican el diagnóstico y la corrección de errores.
o El progreso es fácil de observar.
PRUEBA DE VALIDACIÓN
La validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. La validación 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 |
Prueba Beta |
|
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. |
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 aplicación 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 versión del producto de software para toda la clase de clientes |
PRUEBA DEL SISTEMA
Su propósito 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 recuperación |
|
Esta prueba fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. |
|
Prueba de seguridad |
|
Intenta verificar que los mecanismos de protección incorporadas en el sistema lo protegerán, de hecho, de accesos impropios. |
|
Prueba de resistencia (stress) |
|
Ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales. Por ejemplo:
1. Diseñar pruebas especiales que generen 10 interrupciones por segundo, cuando las normales son una o dos; 2. Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada. 3. Ejecutar casos de prueba que requieran el máximo de memoria o de otros recursos. 4. Diseñar casos de prueba que puedan dar problemas en un sistema operativo virtual. 5. Diseñar casos de prueba que produzcan excesivas búsquedas de datos residentes en disco.
Esencialmente, el responsable de la prueba intenta romper el programa. |
|
Prueba de rendimiento |
|
Permite probar el rendimiento del software en tiempo de ejecución 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. |
DEPURACIÓN
La depuración ocurre como consecuencia de una prueba efectiva. Cuando un caso de prueba descubre un error, la depuración es el proceso que provoca la eliminación del error.
El proceso de depuración comienza con la ejecución de un caso de prueba. Se evalúan los resultados y aparece una falta de correspondencia entre los esperados y los encontrados realmente. El proceso de depuración intenta hacer corresponder el sistema con una causa, llevando así a la corrección del error.
El proceso de depuración siempre tiene uno de los dos resultados siguientes:
1. Se encuentra la causa, se corrige y se elimina.
2. No se encuentra la causa.
En este último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrás a la corrección del error de una forma interativa.
Durante la depuración se encuentran errores que van desde lo ligeramente inesperado hasta lo catastrófico.
La depuración tiene el objetivo primordial de encontrar y corregir la causa de un error en el software.