¿Qué son las pruebas de integración? (Ejemplo)

¿Qué son las pruebas de integración?

Pruebas de integración se define como un tipo de prueba donde los módulos de software se integran lógicamente y se prueban como un grupo. Un proyecto de software típico consta de múltiples módulos de software, codificados por diferentes programadores. El propósito de este nivel de prueba es exponer defectos en la interacción entre estos módulos de software cuando se integran.

Las pruebas de integración se centran en comprobar la comunicación de datos entre estos módulos. De ahí que también se le denomine como 'ÉL' (Integración y Pruebas), 'Prueba de cadenas' y aveces 'Prueba de hilo'.

¿Por qué realizar pruebas de integración?

Aunque cada módulo de software se prueba unitariamente, todavía existen defectos por varias razones, como

• En general, un módulo es diseñado por un desarrollador de software individual, cuya comprensión y lógica de programación pueden diferir de las de otros programadores. Las pruebas de integración se vuelven necesarias para verificar que los módulos de software funcionen en unidad.
• En el momento del desarrollo del módulo, existen grandes posibilidades de que los clientes cambien los requisitos. Es posible que estos nuevos requisitos no se prueben unitariamente y, por lo tanto, las pruebas de integración del sistema se vuelven necesarias.
• Las interfaces de los módulos de software con la base de datos podrían ser erróneas
• Las interfaces de hardware externas, si las hay, podrían ser erróneas
• Un manejo inadecuado de excepciones podría causar problemas.

Haz clic en aquí si el video no es accesible

Ejemplo de caso de prueba de integración

Integración: Caso de prueba difiere de otros casos de prueba en el sentido de que se centra principalmente en las interfaces y el flujo de datos/información entre los módulos. Aquí se debe dar prioridad a la integrando enlaces en lugar de las funciones de la unidad que ya están probadas.

Ejemplos de casos de prueba de integración para el siguiente escenario: La aplicación tiene 3 módulos, digamos 'Página de inicio de sesión', 'Mailcasilla' y 'Eliminar correos' y cada uno de ellos está integrado de forma lógica.

Aquí no nos concentremos mucho en las pruebas de la página de inicio de sesión, ya que ya se hizo en Examen de la unidad. Pero comprueba cómo está vinculado con el Mail Box Página.

Del mismo modo Mail Box: Verifique su integración al Eliminar MailMódulo s.

ID de caso de prueba	Objetivo del caso de prueba	Caso de prueba Description	Resultado Esperado
1	Verifique el enlace de la interfaz entre el inicio de sesión y Mailmódulo de caja	Ingrese las credenciales de inicio de sesión y haga clic en el botón Iniciar sesión	Para ser dirigido a la Mail Box
2	Verifique el enlace de la interfaz entre el Mailcasilla y Borrar Mails Módulo	Desde MailSeleccione el correo electrónico y haga clic en el botón Eliminar	El correo electrónico seleccionado debe aparecer en la carpeta Eliminados/Papelera

Tipos de pruebas de integración

La ingeniería de software define una variedad de estrategias para ejecutar pruebas de integración, a saber:

• Enfoque del Big Bang:
• Enfoque incremental: que se divide además en los siguientes
  • Enfoque de arriba hacia abajo
  • Enfoque de abajo hacia arriba
  • Enfoque sándwich: combinación de arriba hacia abajo y de abajo hacia arriba

A continuación se detallan las diferentes estrategias, la forma en que se ejecutan y sus limitaciones y ventajas.

Prueba del Big Bang

Prueba del Big Bang Es un enfoque de prueba de integración en el que todos los componentes o módulos se integran juntos a la vez y luego se prueban como una unidad. Este conjunto combinado de componentes se considera como una entidad durante las pruebas. Si no se completan todos los componentes de la unidad, el proceso de integración no se ejecutará.

Ventajas:

• Conveniente para sistemas pequeños.

Desventajas:

• La localización de fallos es difícil.
• Dada la gran cantidad de interfaces que deben probarse en este enfoque, algunos enlaces de interfaces que deben probarse podrían pasarse por alto fácilmente.
• Dado que las pruebas de integración pueden comenzar sólo después de que "todos" los módulos estén diseñados, el equipo de pruebas tendrá menos tiempo para la ejecución en la fase de prueba.
• Dado que todos los módulos se prueban a la vez, los módulos críticos de alto riesgo no se aíslan ni se prueban con prioridad. Los módulos periféricos que se ocupan de las interfaces de usuario tampoco están aislados ni probados con prioridad.

Pruebas incrementales

En la Pruebas incrementales En este enfoque, las pruebas se realizan integrando dos o más módulos que están relacionados lógicamente entre sí y luego se prueban para determinar el funcionamiento adecuado de la aplicación. Luego, los otros módulos relacionados se integran de forma incremental y el proceso continúa hasta que todos los módulos relacionados lógicamente se integran y prueban con éxito.

El Enfoque Incremental, a su vez, se lleva a cabo mediante dos Métodos diferentes:

• De abajo hacia arriba
• Top Down

Talones y controladores

Talones y controladores son los programas ficticios en las pruebas de integración que se utilizan para facilitar la pruebas de software actividad. Estos programas actúan como sustitutos de los modelos que faltan en las pruebas. No implementan toda la lógica de programación del módulo de software pero simulan la comunicación de datos con el módulo de llamada durante la prueba.

Talón: Lo llama el módulo bajo prueba.

Destornillador: Llama al módulo a probar.

Prueba de integración ascendente

Prueba de integración ascendente Es una estrategia en la que los módulos de nivel inferior se prueban primero. Estos módulos probados luego se utilizan para facilitar la prueba de módulos de nivel superior. El proceso continúa hasta que se prueben todos los módulos del nivel superior. Una vez que los módulos de nivel inferior se prueban e integran, se forma el siguiente nivel de módulos.

Representación esquemática:

Ventajas:

• La localización de fallos es más sencilla.
• No se pierde tiempo esperando a que se desarrollen todos los módulos, a diferencia del enfoque Big-bang.

Desventajas:

• Los módulos críticos (en el nivel superior de la arquitectura del software) que controlan el flujo de la aplicación se prueban en último lugar y pueden ser propensos a defectos.
• Un prototipo temprano no es posible

Prueba de integración de arriba hacia abajo

Pruebas de integración de arriba hacia abajo Es un método en el que las pruebas de integración se realizan de arriba a abajo siguiendo el flujo de control del sistema de software. Primero se prueban los módulos de nivel superior y luego se prueban e integran los módulos de nivel inferior para verificar la funcionalidad del software. Los stubs se utilizan para realizar pruebas si algunos módulos no están listos.

Representación esquemática:

Ventajas:

• La localización de fallos es más sencilla.
• Posibilidad de obtener un prototipo temprano.
• Los módulos críticos se prueban según su prioridad; Los principales defectos de diseño se podrían encontrar y solucionar primero.

Desventajas:

• Necesita muchos talones.
• Los módulos de nivel inferior no se prueban adecuadamente.

¿Cómo hacer pruebas de integración?

El procedimiento de prueba de integración independientemente de las estrategias de prueba de software (discutidas anteriormente):

1. Preparar la integración Plan de pruebas
2. Diseñar los escenarios, casos y guiones de prueba.
3. Ejecutar los casos de prueba y luego informar los defectos.
4. Seguimiento y nueva prueba de los defectos.
5. Los pasos 3 y 4 se repiten hasta que la integración se complete correctamente.

Resúmenes Description de planes de prueba de integración

Incluye los siguientes atributos:

• Métodos/enfoques de prueba (como se analizó anteriormente).
• Alcances y elementos fuera de alcance de las pruebas de integración.
• Funciones y responsabilidades.
• Requisitos previos para las pruebas de integración.
• Entorno de prueba.
• Planes de Riesgo y Mitigación.

Criterios de entrada y salida de las pruebas de integración.

Criterios de entrada y salida a la fase de pruebas de integración en cualquier modelo de desarrollo de software.

Criterio para entrar:

• Componentes/módulos probados por unidad
• Todos los errores de alta prioridad corregidos y cerrados.
• Todos los módulos deben completarse e integrarse correctamente.
• Plan de pruebas de integración, caso de prueba, escenarios a aprobar y documentar.
• Requerido Entorno de prueba para configurar para pruebas de integración

Criterios de salida:

• Pruebas exitosas de la aplicación integrada.
• Los casos de prueba ejecutados están documentados.
• Todos los errores de alta prioridad corregidos y cerrados.
• Se presentarán documentos técnicos seguidos de notas de la versión.

Mejores prácticas/directrices para pruebas de integración

• Primero, determine la integración Estrategia de prueba que podrían adoptarse y posteriormente preparar los casos de prueba y los datos de prueba en consecuencia.
• Estudiar el ArchiDiseño de la tecnología de la Aplicación e identificación de los Módulos Críticos. Estos deben ser probados con prioridad.
• Obtenga los diseños de interfaz del Archiequipo técnico y crear casos de prueba para verificar todas las interfaces en detalle. La interfaz con la base de datos/hardware externo/aplicación de software debe probarse en detalle.
• Después de los casos de prueba, son los datos de prueba los que desempeñan un papel fundamental.
• Tenga siempre preparados los datos simulados antes de ejecutar. No seleccione datos de prueba mientras ejecuta los casos de prueba.