¿Qué es el ejemplo de prueba de integración de sistemas (SIT)?
Tomas Hamilton
¿Qué son las pruebas de integración de sistemas?
System 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 de sistemas (SIT) se realizan 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 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é 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.
Cómo realizar pruebas de integración del sistema
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 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. Veremos más detalles sobre el 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 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 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 integración de software En el entorno del host dependerá de cuánta funcionalidad específica del objetivo exista. Para algunos sistemas integrados, el acoplamiento con el entorno de destino será muy fuerte, lo que hará que no sea práctico realizar la integración de software en el entorno del host.
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].
Criterios de entrada y salida para las pruebas de integración
Por lo general, al realizar las pruebas de integración, se utiliza la estrategia ETVX (criterios de entrada, tareas, 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
Algunas de las numerosas actividades incluyen:
- 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
Recursos
- Informes de prueba de integración
- Procedimientos y casos de prueba de software [SVCP].
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
Es la prueba del componente de software de la computadora que opera dentro de la computadora host/destino.
Entorno, mientras se simula todo el sistema [otros CSC] y la funcionalidad de alto nivel.
Se centra en el comportamiento de un CSC en un entorno de host/destino 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).
Enfoque incremental
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:
- 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.
- Los talones subordinados se reemplazan uno a la vez con módulos reales dependiendo del enfoque seleccionado (primero la anchura o primero la profundidad).
- Las pruebas se ejecutan a medida que se integra cada módulo.
- Al finalizar cada conjunto de pruebas, se reemplaza otro trozo con un módulo real al finalizar cada conjunto de pruebas.
- 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.
- Los módulos de bajo nivel se combinan en grupos que realizan una subfunción de software específica.
- Un controlador está escrito para coordinar la entrada y salida del caso de prueba.
- Se prueba el clúster o la compilación.
- 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, se hace más necesaria la impartición de clases separadas para los pilotos de pruebas. De hecho, si los dos niveles superiores de la estructura del programa se integran de arriba hacia abajo, se puede reducir sustancialmente la cantidad de pilotos y se simplifica enormemente la integración de los clústeres. La integración sigue el patrón que se ilustra a continuación. A medida que la integración avanza hacia arriba, se hace más necesaria la impartición de clases separadas para los pilotos 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 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.
Resum
- La integración se realiza para verificar las interacciones entre los módulos de un sistema de software. Ayuda a detectar defectos temprano.
- Se pueden realizar pruebas de integración para la integración Hardware-Software o Hardware-Hardware.
- Las pruebas de integración se realizan mediante dos métodos.
- Enfoque incremental
- Enfoque del big bang
- Al realizar pruebas de integración, generalmente se utiliza la estrategia ETVX (criterios de entrada, tareas, validación y criterios de salida).
