¿Qué es el ejemplo de prueba de integración de sistemas (SIT)? (2023)

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

SistemaPruebas de integraciónse 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. Es una prueba realizada 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 trata 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 haya integrado todo el sistema.

¿Por qué hacer pruebas de integración de sistemas?

En Ingeniería de Software, las Pruebas de Integración de Sistemas se realizan porque,

• Ayuda a detectarDefectotemprano
• Se dispondrá de comentarios anteriores sobre la aceptabilidad del módulo individual.
• La programación de 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
• Correcto con los requisitos de software

Cómo hacer 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 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. Veremos más detalles sobre un enfoque incremental más adelante en el tutorial.

Existen algunos métodos incrementales, como las pruebas de integración que se realizan en un sistema basado en el procesador de destino. La metodologa utilizada esPruebas de caja negra. Se puede utilizar la integración de abajo hacia arriba o de arriba hacia abajo.

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 la 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 llevar a cabo la integración de software en el entorno del host dependerá de cuánta funcionalidad específica de destino haya. Para algunos sistemas integrados, el acoplamiento con el entorno de destino será muy fuerte, lo que hará que sea poco práctico llevar a cabo la integración del software en el entorno del 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 host, y los niveles posteriores de integración de software se volverían más dependientes del entorno de destino.

Nota:Si solo se prueba el software, se denomina Prueba de integración de software y software [SSIT] y si se prueban 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 las pruebas de integración, se utiliza la estrategia ETVX (Criterios de entrada, Tarea, Validación y Criterios de salida).

Criterio para entrar:

• Finalización deExamen 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 de prueba y procedimientos
• Combine compilaciones de módulos de bajo nivel que implementen una funcionalidad común
• Desarrollar un arnés de prueba
• Probar 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
• Correcto desempeño del software de acuerdo a los requerimientos especificados

Salidas

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

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 en la computadora de destino satisfará 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 una prueba integrada
• Respuesta incorrecta a fallas de hardware
• Error debido a secuencias, cargas de entrada transitorias y transitorios de potencia de entrada
• Bucles de retroalimentación comportamiento incorrecto
• Control incorrecto o inadecuado del hardware de administración de memoria
• Problema de contención del bus de datos
• Operación incorrecta del mecanismo para verificar la compatibilidad y exactitud del software cargable en el campo

La integración de hardware y software se ocupa de la verificación de los requisitos de alto nivel. Todas las pruebas en 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 el hardware estándar de producción (en el destino)

Aspectos a tener en cuenta al diseñar casos de prueba para la integración HW/SW

• Adquisición correcta de todos los datos por parte del software.
• Escalamiento y rango 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 especificaciones (rango anormal)
• Datos de límite
• Procesamiento de interrupciones
• Momento
• Uso correcto de la memoria (direccionamiento, superposiciones, etc.)
• transiciones de estado

Nota:Para la prueba de interrupciones, todas las interrupciones se verificarán independientemente desde la solicitud inicial hasta el servicio completo y hasta la 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 de computadora que opera dentro de la computadora host/objetivo

Entorno, mientras simula todo el sistema [otros CSC], y en 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 un enfoque incremental (de arriba hacia abajo, un enfoque 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 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 cada vez más bajas 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 manera prioritaria en anchura o en profundidad.
• La integración primero 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 stubs se sustituyen por todos los módulos directamente subordinados al módulo de control principal.
2. Los stubs subordinados se reemplazan uno a la vez con módulos reales según el enfoque seleccionado (primero el ancho o primero la profundidad).
3. Las pruebas se ejecutan a medida que se integra cada módulo.
4. Al completar cada conjunto de pruebas, otro stub se reemplaza con un módulo real al completar cada conjunto de pruebas
5. Para asegurarse de que no se han introducido nuevos erroresPruebas de regresiónse 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 suena relativamente sencilla, pero en la práctica surgen problemas logísticos.

El más común de estos problemas ocurre cuando se requiere el 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, ningún dato significativo puede fluir hacia arriba en la estructura del programa.

Desafíos que puede enfrentar Tester:

• 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 parte inferior de la jerarquía hacia arriba.

Nota:El primer enfoque nos hace perder algo de 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 limitada del enfoque de arriba hacia abajo.

El segundo enfoque es factible, 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 stubs.

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. Se escribe un controlador para coordinar la entrada y salida del caso de prueba.
3. Se prueba el clúster o la compilación.
4. Los controladores se eliminan y los grupos se combinan moviéndose hacia arriba en la estructura del programa.

A medida que la integración avanza, surge la necesidad de lecciones separadas para los conductores de pruebas. De hecho, 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 los clústeres se simplifica en gran medida. La integración sigue el patrón ilustrado a continuación. A medida que la integración avanza, surge la necesidad de lecciones separadas para los conductores de pruebas.

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 están integrados hasta que todos los módulos estén listos. Una vez que están listos, todos los módulos se integran y luego se ejecutan para saber si todos los módulos integrados funcionan o no.

En este enfoque, es difícil conocer la causa raíz de la falla debido a la integración de todo a la vez.

Además, habrá una alta probabilidad de que ocurran 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 defectos 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 de gran explosión
• Al realizar las Pruebas de Integración, generalmente se utiliza la estrategia ETVX (Criterios de Entrada, Tarea, Validación y Criterios de Salida).