En las pruebas de integración se examinan las interfaces entre grupos de componentes o subsistemas para asegurar que
son llamados cuando es necesario y que los datos o mensajes que se transmiten son los requeridos.
Debido a que en las pruebas unitarias es necesario crear módulos auxiliares que simulen las acciones de los componentes
invocados por el que se está probando y a que se han de crear componentes "conductores" para establecer las
precondiciones necesarias, llamar al componente objeto de la prueba y examinar los resultados de la prueba, a menudo se
combinan los tipos de prueba unitarias y 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. Con
el tipo de prueba incremental lo más probable es que los problemas que surjan al incorporar un nuevo componente
o un grupo de componentes previamente probado, sean debidos a este último o a las interfaces entre éste y los
otros componentes.
-
Integración no incremental: Se prueba cada componente por separado y posteriormente se integran
todos de una vez realizando las pruebas pertinentes. Este tipo de integración se denomina también
Big-Bang (gran explosión).
En la integración incremental de componentes (ver figura anterior) se distinguen las siguientes estrategias de
integración:
-
De arriba abajo (top-down). El primer componente que se desarrolla y prueba es el primero de la
jerarquía (A). Los componentes de nivel más bajo se sustituyen por componentes auxiliares para simular a los
componentes invocados. En este caso no son necesarios componentes conductores. Una de las ventajas de aplicar
esta estrategia es que las interfaces entre los distintos componentes se prueban en una fase temprana y con
frecuencia.
-
De abajo arriba (bottom-up). En este caso se crean primero los componentes de más bajo nivel (E,
F) y se crean componentes conductores para simular a los componentes que los llaman. A continuación se
desarrollan los componentes de más alto nivel (B, C, D) y se prueban. Por último dichos componentes se combinan
con el que los llama (A). Los componentes auxiliares son necesarios en raras ocasiones.
Este tipo de enfoque permite un desarrollo más en paralelo que el enfoque de arriba abajo, pero presenta
mayores dificultades a la hora de planificar y de gestionar.
-
Estrategias combinadas. A menudo es útil aplicar las estrategias anteriores conjuntamente. De este modo,
se desarrollan partes del sistema con un enfoque "top-down", mientras que los componentes más críticos
en el nivel más bajo se desarrollan siguiendo un enfoque "bottom-up". En este caso es necesaria una
planificación cuidadosa y coordinada de modo que los componentes individuales se "encuentren" en el
centro.
|