¿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?

Pruebas de integración


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

  • Un Módulo, en general, está diseñado por un desarrollador de software individual cuya comprensión y lógica de programación pueden diferir de la 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.neous
  • Las interfaces de hardware externo, si las hay, podrían estar equivocadas.neous
  • Un manejo inadecuado de excepciones podría causar problemas.

Haga clic aquí si el video no es accesible

Ejemplo de caso de prueba de integración

moderna 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.

Casos de prueba de integración de muestra para lo siguientewing Escenario: la aplicación tiene 3 módulos que dicen "Página de inicio de sesión", "Mailbox' y 'Eliminar emails’ y cada uno de ellos está integrado lógicamente.

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 Descripción del caso de prueba Resultado Esperado
1 Verifique el enlace de la interfaz entre el inicio de sesión y Mailbox módulo 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 Mailbox y eliminar Mails Módulo Precio Desde Mailbox seleccione la email y haga clic en un botón de eliminar mi seleccionadomail debería 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, viz.

  • Enfoque del Big Bang:
  • Enfoque incremental: que se divide a su vez en los siguienteswing
    • 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:

Tutorial de pruebas de INTEGRACIÓN: Big Bang, de arriba hacia abajo y de abajo hacia arriba

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:

  • Módulos críticos (en el nivel superior de software architecture) que controlan el flujo de la aplicación se prueban en último lugar y pueden ser propensos a presentar 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.wing 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 resguardos se utilizan para realizar pruebas si algunos módulos no están listos.

Representación esquemática:

Tutorial de pruebas de INTEGRACIÓN: Big Bang, de arriba hacia abajo y de abajo hacia arriba

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.

Prueba de sándwich

Prueba de sándwich Es una estrategia en la que los módulos de nivel superior se prueban con módulos de nivel inferior al mismo tiempo que los módulos inferiores se integran con los módulos superiores y se prueban como un sistema. Es una combinación de enfoques de arriba hacia abajo y de abajo hacia arriba, por eso se llama Pruebas de integración híbrida. Hace uso tanto de talones como de controladores.

Tutorial de pruebas de INTEGRACIÓN: Big Bang, de arriba hacia abajo y de abajo hacia arriba

¿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.

Breve descripción de los planes de prueba de integración

Incluye lo siguientewing 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ía adoptarse y later Prepare 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.