Pruebas De Integracion Y Validacion

INTRODUCCIÓN:

El término integración se refiere a las actividades de desarrollo de producto software donde se combinan componentes de software separados en un único sistema. El esfuerzo destinado a la integración de producto puede oscilar entre unas horas y varios meses, dependiendo del tamaño del producto. La integración conlleva la prueba del componente integrado como un todo y la corrección de los defectos encontrados.

La necesidad de realizar las pruebas de integración viene dada por el hecho de que los módulos que forman un programa suelen fallar cuando trabajan de forma conjunta, aunque previamente se haya demostrado que funcionan correctamente de manera individual. Por ello realizamos este tipo de pruebas, asegurándonos que los módulos que están relacionados ejecuten correctamente.

Con el uso de estas pruebas conseguimos ir formando el programa global a medida que se comprueba como los distintos componentes interaccionan y se comunican libres de errores.

PRUEBAS INTEGRALES O PRUEBAS DE INTEGRACIÓN:

Es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con el que dicta el diseño.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Las pruebas de integración (algunas veces llamadas integración y testeo I&t) es la fase del prueba de software en la cual módulos individuales de software son combinados y probados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden a las pruebas del sistema.

ALCANCES DE LAS PUEBAS DE INTEGRACIÓN:

El propósito de estas pruebas es descubrir los defectos de las interconexiones y de la interacción entre sistemas o componentes integrados. Puede haber más de un nivel de integración y las pruebas pueden realizarse sobre objetos de tamaño variable. Por ejemplo:

 Las pruebas de integración de componentes prueban la interconexión entre componentes de software, y se ejecutan después de las pruebas unitarias. Este tipo de pruebas de integración las realizan los desarrolladores.

 Las pruebas de integración de sistemas prueban la interconexión entre distintos sistemas y se ejecutan después de las pruebas de sistema de cada sistema individual. Este tipo de pruebas de integración las realizan técnicos de pruebas.

ESTRATEGIAS DE INTEGRACIÓN INCREMENTAL:

Antes de realizar cualquier prueba de integración, es necesario establecer una estrategia y decidir cómo unir las distintas partes de un sistema.

La integración incremental requiere una buena planificación de la secuencia de integración. La mayoría de los sistemas integran unos componentes antes que otros. La planificación de esta integración también afecta a la planificación de la construcción (desarrollo); el orden en que se construyen los componentes tiene que soportar el orden en que se van a integrar.

A continuación, se describen algunas de las estrategias estándar para la integración incremental:

1. INTEGRACIÓN TOP-DOWN:

El sistema se construye por fases empezando por los componentes que llaman a otros componentes.

A medida que se integran los módulos, se realizan pruebas de regresión para capturar y corregir nuevos errores.

Ventajas:

 La lógica de control del sistema se prueba relativamente pronto.

 Los grandes problemas conceptuales de diseño se identifican rápidamente.

 Se puede obtener un sistema que funcione parcialmente en un momento temprano del proyecto.

 La codificación puede comenzar antes de que los detalles de diseño a bajo nivel estén completos.

Inconvenientes:

 Los problemas de interfaces a bajo nivel se detectan tarde.

 Gran número de stubs a mantener.

 No se puede aplicar en diseños orientados a objetos y sistemas interactivos.

2. INTEGRACIÓN BOTTOM-UP

Los componentes se integran en el sentido contrario al caso anterior, primero los componentes que son llamados por otros.

Ventajas:

 Ejecuta interfaces a bajo nivel potencialmente problemáticas en un momento temprano.

Inconvenientes

 Problemas conceptuales de diseño a alto nivel se detectan tarde. Corregir esos problemas puede implicar desechar o realizar mucho re-trabajo en módulos a bajo nivel.

 Requiere que el diseño de todo el sistema esté completo antes de comenzar la integración.

3. INTEGRACIÓN SANDWICH

Primero, se integran los módulos de alto nivel y de control. Después, los módulos de bajo nivel. La integración de los módulos de nivel intermedio se hace al final.

Ventajas:

 Evita la rigidez de las integraciones top-down y bottom-up.

 Integra los módulos más problemáticos primero y permite minimizar los drivers y stubs.

4. INTEGRACIÓN ORIENTADA A RIESGOS

Se identifica el nivel de riesgo asociado a cada módulo. Los módulos de riesgo alto se integran primero y los módulos de menor riesgo se integran más tarde.

Ventajas:

 Evita la rigidez de las integraciones top-down y bottom-up.

 Integra los módulos más problemáticos primero y permite minimizar los drivers y stubs.

5. INTEGRACIÓN ORIENTADA A FUNCIONALIDADES

Los módulos se integran en grupos que constituyen una funcionalidad identificada.

Ventajas:

 Minimiza el uso de drivers y stubs.

 Cada grupo nuevo integrado proporciona un incremento en funcionalidad.

 Funciona bien para sistemas orientados a objetos.

BUENAS PRÁCTICAS:

La secuencia y número de pasos requeridos en la integración dependen de la ubicación de las interconexiones de alto riesgos dentro de la arquitectura. La mejor opción es empezar la integración por aquellas conexiones que se espera que causen mayores problemas. De esta forma, se evitan encontrar los mayores defectos al final de la etapa de pruebas de integración. Con el objetivo de reducir este riesgo es aconsejable no usar la integración Big-bang.

También se recomienda que las personas que lleven a cabo las pruebas entiendan la arquitectura y realicen

...