Herramientas de prueba para pruebas integradas

Los sistemas de aplicación de sistemas de destino en el campo integrado son cada vez más complejos y la competencia requiere que los productos se introduzcan rápidamente en el mercado. La tecnología se desarrolla cada día. El hardware se vuelve cada vez más estable y, por otro lado, las fallas del software son cada vez más comunes. La importancia del software ha atraído gradualmente la atención de la gente y cada vez más personas se han dado cuenta de que las pruebas de los sistemas integrados son imperativas. Cuando se trata de probar software integrado, primero debemos presentar brevemente algunos puntos de vista de la ingeniería de software. Ahora, la definición generalmente aceptada de software es: el software es otra parte del sistema informático que es interdependiente con el hardware e incluye el programa (. programa), datos relacionados (datos) y su documentación (documento). Entre ellos, el programa es una secuencia de instrucciones ejecutadas de acuerdo con requisitos funcionales y de rendimiento prediseñados; los datos son la estructura de datos de información que el programa puede operar normalmente; los documentos son información gráfica diversa relacionada con el desarrollo, mantenimiento y uso del programa; .

Para las pruebas de software comercial general, las pruebas de software integrado tienen sus propias características y dificultades de prueba.

Debido a las características de los sistemas integrados, como tiempo real (Real-timing), memoria insuficiente, canales de E/S pequeños, herramientas de desarrollo costosas y varios tipos de CPU que están estrechamente relacionados con el hardware. . El desarrollo y las pruebas de software integrado son muy diferentes de las estrategias de desarrollo y pruebas del software comercial general. Se puede decir que el software integrado es el tipo de software más difícil de probar.

Adoptar estrategias de prueba efectivas para las pruebas de software integrado es la única salida, que puede maximizar la eficiencia del desarrollo, evitar cuellos de botella en el sistema de destino y utilizar emuladores en línea para ahorrar costosos recursos de destino. Desde la llegada de los lenguajes de alto nivel, a menudo ha habido una diferencia entre el entorno de desarrollo y el entorno de ejecución final, y esto es especialmente cierto para los sistemas integrados. El entorno de desarrollo se considera la plataforma anfitriona, mientras que el entorno de ejecución del software es la plataforma de destino.

La discusión sobre las pruebas de software integrado comienza con la pregunta: ¿Por qué no realizar todas las pruebas en la plataforma de destino? Porque si todas las pruebas se realizan en la plataforma de destino, habrá muchas desventajas:

1) Las pruebas de software pueden causar cuellos de botella y competir con los desarrolladores por el tiempo, y la única forma de evitar cuellos de botella es proporcionar más objetivos. ambiente.

2) Es posible que el entorno objetivo aún no sea viable.

3) Los entornos de destino suelen ser imprecisos e inconvenientes en comparación con los entornos de plataforma host.

4) Los entornos de destino y los entornos de codesarrollo proporcionados a los desarrolladores suelen ser costosos.

5) El trabajo de desarrollo y pruebas puede interferir con las aplicaciones en curso que ya existen en el entorno de destino.

Desde una perspectiva económica y de eficiencia del desarrollo, todos los ciclos de desarrollo de software probablemente deben realizarse en un gran porcentaje. llevado a cabo en un entorno de sistema host, incluidas las pruebas.

Después de determinar el entorno de prueba del host-objetivo, los evaluadores de desarrollo enfrentarán las siguientes preguntas:

1) ¿Cuántos desarrolladores participarán en el trabajo de prueba (pruebas unitarias, integración de software, pruebas del sistema)? ) ?

2) ¿Cuánto software hay que probar?

3) ¿Qué herramientas de software están disponibles en los entornos host y de destino?

4) ¿Cuántos entornos de destino puede utilizar un desarrollador y cuándo?

5) ¿Cómo es la conexión entre el host y el destino?

6) ¿Qué tan rápido es descargar el software de prueba al objetivo?

7) ¿Cuáles son las restricciones (por ejemplo, estándares de seguridad del software) entre el uso del host y el entorno de destino?

Las personas u organizaciones que realicen pruebas de software integrado deben considerar en profundidad los problemas anteriores y elegir estrategias y planes de prueba razonables basados ​​en sus propias condiciones reales.

Para las pruebas de software integrado o pruebas cruzadas, existe una estrategia común para todas las etapas de las pruebas: todas las pruebas a nivel de unidad se pueden realizar en el entorno host, excepto en algunos casos que especifican las pruebas unitarias directamente. en el entorno objetivo. Maximice la proporción de pruebas de software realizadas en el entorno host haciendo que la unidad de destino más pequeña posible acceda a todas las interfaces especificadas de destino.

Ejecutar pruebas en la plataforma host es mucho más rápido que en la plataforma de destino. Después de completar la prueba en la plataforma host, se puede repetir una prueba de verificación simple en el entorno de destino para confirmar que los resultados de la prueba no son los mismos. afectado por el anfitrión y el impacto de las diferencias entre objetivos.

Las pruebas de confirmación en el entorno de destino identificarán diferencias desconocidas, imprevistas y no especificadas entre las máquinas host y de destino. Por ejemplo, el compilador de destino puede tener errores que no están presentes en el compilador del host. La integración del software también se puede realizar en el entorno del host simulando el entorno de destino que se ejecuta en la plataforma del host. Por supuesto, es necesario realizar pruebas repetidas en el entorno de destino y las pruebas de confirmación en este nivel descubrirán algunos problemas ambientales, como la ubicación de la memoria. y algunos errores en la distribución.

El uso de pruebas de integración en un entorno host depende de cuánta funcionalidad es exclusiva del sistema de destino. Algunos sistemas integrados están estrechamente acoplados al entorno de destino, lo que hace que la integración en el entorno anfitrión no sea práctica. El desarrollo de un software a gran escala se puede dividir en varios niveles de integración. La integración de software de bajo nivel tiene grandes ventajas cuando se completa en la plataforma host. Cuanto más tarde es la integración, más depende del entorno de destino. Todas las pruebas del sistema y las pruebas de verificación deben realizarse en el entorno de destino. Por supuesto, también es conveniente desarrollar y ejecutar pruebas del sistema en la máquina host, luego trasplantarlas al entorno de destino y repetirlas. Las dependencias en el sistema de destino pueden impedir la transferencia de pruebas del sistema desde el entorno del host al sistema de destino y, dado que solo unos pocos desarrolladores participarán en las pruebas del sistema, a veces puede ser más conveniente renunciar a realizar pruebas del sistema en el entorno del host.

Confirme que la etapa final de ejecución de la prueba debe realizarse en el entorno de destino y que la verificación del sistema debe probarse en el sistema real en lugar de simularse en el entorno del host. Esto tiene que ver con el uso final del software integrado.

Las pruebas que incluyen pruebas de recuperación, pruebas de seguridad, pruebas de resistencia y pruebas de rendimiento están fuera del alcance de las pruebas de software y no se analizarán en este artículo.

Adoptar una estrategia de pruebas cruzadas eficaz puede mejorar en gran medida el nivel y la eficiencia del desarrollo y las pruebas de software integrado. Por supuesto, el uso correcto de las herramientas de prueba también es esencial:

Resumen. Las aplicaciones de las herramientas de prueba anteriores son las siguientes:

(1) Realizar análisis de pruebas estáticas y prepararse para insertar código de software para pruebas de cobertura dinámica.

B) Utilizar código fuente para realizar pruebas funcionales en el entorno host y corregir defectos y errores de software en los scripts de prueba.

C) Realice pruebas de cobertura utilizando código de software insertado, agregue casos de prueba o corrija errores de software para garantizar que se logren los objetivos de cobertura requeridos.

D) Repita (B) en el entorno de destino para confirmar que el software realiza la prueba correctamente en el entorno de destino.

E) Si la prueba necesita alcanzar un nivel extremadamente alto de integridad, es mejor repetir (C) en el sistema de destino para garantizar que la cobertura del software no cambie.

Normalmente, la mayoría de las pruebas se realizan en el entorno host y solo se trasplantan al entorno de destino después de que se finalizan los resultados de las pruebas y las pruebas finales del sistema. Esto puede evitar problemas al acceder a los recursos del sistema de destino y reducir los gastos. en recursos costosos como emuladores en línea. Además, si el hardware del sistema de destino no está disponible por algún motivo, las pruebas de validación finales se pueden aplazar hasta que el hardware de destino esté disponible, lo que proporciona flexibilidad en el desarrollo y las pruebas del software integrado. Diseñar software para que sea portátil es un requisito previo para el éxito de las pruebas cruzadas, que generalmente mejoran la calidad del software y facilitan su mantenimiento. Todas las herramientas de prueba mencionadas anteriormente brindan portabilidad de prueba entre las máquinas host y de destino a su manera, lo que facilita la prueba del software integrado.

El uso de estrategias efectivas de pruebas cruzadas puede mejorar en gran medida el nivel y la eficiencia del desarrollo y las pruebas de software integrado, y mejorar la calidad del software integrado.

Apéndice:

1). Introducción al método de conexión HOST-TARGET:

Figura 1: conexión directa

Figura 2: Conexión a través del emulador

Figura 3 - Conexión indirecta usando medios

Figura 4 - Entrega del software bajo prueba usando PROM, etc.

Figura 5 - Uso de la interfaz interactiva para realizar pruebas

Figura 6: sin conexión a la interfaz interactiva