¿Qué son las pruebas integradas en las pruebas de software?
Tomas Hamilton
⚡ Resumen inteligente
Las pruebas integradas comprueban el comportamiento funcional y no funcional del software y el hardware de forma conjunta, ya que en un sistema integrado ambos están estrechamente acoplados y ninguno puede validarse adecuadamente por sí solo.
¿Qué son los sistemas integrados?
Los sistemas embebidos Los sistemas embebidos son dispositivos controlados electrónicamente donde el software y el hardware están estrechamente integrados. Pueden contener diversos dispositivos informáticos. Se trata de ordenadores personales incorporados en otros dispositivos para ejecutar funciones específicas de la aplicación. El usuario final generalmente ni siquiera es consciente de su existencia.
Pruebas integradas
Pruebas integradas es un proceso de prueba para verificar la funcionalidad y no funcional Las pruebas de sistemas embebidos evalúan los atributos tanto del software como del hardware, y garantizan que el producto final esté libre de defectos. Su principal objetivo es verificar y validar si el producto final, que integra hardware y software, cumple con los requisitos del cliente.
Las pruebas de software embebido verifican y garantizan que el software en cuestión sea de buena calidad y cumpla con todos los requisitos. Estas pruebas son un excelente método para garantizar la seguridad en aplicaciones críticas como equipos médicos, ferrocarriles, aviación, industria automotriz, etc. Las pruebas rigurosas y minuciosas son cruciales para obtener la certificación del software.
Cómo realizar pruebas de software integrado
En general, realiza la prueba por cuatro razones:
- Para encontrar errores en el software
- Ayuda a reducir el riesgo tanto para los usuarios como para la empresa.
- Reducir los costos de desarrollo y mantenimiento.
- Para mejorar el rendimiento
En las pruebas integradas, se realizan las siguientes actividades:
- El software se proporciona con algunos datos de entrada.
- Se ejecuta una parte del software.
- Se observa el estado del software y se comprueba que los resultados posean las propiedades esperadas, como por ejemplo si el resultado coincide con el resultado previsto, si cumple con los requisitos y si no se producen fallos del sistema.
Tipos de pruebas de software integrado
Fundamentalmente, existen cinco niveles de prueba que se pueden aplicar al software embebido.
Pruebas unitarias de software
El módulo unitario puede ser una función o una clase. Las pruebas unitarias las realiza el equipo de desarrollo, principalmente el desarrollador, y generalmente se llevan a cabo mediante un modelo de revisión por pares. Los casos de prueba se desarrollan en función de la especificación del módulo.
Pruebas de integración
Pruebas de integración se puede clasificar en dos segmentos:
- Pruebas de integración de software
- Pruebas de integración de software/hardware
Finalmente, se prueba la interacción entre el hardware y los componentes de software. Esto puede incluir el análisis de la interacción entre los dispositivos periféricos integrados y el software.
El desarrollo de software embebido tiene una característica única: el entorno real en el que se ejecuta el software generalmente se crea en paralelo con el software. Esto genera inconvenientes para las pruebas, ya que no es posible realizar pruebas exhaustivas en un entorno simulado.
Pruebas de unidades del sistema
Ahora el módulo a probar es un marco completo que consta del código de software completo más todo sistema operativo en tiempo real (RTOS) y componentes relacionados con la plataforma, como interrupciones, mecanismos de asignación de tareas, comunicaciones, etc. El protocolo de punto de control ya no es una llamada a una función o una invocación de método, sino un mensaje enviado o recibido mediante las colas de mensajes del RTOS.
Se observan los recursos del sistema para evaluar la capacidad del sistema para soportar la ejecución del sistema integrado. Para este aspecto, pruebas de caja gris es el método de prueba preferido. Dependiendo de la organización, las pruebas unitarias del sistema son responsabilidad del desarrollador o de un equipo de integración de sistemas especializado.
Pruebas de integración del sistema
El módulo que se va a probar parte de un conjunto de componentes dentro de un único nodo. Los Puntos de Control y Observación (PCO) son una combinación de protocolos de comunicación relacionados con la red y eventos del RTOS, como mensajes de red. Además de un componente, un probador virtual también puede funcionar como un nodo.
Pruebas de validación del sistema
El módulo que se va a probar es un subsistema con una implementación completa o el sistema embebido completo. El objetivo de esta prueba final es cumplir con los requisitos funcionales de la entidad externa. Cabe destacar que una entidad externa puede ser una persona, un dispositivo en una red de telecomunicaciones o ambos.
Diferencia: pruebas integradas y pruebas de software
La tabla siguiente compara las pruebas integradas con las convencionales. pruebas de software.
| Pruebas de software | Pruebas integradas |
|---|---|
| Las pruebas de software están relacionadas únicamente con el software. | Las pruebas integradas están relacionadas tanto con el software como con el hardware. |
| En promedio, el 90% de las pruebas que se realizan en el mundo son puramente manuales. prueba de caja negra. | Las pruebas integradas se realizan en sistemas o chips integrados, y pueden ser de caja negra o pruebas de caja blanca. |
| Las áreas principales de prueba son comprobaciones de GUI, funcionalidad, validación y algún nivel de prueba de bases de datos. | Las principales áreas de prueba son el comportamiento del hardware en función del número de entradas que se le proporcionan. |
| Las pruebas de software se realizan principalmente en aplicaciones cliente-servidor, web y móviles. | Las pruebas integradas generalmente se realizan en el hardware. |
| e.g., Google Mail, Yahoo Mail, Android aplicaciones. | Por ejemplo, máquinas del sector sanitario, microcontroladores utilizados en ordenadores. |
Desafíos: pruebas de software integrado
Algunos de los desafíos que se pueden presentar durante las pruebas de software embebido:
Dependencia de hardware
La dependencia del hardware es una de las principales dificultades que se presentan durante las pruebas de software embebido, debido al acceso limitado al hardware. Sin embargo, los emuladores y simuladores pueden no representar con precisión el comportamiento del dispositivo real y podrían generar una percepción errónea del rendimiento del sistema y la usabilidad de la aplicación.
Software de código abierto
La mayoría de los componentes de software embebido son de código abierto, no se desarrollan internamente y no disponen de un conjunto completo de pruebas. Existe una amplia gama de combinaciones de pruebas y escenarios resultantes.
Defectos de software versus hardware
Otro aspecto a considerar es el desarrollo de software para hardware de reciente creación. Durante este proceso, se puede detectar una alta tasa de defectos de hardware. Estos defectos no se limitan al software, sino que también pueden estar relacionados con el hardware.
Defectos reproducibles
En el caso de un sistema embebido, los defectos son más difíciles de reproducir o recrear. Esto obliga al procedimiento de prueba a valorar cada aparición de defectos considerablemente más que en un caso estándar, y a recopilar la mayor cantidad de datos razonablemente necesarios para encontrar la causa raíz del defecto.
Actualizaciones continuas de software
Los sistemas embebidos requieren actualizaciones de software periódicas, como actualizaciones del kernel, correcciones de seguridad, controladores de dispositivos, etc. Las limitaciones asociadas a las actualizaciones de software dificultan la identificación de errores. Además, esto aumenta la importancia del proceso de compilación e implementación.
