¿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 varios 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 están integrados
Las pruebas de integración se enfocan en verificar la comunicación de datos entre estos módulos. Por lo tanto, también se denomina 'I & T' (integración y prueba), 'prueba de cadenas' y, a veces, 'prueba de subprocesos' .
- ¿Qué son las pruebas de integración?
- ¿Por qué realizar pruebas de integración?
- Ejemplo de caso de prueba de integración
- Enfoques, Estrategias, Metodologías de Pruebas de Integración
- Enfoque del Big Bang:
- Enfoque incremental
- ¿Qué es Stub and Driver?
- Integración ascendente
- Integración de arriba hacia abajo:
- Integración híbrida / sándwich
- ¿Cómo realizar pruebas de integración?
- Breve descripción de los planes de prueba de integración:
- Criterios de entrada y salida de las pruebas de integración
- Prácticas recomendadas / directrices para las pruebas de integración
¿Por qué realizar pruebas de integración?
Aunque cada módulo de software se prueba por unidad, 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 otros programadores. Las pruebas de integración se vuelven necesarias para verificar que los módulos de software funcionan en unidad
- En el momento del desarrollo del módulo, existen amplias 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 externo, si las hay, pueden ser erróneas
- El 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
El caso de prueba de integración se diferencia 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 los enlaces de integración en lugar de a las funciones unitarias que ya se han probado.
Ejemplos de casos de prueba de integración para el siguiente escenario: La aplicación tiene 3 módulos que dicen 'Página de inicio de sesión', 'Buzón de correo' y 'Eliminar correos electrónicos' y cada uno de ellos está integrado de manera lógica.
Aquí no se concentre mucho en las pruebas de la página de inicio de sesión, ya que ya se ha realizado en las pruebas unitarias. Pero compruebe cómo está vinculado a la página del buzón de correo.
Del mismo modo Buzón: Verifique su integración con el Módulo Eliminar correos.
| 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 módulo de inicio de sesión y buzón | Ingrese las credenciales de inicio de sesión y haga clic en el botón Iniciar sesión | Para ser dirigido al Buzón |
| 2 | Verifique el enlace de la interfaz entre el buzón y el módulo Eliminar correos | Desde el buzón, seleccione el correo electrónico y haga clic en un botón de eliminar | El correo electrónico seleccionado debería aparecer en la carpeta Eliminado / Papelera |
Enfoques, Estrategias, Metodologías de Pruebas de Integración
La ingeniería de software define una variedad de estrategias para ejecutar las pruebas de integración, a saber.
- Enfoque del Big Bang:
- Enfoque incremental: que se divide a su vez 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 muestran las diferentes estrategias, la forma en que se ejecutan y sus limitaciones y ventajas.
Pruebas de Big Bang
Big Bang Testing es un enfoque de prueba de integración en el que todos los componentes o módulos se integran a la vez y luego se prueban como una unidad. Este conjunto combinado de componentes se considera una entidad durante la prueba. 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 fallas 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 la prueba de integración puede comenzar solo después de que "todos" los módulos estén diseñados, el equipo de prueba 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 se aíslan ni se prueban con prioridad.
Prueba incremental
En el enfoque de prueba incremental , las pruebas se realizan integrando dos o más módulos que están relacionados lógicamente entre sí y luego se prueban para 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
- De arriba hacia abajo
Stubs y controladores
Los stubs y los controladores son los programas ficticios en las pruebas de integración que se utilizan para facilitar la actividad de prueba del software. 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.
Stub : es llamado por el módulo bajo prueba.
Driver : llama al módulo para que sea probado.
Prueba de integración ascendente
La prueba de integración ascendente es una estrategia en la que los módulos de nivel inferior se prueban primero. Estos módulos probados se utilizan posteriormente para facilitar la prueba de módulos de nivel superior. El proceso continúa hasta que se prueban 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 fallas es más fácil.
- No se pierde tiempo esperando 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 de software) que controlan el flujo de la aplicación se prueban en último lugar y pueden ser propensos a tener defectos.
- No es posible un prototipo temprano
Prueba de integración de arriba hacia abajo
Las pruebas de integración de arriba hacia abajo son un método en el que las pruebas de integración se llevan a cabo de arriba a abajo siguiendo el flujo de control del sistema de software. Los módulos de nivel superior se prueban primero y luego los módulos de nivel inferior se prueban e integran para verificar la funcionalidad del software. Los stubs se utilizan para probar si algunos módulos no están listos.
Representación esquemática:
Ventajas:
- La localización de fallas es más fácil.
- Posibilidad de obtener un prototipo temprano.
- Los módulos críticos se prueban con prioridad; Los principales defectos de diseño se pueden encontrar y corregir primero.
Desventajas:
- Necesita muchos talones.
- Los módulos de un nivel inferior se prueban de forma inadecuada.
Prueba de sándwich
Sandwich Testing 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 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 lo que se denomina prueba de integración híbrida . Utiliza tanto stubs como controladores.
¿Cómo realizar pruebas de integración?
El procedimiento de prueba de integración independientemente de las estrategias de prueba del software (discutidas anteriormente):
- Prepare el plan de pruebas de integración
- Diseñe los escenarios de prueba, los casos y los scripts.
- Ejecutar los Casos de prueba y luego informar los defectos.
- Seguimiento y reevaluación de los defectos.
- Los pasos 3 y 4 se repiten hasta que la integración se completa correctamente.
Breve descripción de los planes de prueba de integración:
Incluye los siguientes atributos:
- Métodos / enfoques de las pruebas (como se discutió anteriormente).
- Ámbitos y elementos fuera de ámbito 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 prueba 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 ser completados e integrados correctamente.
- Pruebas de integración Plan, caso de prueba, escenarios a firmar y documentar.
- Entorno de prueba requerido para ser configurado para pruebas de integración
Criterio de salida:
- Prueba exitosa de la aplicación integrada.
- Los casos de prueba ejecutados están documentados
- Todos los errores de alta prioridad corregidos y cerrados
- Documentos técnicos que se enviarán seguidos de notas de lanzamiento.
Prácticas recomendadas / directrices para las pruebas de integración
- Primero, determine la estrategia de prueba de integración que podría adoptarse y luego prepare los casos de prueba y los datos de prueba en consecuencia.
- Estudiar el diseño de Arquitectura de la Aplicación e identificar los Módulos Críticos. Estos deben probarse con prioridad.
- Obtenga los diseños de interfaz del equipo de arquitectura y cree casos de prueba para verificar todas las interfaces en detalle. La interfaz a la aplicación de software / hardware externo / base de datos debe probarse en detalle.
- Después de los casos de prueba, son los datos de prueba los que juegan un papel fundamental.
- Tenga siempre preparados los datos simulados antes de la ejecución. No seleccione datos de prueba mientras ejecuta los casos de prueba.