¿Qué es SIT? Pruebas de integración de sistemas con ejemplo

¿Qué son las pruebas de integración de sistemas?

Sistema Pruebas de integración Se define como un tipo de prueba de software realizada en un entorno integrado de hardware y software para verificar el comportamiento del sistema completo. Son pruebas realizadas en un sistema completo e integrado para evaluar el cumplimiento del sistema con sus requisitos especificados.

Las pruebas de integración del sistema (SIT, por sus siglas en inglés) se realizan para verificar las interacciones entre los módulos de un sistema de software. Se ocupan de la verificación de los requisitos de software de alto y bajo nivel especificados en la Especificación de Requisitos de Software/Datos y el Documento de Diseño de Software.

Las pruebas de integración de software (SIT) también verifican la coexistencia de un sistema de software con otros y prueban la interfaz entre los módulos de la aplicación. En este tipo de pruebas, los módulos se prueban primero 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 el sistema completo esté integrado.

El diagrama anterior muestra la progresión que define SIT: los módulos verificados por separado se fusionan paso a paso hasta que queda un único sistema integrado bajo prueba.

¿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 Defecto temprana
• Se dispondrá de comentarios anteriores sobre la aceptabilidad del módulo individual.
• La programación de correcciones de defectos es flexible y puede superponerse con el desarrollo.
• Flujo de datos correcto
• Flujo de control correcto
• Momento correcto
• Uso correcto de la memoria
• Corregir con los requisitos de software.

Pruebas de integración del sistema vs. Pruebas del sistema vs. Pruebas de aceptación del usuario

Debido a que estos tres niveles son consecutivos, a menudo se confunden. Pruebas del sistema examina una construcción terminada en función de sus requisitos, SIT examina las uniones entre las construcciones y Pruebas de aceptación del usuario Examina la idoneidad del negocio desde el punto de vista del cliente. La tabla a continuación los separa.

Parámetro	Pruebas de integración del sistema	Pruebas del sistema	Pruebas de aceptación del usuario
Enfoque primario	Interfaces y flujo de datos entre módulos integrados	Comportamiento del conjunto ensamblado en su totalidad	Aptitud empresarial para uso real
Nivel de prueba	Nivel dos	Nivel tres	Nivel final antes de la puesta en marcha.
Tecnologia	Caja negra	Caja negra, caja blanca o caja gris	Caja negra
Interpretado por	probadores de integración y desarrolladores	Equipo de pruebas independiente	Clientes o usuarios finales
Defectos típicos	Interfaz, sincronización, memoria y mapa de datosping errores	Errores funcionales y no funcionales del sistema	Desajustes entre la usabilidad y los requisitos
Corre cuando	Después Examen de la unidad	Después de SIT	Después de las pruebas del sistema

La secuencia importa. Los módulos superan las pruebas unitarias, las pruebas de integración del sistema (SIT) comprueban las interfaces, las pruebas del sistema (SIT) comprueban el producto ensamblado y las pruebas de aceptación del usuario (UAT) confirman que el producto cumple con las expectativas del negocio. Saltarping Las pruebas de integración del sistema (SIT) trasladan los defectos de la interfaz a las pruebas de aceptación del usuario (UAT), donde cada corrección cuesta mucho más de realizar.

Cómo realizar pruebas de integración del sistema

Se trata de una técnica sistemática para construir la estructura del programa mientras se realizan pruebas para detectar errores relacionados con la interfaz.

Todos los módulos se integran de antemano y todo el programa se prueba en su conjunto. Pero durante este proceso, es probable que se produzcan una serie de errores.

La corrección de tales errores es difícil porque las causas del 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. Este enfoque se explica detalladamente en la siguiente sección.

Existen 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 Negro Box Pruebas. 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 anfitrión, simulándose unidades específicas del entorno objetivo en el anfitrión. Nuevamente será necesario repetir las pruebas en el entorno de destino para confirmarlas.

Las pruebas de confirmación a este nivel identificarán problemas específicos del entorno, como errores en la asignación y liberación de memoria. La viabilidad de realizar la integración de software en el entorno anfitrión dependerá de la cantidad de funcionalidad específica del sistema de destino. Para algunos sistemas embebidos, el acoplamiento con el entorno de destino será muy fuerte, lo que hará que la integración de software en el entorno anfitrión resulte poco práctica.

Los grandes desarrollos de software dividirán la integración del software en varios niveles. Los niveles inferiores de integración del software podrían basarse predominantemente en el entorno anfitrión, mientras que los niveles posteriores de integración del software se volverán más dependientes del entorno de destino.

Nota: Si solo se prueba software, se llama Prueba de integración de software y software [SSIT] y si se prueban tanto el hardware como el software, se llama Prueba de integración de software y hardware [HSIT].

Enfoque incremental

Dado que integrar todo a la vez dificulta el aislamiento de los defectos, la mayoría de los equipos siguen el método incremental que se describe aquí.

Las pruebas incrementales son una forma de pruebas 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 contrasta con el enfoque del big bang. El programa se construye y prueba 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 avanza 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 primero en anchura o primero 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:

1. El módulo de control principal se utiliza como controlador de prueba y los resguardos se sustituyen por todos los módulos directamente subordinados al módulo de control principal.
2. Los talones subordinados se reemplazan uno a la vez con módulos reales dependiendo del enfoque seleccionado (primero la anchura o primero la profundidad).
3. Las pruebas se ejecutan a medida que se integra cada módulo.
4. Al finalizar cada conjunto de pruebas, se reemplaza otro trozo con un módulo real al finalizar cada conjunto de pruebas.
5. Para asegurarse de que no se hayan introducido nuevos errores Pruebas de regresión Se puede realizar.

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 procesamiento en niveles bajos de la jerarquía para probar adecuadamente los niveles superiores.

Los stubs reemplazan los módulos de bajo nivel al comienzo de las pruebas de arriba hacia abajo y, por lo tanto, no pueden fluir datos significativos hacia arriba en la estructura del programa.

Desafíos que podría enfrentar el evaluador:

• Retrasar muchas pruebas hasta que los stubs se reemplacen con módulos reales.
• Desarrollar 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 nos hace perder cierto control sobre la correspondencia entre pruebas específicas y la incorporación de módulos específicos. Esto puede resultar en dificultades 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 stubs 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 de 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 siempre está disponible y se elimina la necesidad de los resguardos.

Este proceso de prueba de integración se realiza en una serie de cuatro pasos.

1. Los módulos de bajo nivel se combinan en grupos que realizan una subfunción de software específica.
2. Un controlador está escrito para coordinar la entrada y salida del caso de prueba.
3. Se prueba el clúster o la compilación.
4. Se eliminan los controladores y se combinan los clústeres moviéndose hacia arriba en la estructura del programa.

A medida que la integración avanza hacia arriba, disminuye la necesidad de lecciones independientes para los controladores de prueba. De hecho, si los dos niveles superiores de la estructura del programa se integran de arriba hacia abajo, el número de controladores puede reducirse sustancialmente y la integración de clústeres se simplifica enormemente. La integración sigue el patrón que se ilustra a continuación.

Nota: Si los dos niveles superiores de la estructura del programa se integran 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 del fallo 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 sólo cuando las pruebas de integración deben realizarse de inmediato.

Pruebas de integración de software de hardware

Pruebas de integración de software de hardware es un proceso de prueba de componentes de software de computadora (CSC) para 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 garantizar que el software en la computadora 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 partición de software.
• Incapacidad para detectar fallas mediante la prueba incorporada
• Respuesta incorrecta a fallas de hardware.
• Error debido a secuenciación, cargas de entrada transitorias y transitorios de potencia de entrada
• Bucles de retroalimentación comportamiento incorrecto
• Control incorrecto o inadecuado del hardware de gestió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 software de hardware 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.
• Definición Casos de prueba solo de los requisitos de alto nivel
• Se debe ejecutar una prueba en hardware estándar de producción (en el objetivo)

Cosas a considerar al diseñar casos de prueba para la integración HW/SW

• Adquisición correcta de todos los datos por parte del software.
• Escalado y variedad de datos como se esperaba del hardware al 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 interrupción, 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

Se trata de probar el componente de software informático que opera dentro del entorno informático anfitrión/destino, simulando todo el sistema [otros CSC] y la funcionalidad de alto nivel.

Se centra en el comportamiento de un CSC en un entorno de host/objetivo simulado. El enfoque utilizado para la integración de software puede ser incremental (de arriba hacia abajo, de abajo hacia arriba o una combinación de ambos, también conocido como enfoque sándwich o híbrido).

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

Una vez definidos el enfoque y las dos variantes de integración, la pregunta que queda es cuándo puede comenzar y cuándo puede terminar un equipo. Generalmente, 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 Examen de la unidad

Entradas:

• Datos de requisitos de software
• Documento de diseño de software
• Plan de verificación de software
• Documentos de integración de software

Actividades

• Basado en los requisitos de alto y bajo nivel, cree casos y procedimientos de prueba.
• Combine compilaciones de módulos de bajo nivel que implementen 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.

Criterios de salida:

• Finalización exitosa de la integración del módulo de Software en el Hardware de destino.
• Correcto funcionamiento del software según los requisitos especificados

Resultados

• Informes de prueba de integración
• Procedimientos y casos de prueba de software [SVCP].

Desafíos comunes en las pruebas de integración de sistemas

Incluso con un enfoque sólido y criterios de salida claros, los entornos integrados generan problemas que nunca se manifiestan durante las pruebas unitarias. Detectarlos a tiempo permite mantener un cronograma realista.

• Desajuste ambiental: el integrado entorno de prueba Rara vez reproduce fielmente la producción, por lo que los defectos de sincronización y configuración pasan desapercibidos hasta muy tarde.
• Preparación para la dependencia: Las interfaces de terceros y las heredadas a menudo están incompletas, lo que obliga a los evaluadores a depender de simulaciones y prototipos durante mucho más tiempo del previsto.
• Inconsistencia de datos: Dos módulos pueden representar el mismo registro de forma diferente, produciendo discrepancias silenciosas en lugar de fallos visibles.
• Propiedad del defecto: cuando un fallo afecta a dos equipos, el análisis de la causa raíz y gestión de defectos Disminuir la velocidad notablemente.
• Costo de regresión: Cada nueva interfaz amplía la pruebas de regresión suite, por lo que la reejecución manual se vuelve rápidamente insostenible.

La mayoría de estos problemas son riesgos de cronograma, más que callejones sin salida técnicos. Acordar las fechas de disponibilidad de la interfaz, el alcance del simulador y la responsabilidad de la clasificación de defectos antes de integrar la primera versión elimina la mayoría de ellos. Para las interfaces propiedad del proveedor, también es importante registrar el formato de mensaje acordado y un contacto para escalar el problema, ya que la ausencia de un responsable retrasa la solución más de lo necesario.

Mejores prácticas para pruebas de integración de sistemas

Un ciclo SIT repetible depende menos de las herramientas que de la disciplina en torno a las interfaces, los datos y la evidencia. Las cinco prácticas que se describen a continuación son igualmente adecuadas para un pequeño proyecto integrado y un entorno multivendedor extenso, y cada una reduce el retrabajo necesario en las fases posteriores de las pruebas.

1. Primero, mapea todas las interfaces. Antes de escribir un solo caso de prueba, enumere cada intercambio de datos, su dirección, protocolo y propietario.
2. Priorizar según el riesgo. Verifique primero las interfaces que manejan dinero, identidad o datos regulados, antes que las de carácter estético.
3. Diseñar datos de prueba realistas. Cubra los rangos normales, límite y anormales para que los errores de escala y redondeo se manifiesten cuanto antes.
4. Automatice las rutas estables. La interfaz de cable comprueba en un integración continua canalización para que cada compilación los vuelva a verificar.
5. mantener evidencia traccapaz. Vincula cada resultado a un requisito a través de un tracmatriz de habilidades De este modo, los criterios de salida pueden probarse, no afirmarse.

⚠ Consejo: Congele las especificaciones de la interfaz antes de que comience la integración. Un cambio tardío en el formato de un mensaje invalida los casos de prueba en ambos lados de la interfaz y es la causa más común de reelaboración de las pruebas de integración del sistema (SIT).

Preguntas Frecuentes