¿Qué son las pruebas de integración?
Con los avances en el campo de la tecnología de la información, las cosas se están volviendo mucho más fáciles para nosotros, los humanos y, literalmente, todo se puede hacer con solo un chasquido de nuestros dedos. Pero antes de esto todo se puede hacer mucho trabajo duro y lo más importante de todo "LOGIC" se pone detrás de esto. Ahora, a veces, hemos visto que algunas funciones no funcionan exactamente según las expectativas o los resultados derivados del software no coinciden con nuestras expectativas, ahí es donde las pruebas de software juegan un papel importante. Para corregir las fallas en los sistemas, a fin de obtener los resultados correctos / esperados es la prueba de software.
Para comprender lo que significa la prueba de integración, primero debemos entender qué significa la prueba de software. La prueba de software es una actividad para verificar si el resultado / resultado de una prueba es equivalente al resultado / resultado esperado, lo que significa que el software se está ejecutando correctamente. El resultado que se obtiene después de ejecutar cierto software / sistema debe coincidir con el resultado que se espera como salida del software / sistema; si no lo hace, el software debe reescribirse o deben realizarse ciertos cambios dentro del código escrito.
La prueba de software de un sistema de software se realiza a diferentes niveles. Los niveles de prueba se representan de la siguiente manera:
Cronológicamente, las pruebas de integración se realizan después del primer paso, se realiza la "Prueba de Unidad". Como dice el nombre de integración, la definición textual de Pruebas de integración es "Los módulos de software individuales se combinan y prueban juntos, como un grupo". Significa que, en el software, hay muchos componentes. Estos muchos componentes juntos cuando se combinan forman un sistema de software. Este sistema de software se prueba en conjunto y el nivel de prueba en el que se prueba se conoce como prueba de integración. Entonces, cuando se combinan estos módulos, el resultado que se obtiene de él debe ser equivalente al resultado esperado, ahí es donde las pruebas de integración forman parte. El propósito principal de las pruebas de integración es verificar si los módulos individuales funcionan juntos correctamente cuando se combinan.
También conocido como I & T (Integración y prueba) puede ayudar en la prueba de un individuo, así como en pruebas de módulo completo. Se incluye en las pruebas Black Box y White Box. La mayoría de las organizaciones solo prueban sus softwares usando metodologías de Pruebas de Unidad y Pruebas Funcionales.
Tipos y enfoques
Hay cuatro tipos y enfoques de pruebas de integración, que se mencionan a continuación:
- Enfoque del Big Bang
- Enfoque de abajo hacia arriba
- Enfoque de arriba hacia abajo
- Híbrido / Sandwich
1. Enfoque de Big Bang:
Los módulos / componentes desarrollados de los sistemas de software están acoplados entre sí. Estos módulos individuales se prueban juntos cuando se acoplan. Después de la prueba de la unidad, estos módulos se prueban juntos y forman un sistema de software. Pero algunos de nosotros, podemos tener esta pregunta: ¿en qué se diferencian las pruebas del sistema de software en su conjunto y las pruebas de integración? Lo principal que entendemos aquí es que, en las pruebas de integración, las pruebas se realizan para que los módulos individuales se combinen juntos, después de que se realizan las pruebas unitarias; y en las pruebas de sistemas de software, todo el sistema se prueba teniendo en cuenta todos los parámetros.
El siguiente diagrama muestra exactamente lo que significa el enfoque Big Bang de las pruebas de integración:
Con Big Bang Approach, hay algunas ventajas y desventajas asociadas:
Ventajas:
- Es muy conveniente acercarse si los sistemas son pequeños. Como el tiempo necesario para este enfoque es mayor, los grandes sistemas pueden conducir a un mayor consumo de tiempo.
- La detección de fallas es muy fácil con esto, considerando sistemas pequeños
Desventajas
- Dado que todos los módulos están acoplados, si surge alguna falla en los sistemas, es difícil detectarlo.
- Algunos módulos son muy importantes y necesitan ser probados. Estos módulos deben probarse antes de usarse en el sistema. Pero durante las pruebas de integración, es posible que estos módulos no se prueben de manera eficiente, ya que todos los módulos están acoplados entre sí.
- El tiempo que tarda todo el sistema de software es mucho más que otros enfoques de pruebas de integración.
- El acoplamiento de los módulos puede llevar algo de tiempo, lo que puede dar lugar al tiempo total del proceso del sistema de software.
- El tiempo necesario para este enfoque es más, ya que muchos módulos están acoplados y probar cada módulo llevará más tiempo.
2. Enfoque ascendente
En este enfoque, los módulos de bajo nivel se prueban primero, juntos e individualmente. Todos los módulos de nivel inferior están integrados, lo que incluye funciones y procedimientos, y todo está acoplado y probado. Esto ayuda a probar los módulos de nivel superior, ya que forma una base para ello. Este procedimiento se repite para todos los módulos desde el nivel inferior hasta el módulo de nivel superior que se prueban exhaustivamente. En términos simples, la prueba comienza, desde los módulos más internos y más inferiores, y gradualmente se dirige hacia arriba. Ahora, como se indica en el diagrama, la ayuda de un controlador se toma al hacerlo. Entonces, ¿qué es un controlador y cómo ayuda? Como sugiere el flujo, los módulos de nivel superior no pueden integrarse en el sistema hasta que, a menos que las pruebas del módulo de nivel inferior se hayan realizado y acoplado. Entonces, el controlador aquí ayuda a acoplar los módulos de nivel inferior y superior y funciona como un medio o en un término técnico como una función de llamada.
Ventajas:
- El desarrollo de módulos individuales se puede hacer mientras se usa el enfoque ascendente de las pruebas de integración, ya que las pruebas de acoplamiento e integración se realizan después de que los módulos de nivel inferior se prueban primero.
- Si existe / surge algún error, se puede arreglar al mismo tiempo y al mismo nivel. La identificación y corrección de errores es mucho más fácil que otros enfoques.
- El tiempo requerido para la identificación y corrección de errores es mucho menor en comparación con otros enfoques.
- Los errores se pueden resolver en el mismo nivel inferior de instancia o en el nivel superior.
Desventajas
- El tiempo necesario para todo el proceso es más, el proceso de prueba no termina hasta que todos los módulos de ambos, el nivel superior e inferior estén incluidos y probados.
- Los controladores son necesarios para llamar a los módulos de alto nivel
- Si el sistema de software contiene módulos cada vez más pequeños pero complejos, puede llevar más tiempo completar el proceso de prueba de software.
3. Enfoque de arriba hacia abajo
Este enfoque es exactamente lo opuesto al enfoque de abajo hacia arriba. Los módulos de nivel superior se prueban inicialmente y luego simultáneamente se prueban otros módulos de nivel inferior. Los módulos superiores se prueban primero individualmente, como las pruebas unitarias especializadas se ejecutan para el módulo superior y, finalmente, otros módulos se tienen en cuenta y se prueban. El enfoque de arriba hacia abajo requiere una función de llamada al igual que un enfoque de abajo hacia arriba llamado Stubs. Los apéndices son sentencias lógicas de código corto que se utilizan para aceptar entradas de los módulos de nivel superior y eventualmente llamar a módulos de nivel inferior para integración y pruebas.
Ventajas:
- Fácilmente se pueden detectar fallas o errores en este enfoque.
- Los módulos cruciales se prueban exhaustivamente y antes que otros módulos.
- Las pruebas de integración del sistema de software se pueden realizar en menos tiempo en comparación con otros enfoques.
Desventajas
- Es posible que los módulos de nivel inferior no se prueben hasta el nivel esperado o que no se prueben según los requisitos.
- Se necesitan talones y son necesarios para que el proceso de prueba avance más.
4. Enfoque híbrido / sándwich
También conocido como prueba de integración mixta. El enfoque de abajo hacia arriba y el enfoque de arriba hacia abajo se combinan en este enfoque. Por lo tanto, conocido como enfoque de prueba híbrido o sándwich o integración mixta. Este enfoque se está utilizando para ocultar las consecuencias de ambos abordados individualmente. El módulo superior está probado en la unidad y, al mismo tiempo, los módulos de nivel inferior están integrados y probados con los módulos de nivel superior.
Ventajas:
- Principalmente utilizado para grandes proyectos y que requieren mucho tiempo para su finalización.
Desventajas
- Los costos de este tipo de pruebas son bastante altos ya que ambos enfoques se utilizan para completar las pruebas.
Ventajas de las pruebas de integración
- Las pruebas de integración para diferentes módulos al mismo tiempo son fáciles.
- Se puede utilizar tanto en las etapas iniciales como posteriores del proceso de prueba.
- La cobertura de la longitud del código es más en comparación con otras técnicas de prueba de software, ya que se pueden usar los enfoques de abajo hacia arriba y de arriba hacia abajo.
- De acuerdo con los cambios en los requisitos, el desarrollo varía, por lo que las pruebas de módulos en diferentes niveles se vuelven importantes, por lo que las pruebas de integración se pueden usar fácilmente.
Por qué se utilizan las pruebas de integración
- Las personas que han estado en la industria de TI pueden conocer los constantes cambios que suceden. Todos los días, de acuerdo con los requisitos, la necesidad de desarrollar un cierto sistema de software cambia, por lo que cada día se desarrollan nuevos parches de código. Ahora, cuando estos parches se unen para formar un solo software. Entonces, para verificar esto, las pruebas de integración y sus enfoques son imprescindibles.
- Cuando se codifica o construye un software complejo o enorme, se clasifica en módulos separados. Muchas personas trabajan en estos módulos al mismo tiempo, pero cuando estos módulos están integrados, se realizan las pruebas. En la mayoría de los casos, la integración de módulos requiere que se realicen pruebas de integración en él, antes de seguir procesándose.
- La mayoría de las aplicaciones de software requieren que algunas bibliotecas de soporte funcionen. Las pruebas de integración se realizan cuando estas bibliotecas se usan junto con el código desarrollado.
- La integración se convierte en una necesidad cuando se desarrolla el software, ya que los errores pueden rectificarse al nivel estipulado. Ahora, como sabemos acerca de los enfoques, uno de los enfoques se puede utilizar para ello.
Casos de prueba de integración
Considere que estamos creando un software de gestión de empleados. Este software tiene tres aspectos principales:
- Inicio de sesión de empleado
- Informe del empleado
- Página de designación de salario de empleado y nivel de salario
Ahora, considerando el caso anterior, primero se desarrolla el software y el flujo debe ser el registro del Empleado (Ingresando los valores, por ejemplo: identificación del empleado, nombre, número de teléfono, etc.). Después de las entradas correctas, debe redirigir a la página de red que informa la página del empleado. Ahora, si aquí el empleado no es dirigido a la página de informes y directamente a la página de información salarial, entonces es un error. Entonces, para rectificar esto, se realiza el flujo, la secuencia de actividades, las pruebas de integración.
Otro ejemplo de las pruebas de integración sería:
Revisamos diariamente nuestros correos electrónicos. Todos los proveedores de servicios de correo electrónico nos brindan la misma funcionalidad.
Login-> Inbox->Send / Delete Mail-> Logout
Ahora, aquí cuando iniciamos sesión en sus servidores, primero se verifica la exactitud de los valores, es decir, pruebas unitarias. Entonces, ahora después de que coincidan las credenciales, la página de inicio de sesión debería transferirnos a la página de la bandeja de entrada. Ese es el resultado esperado. Si no nos transfiere a la página de la Bandeja de entrada, sino que nos transfiere a alguna carpeta basura, se convierte en un caso de prueba de integración. Lo mismo ocurre con el envío y la eliminación de los correos electrónicos.
Otros casos pueden ser:
- Después de un registro exitoso en cualquier aplicación en línea / fuera de línea, debe aparecer un mensaje en pantalla frente al usuario.
- Las aplicaciones bancarias deben dirigir a los usuarios a la página de resumen de cuenta que se requiere.
- Después de iniciar sesión correctamente en las aplicaciones de redes sociales, debe aparecer la página predeterminada, por ejemplo: Inicio / Perfil para Facebook.
Conclusión
Con tantos avances en el campo de TI, día a día, y tantos desarrolladores en diferentes ubicaciones trabajando en el mismo software, las pruebas de integración se han convertido en una necesidad. Con sus enfoques, las pruebas de integración se pueden usar con aplicaciones de software pequeñas y grandes por igual. Las pruebas de integración, al estar en el medio de los niveles de prueba de software y tener tantas ventajas, se vuelven cada vez más importantes para los clientes de nivel comercial y la verificación regular ayuda a mantener el software intacto.
Artículos recomendados
Esta ha sido una guía para las pruebas de integración. Aquí discutimos algunos conceptos básicos, definición, tipos y enfoque con sus ventajas y desventajas. También puede consultar nuestros otros artículos sugeridos para obtener más información:
- Carreras en pruebas de software
- Carreras para desarrolladores de software
- ¿Qué es la prueba de caja negra?
- Carreras útiles como ingeniero de software