¿Qué son las pruebas de integración de sistemas?
La prueba de integración del sistema se define como un tipo de prueba de software que se lleva a cabo en un entorno integrado de hardware y software para verificar el comportamiento del sistema completo. Se está probando en un sistema completo e integrado para evaluar el cumplimiento del sistema con su requisito especificado.
La prueba de integración del sistema (SIT) se realiza para verificar las interacciones entre los módulos de un sistema de software. Se ocupa de la verificación de los requisitos de software de alto y bajo nivel especificados en la Especificación / Datos de requisitos de software y el Documento de diseño de software.
También verifica la coexistencia de un sistema de software con otros y prueba la interfaz entre los módulos de la aplicación de software. En este tipo de prueba, los módulos primero se prueban individualmente y luego se combinan para formar un sistema.
Por ejemplo, los componentes de software y / o hardware se combinan y prueban progresivamente hasta que se ha integrado todo el sistema.
En este tutorial, aprenderá:
- ¿Qué son las pruebas de integración de sistemas?
- ¿Por qué realizar pruebas de integración de sistemas?
- Cómo realizar pruebas de integración de sistemas
- Criterios de entrada y salida para pruebas de integración
- Pruebas de integración de hardware a software
- Pruebas de integración de software a software
- Enfoque de arriba hacia abajo
- Enfoque de abajo hacia arriba
- Enfoque del Big Bang
¿Por qué realizar pruebas de integración de sistemas?
En ingeniería de software, las pruebas de integración de sistemas se realizan porque,
- Ayuda a detectar defectos a tiempo
- Habrá comentarios anteriores sobre la aceptabilidad del módulo individual.
- La programación de las correcciones de defectos es flexible y se puede superponer con el desarrollo.
- Flujo de datos correcto
- Flujo de control correcto
- Tiempo correcto
- Uso correcto de la memoria
- Corregir con los requisitos de software
Cómo realizar pruebas de integración de sistemas
Es una técnica sistemática para construir la estructura del programa mientras se realizan pruebas para descubrir errores asociados con la interfaz.
Todos los módulos se integran de antemano y todo el programa se prueba como un todo. Pero durante este proceso, es probable que se encuentre una serie de errores.
La corrección de tales errores es difícil porque las causas de aislamiento se complican por la gran expansión de todo el programa. Una vez que estos errores se rectifican y corrigen, aparecerá uno nuevo y el proceso continúa sin problemas en un bucle sin fin . Para evitar esta situación, se utiliza otro enfoque, la integración incremental. Veremos más detalles sobre un enfoque incremental más adelante en el tutorial.
Hay algunos métodos incrementales, como las pruebas de integración que se realizan en un sistema basado en el procesador de destino. La metodología utilizada es Black Box Testing. Se puede utilizar la integración ascendente o descendente.
Los casos de prueba se definen utilizando únicamente los requisitos de software de alto nivel.
La integración del software también se puede lograr en gran medida en el entorno del host, con unidades específicas para el entorno de destino que se siguen simulando en el host. Será necesario repetir las pruebas en el entorno de destino para su confirmación.
Las pruebas de confirmación en este nivel identificarán problemas específicos del entorno, como errores en la asignación y desasignación de memoria. La practicidad de realizar la integración de software en el entorno de host dependerá de cuánta funcionalidad específica de destino haya. Para algunos sistemas embebidos, el acoplamiento con el entorno de destino será muy fuerte, por lo que no será práctico realizar la integración de software en el entorno de host.
Los grandes desarrollos de software dividirán la integración de software en varios niveles. Los niveles más bajos de integración de software podrían basarse predominantemente en el entorno de host, y los niveles posteriores de integración de software podrían volverse más dependientes del entorno de destino.
Nota: Si solo se está probando software, entonces se denomina Prueba de integración de software y software [SSIT] y si se están probando tanto el hardware como el software, se denomina Prueba de integración de software y hardware [HSIT].
Criterios de entrada y salida para pruebas de integración
Por lo general, al realizar pruebas de integración, se utiliza la estrategia ETVX (Criterios de entrada, tarea, validación y criterios de salida).
Criterio para entrar:
- Finalización de la prueba unitaria
Entradas:
- Datos de requisitos de software
- Documento de diseño de software
- Plan de verificación de software
- Documentos de integración de software
Ocupaciones:
- Basado en los requisitos de alto y bajo nivel, cree casos y procedimientos de prueba
- Combinar compilaciones de módulos de bajo nivel que implementan una funcionalidad común
- Desarrollar un arnés de prueba
- Prueba la construcción
- Una vez que se pasa la prueba, la compilación se combina con otras compilaciones y se prueba hasta que el sistema se integra como un todo.
- Vuelva a ejecutar todas las pruebas en la plataforma basada en el procesador de destino y obtenga los resultados
Criterio de salida:
- Finalización exitosa de la integración del módulo de software en el hardware de destino
- Rendimiento correcto del software de acuerdo con los requisitos especificados
Salidas
- Informes de prueba de integración
- Procedimientos y casos de prueba de software [SVCP].
Pruebas de integración de software y hardware
La prueba de integración de hardware y software es un proceso de prueba de componentes de software de computadora (CSC) para las funcionalidades de alto nivel en el entorno de hardware de destino. El objetivo de las pruebas de integración de hardware / software es probar el comportamiento del software desarrollado integrado en el componente de hardware.
Pruebas de integración de hardware y software basadas en requisitos
El objetivo de las pruebas de integración de hardware / software basadas en requisitos es asegurarse de que el software del equipo de destino satisfaga los requisitos de alto nivel. Los errores típicos revelados por este método de prueba incluyen:
- Errores de interfaces de hardware / software
- Violaciones de particiones de software.
- Incapacidad para detectar fallas mediante prueba incorporada
- Respuesta incorrecta a fallas de hardware
- Error debido a la secuenciación, cargas de entrada transitorias y transitorios de potencia de entrada
- La retroalimentación genera un comportamiento incorrecto
- Control incorrecto o inadecuado del hardware de administración de memoria
- Problema de contención del bus de datos
- Funcionamiento incorrecto del mecanismo para verificar la compatibilidad y corrección del software cargable en campo
La integración de hardware y software se ocupa de la verificación de los requisitos de alto nivel. Todas las pruebas de este nivel se realizan en el hardware de destino.
- La prueba de caja negra es la metodología de prueba principal utilizada en este nivel de prueba.
- Definir casos de prueba solo a partir de los requisitos de alto nivel
- Se debe ejecutar una prueba en hardware estándar de producción (en el objetivo)
Aspectos a tener en cuenta al diseñar casos de prueba para la integración de HW / SW
- Adquisición correcta de todos los datos por parte del software
- Escalado y rango de datos como se espera de hardware a software
- Salida correcta de datos del software al hardware
- Datos dentro de las especificaciones (rango normal)
- Datos fuera de las especificaciones (rango anormal)
- Datos de límites
- Interrumpe el procesamiento
- Sincronización
- Uso correcto de la memoria (direccionamiento, superposiciones, etc.)
- Transiciones de estado
Nota: Para las pruebas de interrupciones, todas las interrupciones se verificarán independientemente desde la solicitud inicial hasta el servicio completo y hasta su finalización. Los casos de prueba se diseñarán específicamente para probar adecuadamente las interrupciones.
Pruebas de integración de software a software
Es la prueba del componente de software informático que funciona dentro de la computadora host / objetivo.
Medio ambiente, mientras se simula todo el sistema [otros CSC], y en la funcionalidad de alto nivel.
Se centra en el comportamiento de un CSC en un entorno host / objetivo simulado. El enfoque utilizado para la integración de software puede ser un enfoque incremental (de arriba hacia abajo, de abajo hacia arriba o una combinación de ambos).
Enfoque incremental
La prueba incremental es una forma de prueba de integración. En este tipo de método de prueba, primero prueba cada módulo del software individualmente y luego continúa probando agregando otros módulos, luego otro y así sucesivamente.
La integración incremental es el contraste con el enfoque del Big Bang. El programa está construido y probado en pequeños segmentos, donde los errores son más fáciles de aislar y corregir. Es más probable que las interfaces se prueben por completo y se puede aplicar un enfoque de prueba sistemático.
Hay dos tipos de pruebas incrementales
- Enfoque de arriba hacia abajo
- Enfoque de abajo hacia arriba
Enfoque de arriba hacia abajo
En este tipo de enfoque, el individuo comienza probando solo la interfaz de usuario, con la funcionalidad subyacente simulada por stubs, luego se mueve hacia abajo integrando capas inferiores e inferiores como se muestra en la imagen a continuación.
- Comenzando con el módulo de control principal, los módulos se integran moviéndose hacia abajo a través de la jerarquía de control
- Los submódulos del módulo de control principal se incorporan a la estructura, ya sea de una manera en amplitud o en profundidad.
- La integración en profundidad integra todos los módulos en una ruta de control principal de la estructura, como se muestra en el siguiente diagrama:
El proceso de integración del módulo se realiza de la siguiente manera:
- El módulo de control principal se utiliza como controlador de prueba y los stubs sustituyen a todos los módulos directamente subordinados al módulo de control principal.
- Los stubs subordinados se reemplazan uno a la vez con módulos reales según el enfoque seleccionado (primero la amplitud o la profundidad).
- Las pruebas se ejecutan a medida que se integra cada módulo.
- Al completar cada conjunto de pruebas, se reemplaza otro talón con un módulo real al completar cada conjunto de pruebas
- Para asegurarse de que no se hayan introducido nuevos errores, se pueden realizar pruebas de regresión.
El proceso continúa desde el paso 2 hasta que se construye toda la estructura del programa. La estrategia de arriba hacia abajo parece relativamente sencilla, pero en la práctica surgen problemas logísticos.
El más común de estos problemas ocurre cuando se requiere procesar en niveles bajos en la jerarquía para probar adecuadamente los niveles superiores.
Los stubs reemplazan los módulos de bajo nivel al comienzo de las pruebas descendentes y, por lo tanto, no pueden fluir datos significativos hacia arriba en la estructura del programa.
Desafíos que puede enfrentar el probador:
- Retrase muchas pruebas hasta que los stubs se reemplacen con módulos reales.
- Desarrolle stubs que realicen funciones limitadas que simulen el módulo real.
- Integre el software desde la base de la jerarquía hacia arriba.
Nota: El primer enfoque hace que perdamos cierto control sobre la correspondencia entre pruebas específicas y la incorporación de módulos específicos. Esto puede resultar en dificultad para determinar la causa de los errores, lo que tiende a violar la naturaleza altamente restringida del enfoque de arriba hacia abajo.
El segundo enfoque es viable, pero puede generar una sobrecarga significativa, ya que los talones se vuelven cada vez más complejos.
Enfoque de abajo hacia arriba
La integración ascendente comienza la construcción y las pruebas con módulos en el nivel más bajo en la estructura del programa. En este proceso, los módulos se integran de abajo hacia arriba.
En este enfoque, el procesamiento requerido para los módulos subordinados a un nivel dado está siempre disponible y se elimina la necesidad de los stubs.
Este proceso de prueba de integración se realiza en una serie de cuatro pasos
- Los módulos de bajo nivel se combinan en grupos que realizan una subfunción de software específica.
- Se escribe un controlador para coordinar la entrada y salida del caso de prueba.
- Se prueba el clúster o la compilación.
- Los controladores se eliminan y los clústeres se combinan moviéndose hacia arriba en la estructura del programa.
A medida que la integración avanza, la necesidad de lecciones de controladores de prueba por separado. De hecho, si los dos niveles superiores de la estructura del programa se integran de arriba hacia abajo, el número de impulsores se puede reducir sustancialmente y la integración de los clústeres se simplifica enormemente. La integración sigue el patrón que se ilustra a continuación. A medida que la integración avanza, la necesidad de lecciones de controladores de prueba por separado.
Nota: Si los dos niveles superiores de la estructura del programa están integrados de arriba hacia abajo, la cantidad de controladores se puede reducir sustancialmente y la integración de compilaciones se simplifica enormemente.
Enfoque del Big Bang
En este enfoque, todos los módulos no se integran hasta que todos los módulos estén listos. Una vez que están listos, todos los módulos se integran y luego se ejecuta para saber si todos los módulos integrados están funcionando o no.
En este enfoque, es difícil conocer la causa raíz de la falla debido a que se integra todo a la vez.
Además, habrá una alta probabilidad de que se produzcan errores críticos en el entorno de producción.
Este enfoque se adopta solo cuando las pruebas de integración deben realizarse de una vez.
Resumen:
- La integración se realiza para verificar las interacciones entre los módulos de un sistema de software. Ayuda a detectar el defecto temprano
- Las pruebas de integración se pueden realizar para la integración de hardware-software o hardware-hardware
- Las pruebas de integración se realizan mediante dos métodos
- Enfoque incremental
- Enfoque del Big Bang
- Al realizar las pruebas de integración, generalmente se utiliza la estrategia ETVX (criterios de entrada, tarea, validación y criterios de salida).