Introducción a las pruebas de integración en Java
- Introducción a las pruebas de integración
- Importancia de las pruebas de integración
- Tipos de pruebas de integración
- Pasos necesarios para las pruebas de integración
Este tutorial presenta las pruebas de integración y destaca cómo podemos diferenciarlas de las pruebas unitarias. Además, analiza varios tipos de pruebas de integración, considerando sus ventajas y desventajas.
Luego, aprenderemos sobre los pasos necesarios para realizar pruebas de integración, seguidos de un escenario del mundo real para comprender las pruebas de integración.
Introducción a las pruebas de integración
Hay tres tipos de pruebas en pirámide de pruebas: pruebas unitarias, pruebas de integración y pruebas funcionales. Este artículo girará en torno a las pruebas de integración, lo que significa que comprobamos si varios módulos funcionan como se espera cuando los combinamos como grupo.
Recuerde, el software consta de varios módulos que han codificado varios programadores. Aquí, el objetivo principal de las pruebas de integración es probar una interfaz entre dos o varios módulos de software integrándolos lógicamente y probándolos como un grupo.
Además, determina la corrección de una interfaz al exponer defectos en una interacción entre varios componentes de software cuando los integramos. El proceso de prueba de integración comienza una vez que todos los componentes de software se han sometido a pruebas unitarias.
Consulte lo siguiente para visualizar las pruebas unitarias y las pruebas de integración.
Los siguientes son algunos puntos para resaltar cómo las pruebas de integración difieren de las pruebas unitarias.
| Examen de la unidad | Pruebas de integración |
|---|---|
| Aquí, el desarrollador es muy consciente del diseño interno del software. | Aquí, el probador no conoce el diseño interno del software. |
| Cada módulo se prueba por separado. | Combinamos todos los módulos y probamos como grupo. |
| Se llama prueba de caja blanca. | Se conoce como prueba de caja negra. |
| Lo hace un desarrollador. | Lo hace un probador. |
| Encontrar defectos es fácil aquí. | Exponer defectos es difícil en las pruebas de integración. |
| En las pruebas unitarias, todos los componentes del proyecto se prueban de forma individual e independiente sin esperar a que se completen otros componentes. | La prueba de integración se realiza una vez que se completan todas las partes. |
| Es rentable. El mantenimiento también es menos costoso. | Es caro. El mantenimiento también es costoso. |
| La especificación del módulo se realiza inicialmente. | La especificación de la interfaz se realiza al principio. |
| Se trata de explorar el código en profundidad. | Se trata de una visibilidad detallada de la estructura de integración. |
| Ejecución más rápida que las pruebas de integración. | Aquí, la velocidad es comparativamente lenta debido a la integración de módulos. |
Puedes encontrar más sobre esto aquí.
Importancia de las pruebas de integración
Aunque cada componente de software se somete a pruebas unitarias, aún se pueden exponer defectos por varias razones, lo que aumenta la importancia de las pruebas de integración. Algunos de ellos se enumeran a continuación.
- Permite una mejor integración de los módulos de software.
- Mediante el uso de pruebas de integración, podemos evitar modificaciones en los datos durante las transferencias de módulos de software.
- También supera varios problemas de prueba manual.
- Las pruebas de integración también permiten pruebas efectivas de terceros.
- Se requiere verificar que todos los componentes de software funcionen en una unidad y produzcan el resultado esperado.
- Es útil encontrar defectos en las interfaces de hardware externo y las interfaces de los módulos de software con una base de datos.
- A veces, un cliente cambia los requisitos durante el desarrollo del módulo de software. En ese caso, hay posibilidades de que los nuevos requisitos no se prueben en el nivel de prueba unitaria; por lo tanto, las pruebas de integración se vuelven esenciales aquí.
Tipos de pruebas de integración
Este artículo discutirá dos enfoques para las pruebas de integración, considerando los pros y los contras.
- Gran Explosión
- Incremental (además categorizado en enfoques de arriba hacia abajo, de abajo hacia arriba y de sándwich)
Enfoque Big Bang para pruebas de integración
En este enfoque, integramos todos los componentes de software para probar como una unidad conocida como entidad durante la prueba. Este proceso de integración no se ejecutará hasta que se completen todos los componentes de la prueba unitaria.
No lo confunda con la prueba del sistema. Solo probamos la integración de diferentes módulos de software, no todo el sistema (realizado en las pruebas del sistema).
Su ventaja más significativa es que podemos integrar todos los componentes de software y probarlos como una sola unidad, mientras que también es difícil identificar defectos usando el enfoque big bang. Por lo tanto, es conveniente para todos los sistemas pequeños.
Podemos visualizar el enfoque del big bang de la siguiente manera. Hemos integrado seis módulos diferentes y probado usando el big bang.
Enfoque incremental para pruebas de integración
Usando este enfoque, integramos dos o más módulos de software lógicamente relacionados entre sí y luego los probamos para el correcto funcionamiento de la aplicación. Luego, otros módulos/componentes relacionados se integran de forma incremental y se prueban.
Este procedimiento continúa hasta que todos los componentes lógicamente relacionados estén integrados y probados.
Este enfoque se clasifica además en enfoques de arriba hacia abajo, de abajo hacia arriba y de sándwich. Aprendamos cada uno de ellos a continuación a través de los Stubs y Drivers.
Stub- Es llamado por un módulo/componente bajo prueba.Controlador- Esto requiere que se pruebe el módulo/componente.
Enfoque de arriba hacia abajo
Aquí, la integración se realiza de arriba hacia abajo siguiendo el flujo de control del sistema de software. Con este enfoque, probamos componentes de nivel superior y luego avanzamos hacia componentes de nivel inferior para verificar la funcionalidad del software.
Aquí, podemos usar Stubs si algunos componentes aún no se han leído. Es una forma orgánica coherente con lo que sucederá en el entorno real.
Otra ventaja de este enfoque es que podemos probar módulos críticos en prioridad. De esta manera, podemos encontrar defectos en un nivel superior y corregirlos primero.
Por otro lado, probar las funciones principales al final es la única preocupación con este enfoque. Lo podemos visualizar en el siguiente diagrama.
Enfoque de abajo hacia arriba
Aquí, probamos primero los módulos de nivel inferior, que se utilizarán para ayudar a probar el módulo de nivel superior. Este procedimiento continúa hasta que probamos todos los módulos/componentes en el nivel superior.
En el enfoque bottom-up, utilizamos programas estimuladores conocidos como Drivers. Es fácil encontrar defectos y errores en el nivel inferior, pero los problemas de nivel superior solo se pueden encontrar al final cuando todos los componentes se han integrado y probado.
Enfoque de sándwich
Este enfoque combina enfoques de arriba hacia abajo y de abajo hacia arriba, por lo que se conoce como prueba de integración híbrida. Utiliza Stubs y Drivers.
Aquí, los componentes de nivel superior se prueban con componentes de nivel inferior. Al mismo tiempo, los componentes/módulos inferiores se integran con los módulos/componentes de nivel superior y se prueban como sistema.
Podemos visualizar este enfoque de la siguiente manera:
Pasos necesarios para las pruebas de integración
Los siguientes pasos son necesarios independientemente de la estrategia de prueba de software (discutida anteriormente) que se esté utilizando:
-
Hacer un plan de prueba de integración.
-
Diseñar escenarios de prueba, casos y guiones.
-
Ejecute todos los casos de prueba, seguido de la exposición e informe de defectos.
-
Mantenga un registro y vuelva a probar los defectos.
-
Los pasos 3 y 4 se repiten hasta que logremos una integración exitosa.
Ejemplo del mundo real para comprender las pruebas de integración
Supongamos que tenemos un método llamado performPayment(), que toma dos parámetros, amount y service de tipo double y PaymentService, respectivamente.
En la prueba unitaria, lo probaremos creando un simulacro para el argumento “servicio”, mientras que la prueba de integración será una prueba en la que usaremos el “servicio” externo real para asegurarnos de que ese “servicio” responda a nuestros datos de entrada. como se esperaba.
