¿Qué es la prueba de integración (tutorial con ejemplo de prueba de integración)?

what is integration testing

¿Qué son las pruebas de integración? Aprenda con ejemplos de pruebas de integración

Las pruebas de integración se realizan para probar los módulos / componentes cuando están integrados para verificar que funcionan como se espera, es decir, para probar los módulos que funcionan bien individualmente no tienen problemas cuando se integran.

Cuando se habla de pruebas de aplicaciones grandes utilizando la técnica de prueba de caja negra, implica la combinación de muchos módulos que están estrechamente acoplados entre sí. Podemos aplicar los conceptos de la técnica de prueba de integración para probar este tipo de escenarios.

Lista de tutoriales cubiertos en esta serie:

Tutorial #1: ¿Qué son las pruebas de integración? (Este tutorial)
Tutorial #2: ¿Qué son las pruebas incrementales?
Tutorial #3: ¿Qué es la prueba de componentes?
Tutorial #4: Integración continua
Tutorial #5 Diferencia entre pruebas unitarias e integración
Tutorial #6: Las 10 mejores herramientas de prueba de integración

Lo que vas a aprender:

• ¿Qué son las pruebas de integración?
• ¿Por qué prueba de integración?
• Ventajas
• Desafíos
• Tipos de pruebas de integración
  • Enfoque del Big Bang:
• Enfoques de integración de pruebas
  • Enfoque de abajo hacia arriba:
  • Enfoque de arriba hacia abajo
• Prueba de integración de la aplicación GUI
  • Ejemplo de prueba de integración:
• Pasos para iniciar las pruebas de integración
• Criterios de entrada / salida para pruebas de integración
• Casos de prueba de integración
• ¿Es la integración una técnica de caja blanca o caja negra?
• Herramientas de prueba de integración
• Prueba de integración del sistema
• Diferencia entre pruebas de integración y pruebas de sistemas
• Conclusión
• Lectura recomendada

¿Qué son las pruebas de integración?

El significado de las pruebas de integración es bastante sencillo: Integre / combine el módulo probado por unidad uno por uno y pruebe el comportamiento como una unidad combinada.

La función principal u objetivo de esta prueba es probar las interfaces entre las unidades / módulos.

Normalmente hacemos pruebas de integración después de las 'pruebas unitarias'. Una vez que se crean y prueban todas las unidades individuales, comenzamos a combinar esos módulos de 'Unidad probada' y comenzamos a hacer las pruebas integradas.

La función principal u objetivo de esta prueba es probar las interfaces entre las unidades / módulos.

Los módulos individuales se prueban primero de forma aislada. Una vez testeados unitariamente los módulos, se integran uno a uno, hasta integrar todos los módulos, para comprobar el comportamiento combinatorio y validar si los requisitos se implementan correctamente o no.

Aquí debemos entender que las pruebas de integración no ocurren al final del ciclo, sino que se llevan a cabo simultáneamente con el desarrollo. Entonces, en la mayoría de las veces, todos los módulos no están realmente disponibles para probar y aquí está el desafío de probar algo que no existe.

¿Por qué prueba de integración?

Creemos que las pruebas de integración son complejas y requieren cierto desarrollo y habilidad lógica. ¡Eso es cierto! Entonces, ¿cuál es el propósito de integrar estas pruebas en nuestra estrategia de pruebas?

He aquí algunas razones:

1. En el mundo real, cuando se desarrollan aplicaciones, se divide en módulos más pequeños y a los desarrolladores individuales se les asigna 1 módulo. La lógica implementada por un desarrollador es bastante diferente a la de otro desarrollador, por lo que es importante verificar si la lógica implementada por un desarrollador cumple con las expectativas y presenta el valor correcto de acuerdo con los estándares prescritos.
2. Muchas veces la cara o la estructura de los datos cambia cuando viajan de un módulo a otro. Algunos valores se agregan o eliminan, lo que causa problemas en los módulos posteriores.
3. Los módulos también interactúan con algunas herramientas de terceros o API que también deben probarse para comprobar que los datos aceptados por esa API / herramienta son correctos y que la respuesta generada también es la esperada.
4. Un problema muy común en las pruebas: cambio frecuente de requisitos. :) Muchas veces, los desarrolladores implementan los cambios sin probarlos por unidad. Las pruebas de integración se vuelven importantes en ese momento.

Ventajas

Hay varias ventajas de esta prueba y algunas de ellas se enumeran a continuación.

• Esta prueba asegura que los módulos / componentes integrados funcionen correctamente.
• Las pruebas de integración se pueden iniciar una vez que los módulos que se van a probar estén disponibles. No requiere que se complete el otro módulo para realizar las pruebas, ya que se pueden usar Stubs y Drivers para el mismo.
• Detecta los errores relacionados con la interfaz.

Desafíos

A continuación se enumeran algunos desafíos que están involucrados en la prueba de integración.

#1) La prueba de integración significa probar dos o más sistemas integrados para garantizar que el sistema funcione correctamente. No solo se deben probar los enlaces de integración, sino que se debe realizar una prueba exhaustiva teniendo en cuenta el entorno para garantizar que el sistema integrado funcione correctamente.

Puede haber diferentes rutas y permutaciones que se pueden aplicar para probar el sistema integrado.

#2) La gestión de las pruebas de integración se vuelve compleja debido a algunos factores involucrados, como la base de datos, la plataforma, el entorno, etc.

#3) Al integrar cualquier sistema nuevo con el sistema heredado, requiere muchos cambios y esfuerzos de prueba. Lo mismo se aplica al integrar dos sistemas heredados.

#4) La integración de dos sistemas diferentes desarrollados por dos compañías diferentes es un gran desafío, ya que no se sabe con certeza cómo uno de los sistemas afectará al otro sistema si se realizan cambios en cualquiera de los sistemas.

Para minimizar el impacto al desarrollar un sistema, se deben tener en cuenta pocas cosas como la posible integración con otros sistemas, etc.

Tipos de pruebas de integración

A continuación se muestra un tipo de integración de prueba junto con sus ventajas y desventajas.

Enfoque del Big Bang:

El enfoque de Big Bang integra todos los módulos de una vez, es decir, no se trata de integrar los módulos uno por uno. Verifica si el sistema funciona como se esperaba o no una vez integrado. Si se detecta algún problema en el módulo completamente integrado, resulta difícil averiguar qué módulo ha causado el problema.

El enfoque Big Bang es un proceso que requiere mucho tiempo para encontrar un módulo que tiene un defecto en sí mismo, ya que eso llevaría tiempo y una vez que se detecta el defecto, arreglarlo costaría mucho ya que el defecto se detecta en una etapa posterior.

Ventajas del enfoque Big Bang:

• Es un buen enfoque para sistemas pequeños.

Desventajas del enfoque Big Bang:

• Es difícil detectar el módulo que está causando el problema.
• El enfoque de Big Bang requiere todos los módulos todos juntos para realizar pruebas, lo que a su vez conduce a menos tiempo para las pruebas, ya que el diseño, el desarrollo y la integración tomarían la mayor parte del tiempo.
• Las pruebas se llevan a cabo de una sola vez, lo que no deja tiempo para las pruebas de módulos críticos de forma aislada.

Pasos de prueba de integración:

1. Preparar la integración Plan de prueba.
2. Prepare escenarios de prueba de integración y casos de prueba.
3. Prepare scripts de automatización de pruebas.
4. Ejecute casos de prueba.
5. Informe los defectos.
6. Realice un seguimiento y vuelva a probar los defectos.
7. La nueva prueba y prueba continúa hasta que se completa la prueba de integración.

Enfoques de integración de pruebas

Existen fundamentalmente 2 enfoques para realizar la integración de pruebas:

1. Enfoque de abajo hacia arriba
2. Enfoque de arriba hacia abajo.

Consideremos la siguiente figura para probar los enfoques:

Enfoque de abajo hacia arriba:

Las pruebas de abajo hacia arriba, como sugiere el nombre, comienzan desde la unidad más baja o más interna de la aplicación, y se mueven gradualmente hacia arriba. La prueba de integración comienza desde el módulo más bajo y progresa gradualmente hacia los módulos superiores de la aplicación. Esta integración continúa hasta que todos los módulos están integrados y toda la aplicación se prueba como una sola unidad.

En este caso, los módulos B1C1, B1C2 y B2C1, B2C2 son el módulo más bajo que se prueba por unidad. Los módulos B1 y B2 aún no están desarrollados. La funcionalidad del Módulo B1 y B2 es que llama a los módulos B1C1, B1C2 y B2C1, B2C2. Dado que B1 y B2 aún no están desarrollados, necesitaríamos algún programa o un 'estimulador' que llamará los módulos B1C1, B1C2 y B2C1, B2C2. Estos programas de estimulación se denominan CONDUCTORES .

En palabras simples CONDUCTORES son los programas ficticios que se utilizan para llamar a las funciones del módulo más bajo en un caso en el que la función de llamada no existe. La técnica ascendente requiere que el controlador del módulo alimente la entrada del caso de prueba a la interfaz del módulo que se está probando.

La ventaja de este enfoque es que, si existe una falla importante en la unidad más baja del programa, es más fácil detectarla y se pueden tomar medidas correctivas.

La desventaja es que el programa principal en realidad no existe hasta que se integra y se prueba el último módulo. Como resultado, las fallas de diseño de nivel superior se detectarán solo al final.

Enfoque de arriba hacia abajo

Esta técnica comienza desde el módulo superior y progresa gradualmente hacia los módulos inferiores. Solo el módulo superior se prueba por unidad de forma aislada. Después de esto, los módulos inferiores se integran uno a uno. El proceso se repite hasta que todos los módulos estén integrados y probados.

mejor programa para clonar un disco duro

En el contexto de nuestra figura, las pruebas comienzan desde el Módulo A y los módulos inferiores B1 y B2 se integran uno por uno. Ahora bien, aquí los módulos inferiores B1 y B2 no están realmente disponibles para la integración. Entonces, para probar los módulos superiores A, desarrollamos ' STUBS ”.

Los 'stubs' pueden denominarse código, un fragmento de código que acepta las entradas / solicitudes del módulo superior y devuelve los resultados / respuesta. De esta forma, a pesar de que los módulos inferiores no existen, podemos probar el módulo superior.

En escenarios prácticos, el comportamiento de los stubs no es tan simple como parece. En esta era de módulos y arquitectura complejos, el llamado módulo, la mayoría de las veces implica una lógica empresarial compleja, como conectarse a una base de datos. Como resultado, crear Stubs se vuelve tan complejo y lento como el módulo real. En algunos casos, el módulo Stub puede resultar más grande que el módulo estimulado.

Tanto los stubs como los controladores son un fragmento de código ficticio que se utiliza para probar los módulos 'no existentes'. Activan las funciones / método y devuelven la respuesta, que se compara con el comportamiento esperado

Concluyamos alguna diferencia entre Stubs y controlador :

El único cambio es constante en este mundo, por lo que tenemos otro enfoque llamado ' Prueba de sándwich ”Que combina las características del enfoque de arriba hacia abajo y de abajo hacia arriba. Cuando probamos programas enormes como los sistemas operativos, tenemos que tener algunas técnicas más que sean eficientes y aumenten la confianza. Las pruebas de sándwich juegan un papel muy importante aquí, donde las pruebas de arriba hacia abajo y de abajo hacia arriba se inician simultáneamente.

La integración comienza con la capa intermedia y se mueve simultáneamente hacia arriba y hacia abajo. En el caso de nuestra figura, nuestra prueba comenzará desde B1 y B2, donde un brazo probará el módulo superior A y otro brazo probará los módulos inferiores B1C1, B1C2 y B2C1, B2C2.

Dado que ambos enfoques comienzan simultáneamente, esta técnica es un poco compleja y requiere más personas junto con conjuntos de habilidades específicas y, por lo tanto, aumenta el costo.

Prueba de integración de la aplicación GUI

Ahora hablemos de cómo podemos implicar pruebas de integración en la técnica de caja negra.

Todos entendemos que una aplicación web es una aplicación de varios niveles. Tenemos una interfaz que es visible para el usuario, tenemos una capa intermedia que tiene lógica de negocios, tenemos una capa intermedia más que hace algunas validaciones, integra algunas API de terceros, etc., luego tenemos la capa posterior que es la base de datos.

Ejemplo de prueba de integración:

Veamos el siguiente ejemplo:

Soy propietario de una empresa de publicidad y publico anuncios en diferentes sitios web. Al final del mes, quiero ver cuántas personas vieron mis anuncios y cuántas personas hicieron clic en mis anuncios. Necesito un informe de mis anuncios mostrados y cobro en consecuencia a mis clientes.

Software GenNext desarrollé este producto para mí y a continuación estaba la arquitectura:

CEBOLLA - Módulo de interfaz de usuario, visible para el usuario final, donde se dan todas las entradas.
licenciado en Derecho - Es el módulo Business Logic, que tiene todos los cálculos y métodos específicos del negocio.
VAL - Es el módulo de Validación, que tiene todas las validaciones de la corrección de la entrada.
CNT - Es el módulo de contenido que tiene todos los contenidos estáticos, específicos de las entradas ingresadas por el usuario. Estos contenidos se muestran en los informes.
EN - Es el módulo Engine, este módulo lee todos los datos que provienen del módulo BL, VAL y CNT y extrae la consulta SQL y la dispara a la base de datos.
Programador - Es un módulo que programa todos los informes en función de la selección del usuario (mensual, trimestral, semestral y anual)
DB - Es la base de datos.

Ahora, habiendo visto la arquitectura de toda la aplicación web, como una sola unidad, las pruebas de integración, en este caso, se centrarán en el flujo de datos entre los módulos.

Las preguntas aquí son:

1. ¿Cómo leerán e interpretarán el módulo BL, VAL y CNT los datos ingresados ​​en el módulo UI?
2. ¿El módulo BL, VAL y CNT está recibiendo los datos correctos de la interfaz de usuario?
3. ¿En qué formato se transfieren los datos de BL, VAL y CNT al módulo EQ?
4. ¿Cómo leerá el EQ los datos y extraerá la consulta?
5. ¿La consulta se extrae correctamente?
6. ¿El Programador obtiene los datos correctos para los informes?
7. ¿El conjunto de resultados recibido por la EN de la base de datos es correcto y como se esperaba?
8. ¿EN puede enviar la respuesta al módulo BL, VAL y CNT?
9. ¿El módulo de la interfaz de usuario es capaz de leer los datos y mostrarlos adecuadamente en la interfaz?

En el mundo real, la comunicación de datos se realiza en formato XML. Entonces, cualquier dato que ingrese el usuario en la interfaz de usuario, se convierte a un formato XML.

En nuestro escenario, los datos ingresados ​​en el módulo UI se convierten en un archivo XML que es interpretado por los 3 módulos BL, VAL y CNT. El módulo EN lee el archivo XML resultante generado por los 3 módulos y extrae el SQL y realiza consultas en la base de datos. El módulo EN también recibe el conjunto de resultados y lo convierte en un archivo XML y lo devuelve al módulo UI que convierte los resultados en un formato legible por el usuario y lo muestra.

En el medio tenemos el módulo del programador que recibe el conjunto de resultados del módulo EN, crea y programa los informes.

Entonces, ¿dónde entra en juego la prueba de integración?

Bueno, probar si la información / datos fluye correctamente o no será su prueba de integración, que en este caso sería la validación de los archivos XML. ¿Se generan correctamente los archivos XML? ¿Tienen los datos correctos? ¿Los datos se están transfiriendo correctamente de un módulo a otro? Todas estas cosas se probarán como parte de las pruebas de integración.

Intente generar u obtener los archivos XML y actualice las etiquetas y verifique el comportamiento. Esto es algo muy diferente de las pruebas habituales que suelen hacer los probadores, pero esto agregará valor al conocimiento y comprensión de la aplicación por parte de los probadores.

Algunas otras condiciones de prueba de muestra pueden ser las siguientes:

• ¿Las opciones del menú generan la ventana correcta?
• ¿Pueden las ventanas invocar la ventana bajo prueba?
• Para cada ventana, identifique las llamadas de función para la ventana que la aplicación debería permitir.
• Identificar todas las llamadas desde la ventana a otras funciones que la aplicación debería permitir
• Identificar llamadas reversibles: cerrar una ventana llamada debería volver a la ventana de llamada.
• Identificar llamadas irreversibles: las ventanas de llamada se cierran antes de que aparezca la ventana llamada.
• Pruebe las diferentes formas de ejecutar llamadas a otra ventana, p. Ej. - menús, botones, palabras clave.

Pasos para iniciar las pruebas de integración

1. Comprenda la arquitectura de su aplicación.
2. Identificar los módulos
3. Comprender lo que hace cada módulo
4. Comprenda cómo se transfieren los datos de un módulo a otro.
5. Comprender cómo se ingresan y reciben los datos en el sistema (punto de entrada y punto de salida de la aplicación)
6. Separe la aplicación para que se adapte a sus necesidades de prueba.
7. Identificar y crear las condiciones de prueba.
8. Tome una condición a la vez y anote los casos de prueba.

Criterios de entrada / salida para pruebas de integración

Criterio para entrar:

• El documento del plan de prueba de integración está firmado y aprobado.
• Se han preparado casos de prueba de integración.
• Se han creado los datos de prueba.
• Examen de la unidad de módulos / componentes desarrollados está completo.
• Todos los defectos críticos y de alta prioridad están cerrados.
• El entorno de prueba está configurado para la integración.

Criterio de salida:

• Se han ejecutado todos los casos de prueba de integración.
• No se abren defectos críticos y de Prioridad P1 y P2.
• Se ha preparado el informe de prueba.

Casos de prueba de integración

Los casos de prueba de integración se centran principalmente en interfaz entre los módulos, enlaces integrados, transferencia de datos entre los módulos como módulos / componentes que ya están probados por unidad, es decir, la funcionalidad y los otros aspectos de prueba ya se han cubierto.

Entonces, la idea principal es probar si la integración de dos módulos de trabajo funciona como se esperaba cuando se integran.

Por ejemplo, los casos de prueba de integración para la aplicación Linkedin incluirán:

• Verificación del enlace de la interfaz entre la página de inicio de sesión y la página de inicio, es decir, cuando un usuario ingresa las credenciales y los registros, debe dirigirse a la página de inicio.
• Verificando el enlace de la interfaz entre la página de inicio y la página de perfil, es decir, la página de perfil debería abrirse.
• Verifique el enlace de la interfaz entre la página de red y sus páginas de conexión, es decir, al hacer clic en el botón Aceptar en Invitaciones de la página de red, se debe mostrar la invitación aceptada en su página de conexión una vez que se haga clic.
• Verifique el enlace de la interfaz entre las páginas de notificación y el botón de felicitaciones, es decir, al hacer clic en el botón de felicitaciones, debe dirigirse hacia la ventana del nuevo mensaje.

Se pueden escribir muchos casos de prueba de integración para este sitio específico. Los cuatro puntos anteriores son solo un ejemplo para comprender qué casos de prueba de integración se incluyen en las pruebas.

¿Es la integración una técnica de caja blanca o caja negra?

La técnica de prueba de integración se puede contar tanto en cajas negras como en técnica de caja blanca . Técnica de caja negra es donde un probador no necesita tener ningún conocimiento interno del sistema, es decir, no se requiere conocimiento de codificación, mientras que la técnica de caja blanca necesita conocimiento interno de la aplicación.

Ahora, mientras realiza las pruebas de integración, podría incluir probar los dos servicios web integrados que obtendrán los datos de la base de datos y proporcionarán los datos según sea necesario, lo que significa que podría probarse utilizando la técnica de prueba de caja blanca, mientras que la integración de una nueva función en el sitio web se puede probar. utilizando la técnica de la caja negra.

Por lo tanto, no es específico que las pruebas de integración sean una técnica de caja negra o caja blanca.

Herramientas de prueba de integración

Hay varias herramientas disponibles para esta prueba.

A continuación se muestra una lista de herramientas:

• Probador de integración racional
• Transportador
• Vapor
• TESSY

Para obtener más detalles sobre las herramientas anteriores, consulte este tutorial:

Las 10 mejores herramientas de prueba de integración para escribir pruebas de integración

Prueba de integración del sistema

La prueba de integración del sistema se realiza para probar el sistema integrado completo .

Los módulos o componentes se prueban individualmente en pruebas unitarias antes de integrar los componentes.

Una vez que se prueban todos los módulos, se realiza la prueba de integración del sistema integrando todos los módulos y se prueba el sistema en su conjunto.

Diferencia entre pruebas de integración y pruebas de sistemas

La prueba de integración es una prueba en la que uno o dos módulos que se prueban en la unidad se integran para probar y se realiza la verificación para verificar si los módulos integrados funcionan como se espera o no.

La prueba del sistema es una prueba en la que sistema como un todo se prueba, es decir, todos los módulos / componentes se integran juntos para verificar si el sistema funciona como se esperaba y no ocurren problemas debido a los módulos integrados.

Conclusión

Se trata de pruebas de integración y su implementación tanto en la técnica de caja blanca como en la de caja negra. Espero que lo hayamos explicado claramente con ejemplos relevantes.

La integración de pruebas es una parte importante del ciclo de pruebas, ya que facilita la búsqueda del defecto cuando se integran dos o más módulos para integrar todos los módulos juntos en el primer paso.

Ayuda a encontrar los defectos en una etapa temprana, lo que a su vez también ahorra esfuerzo y costo. Asegura que los módulos integrados funcionen correctamente como se espera.

Espero que este tutorial informativo sobre pruebas de integración haya enriquecido su conocimiento del concepto.

Lectura recomendada

• ¿Qué son las pruebas de componentes o las pruebas de módulos? (Aprenda con ejemplos)
• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• Spock para pruebas funcionales y de integración con selenio
• Las diferencias entre pruebas unitarias, pruebas de integración y pruebas funcionales
• Integración de selenio con JMeter
• Descarga del libro electrónico Testing Primer
• Pruebas funcionales versus pruebas no funcionales
• Tutorial de pruebas por pares o pruebas de todos los pares con herramientas y ejemplos