Automatización de pruebas con hardware integrado

Question

¿Alguien ha tenido éxito al automatizar las pruebas directamente en hardware integrado?

En concreto, estoy pensando en automatizar una batería de pruebas unitarias para módulos de capa de hardware.Necesitamos tener una mayor confianza en nuestro código de capa de hardware.Muchos de nuestros proyectos utilizan temporizadores controlados por interrupciones, ADC, io serie, dispositivos SPI serie (memoria flash), etc.

¿Vale la pena el esfuerzo?

Normalmente nos dirigimos a:

Procesador:Microcontroladores de 8 o 16 bits (algunos elementos DSP)
Idioma:C (a veces c++).

Answer 1

Seguro.En la industria automotriz utilizamos probadores personalizados de $100,000 para cada producto nuevo para verificar que el hardware y el software estén funcionando correctamente.

Sin embargo, los desarrolladores también construyen un probador más económico (menos de $1000) que incluye un montón de E/S USB, A/D, entrada/salida PWM, etc. y utiliza secuencias de comandos en la estación de trabajo o software de prueba HIL/SIL especialmente diseñado. como por ejemplo MxVDev.

Probablemente lo que quiere decir es prueba de hardware en el bucle (HIL), y simplemente implica algunas E/S de hardware USB conectadas a las E/S de su dispositivo, con el software en la computadora ejecutando pruebas.

Si vale la pena depende.

En la industria de alta confiabilidad (aviones, automóviles, etc.), el cliente especifica pruebas de hardware muy exhaustivas, por lo que es necesario tenerlo solo para obtener la oferta.

En el sector de consumo, con proyectos no complejos normalmente no merece la pena.

Sin embargo, en cualquier proyecto en el que haya más de unos pocos programadores involucrados, es en realidad Es bueno ejecutar una prueba de regresión nocturna en el hardware; es difícil simular correctamente el hardware en el grado necesario para asegurarse de que las pruebas de software son suficientes.

Luego, la prueba muestra inmediatamente cuando un problema ha ingresado a la compilación.

Por lo general, realiza pruebas de caja negra y de caja blanca: tiene un código de diagnóstico ejecutándose en el dispositivo que le permite espiar las señales y la memoria en el hardware (lo que podría ser simplemente un depurador o un código que usted escribió y que reacciona a los mensajes en un autobús, por ejemplo).Esto sería una prueba de caja blanca donde se puede ver lo que sucede internamente (e incluso hacer que sucedan algunas cosas, como errores críticos de memoria que no se pueden probar sin introducir el error usted mismo).

También ejecutamos una serie de pruebas de "caja negra" en las que se ignora la ruta de diagnóstico y solo se estimula/lee la E/S.

Para una configuración mucho más económica, puede obtener placas de microcontrolador de $100 con USB y/o Ethernet (como la familia Atmel UC3) que puede conectar a su dispositivo y ejecutar pruebas básicas.

Es especialmente útil para el mantenimiento del producto: cuando el proyecto esté terminado, almacene algunas placas de trabajo, el probador y un conjunto completo de software en un CD.Cuando necesita realizar una modificación o depurar un problema, es fácil configurarlo todo de nuevo y trabajar en ello sabiendo (después de probar) que la funcionalidad principal no se vio afectada por sus cambios.

-Adán

Answer 2

Sí.He tenido éxito, pero no es un problema sencillo de resolver.En pocas palabras, esto es lo que hizo mi equipo:

1. Definí una variedad de pruebas unitarias utilizando un marco de pruebas unitarias C construido en casa.Básicamente, sólo un montón de macros, la mayoría de las cuales fueron nombradas TEST_EQUAL, TEST_BITSET, TEST_BITVLR, etc.

2. Escribí un generador de código de arranque que tomó estas pruebas compiladas y las orquestó en un entorno de ejecución.Es sólo un pequeño controlador que ejecuta nuestra rutina de inicio normal, pero en lugar de entrar en el bucle de control, ejecuta un conjunto de pruebas.Cuando termina, almacena el último paquete que se ejecutó en la memoria flash y luego reinicia la CPU.Luego se ejecutará la siguiente suite.Esto es para proporcionar aislamiento en caso de que una suite muera.(Sin embargo, es posible que desees desactivar esto para asegurarte de que tus módulos cooperen.Pero esa es una prueba de integración, no una prueba unitaria).

3. Las pruebas individuales registrarían su salida utilizando el puerto serie.Esto estaba bien para nuestro diseño porque el puerto serie estaba libre.Tendrás que encontrar una manera de almacenar tus resultados si se consume todo tu IO.

¡Funcionó!Y fue genial tenerlo.Usando nuestro registrador de datos personalizado, puede presionar el botón "Probar" y, un par de minutos más tarde, tendrá todos los resultados.Lo recomiendo altamente.

Actualizado para aclarar cómo funciona el conductor de pruebas.

Answer 3

Sí.

La dificultad depende del tipo de hardware que intentas probar.Como ya han dicho otros, la cuestión será la complejidad del estímulo externo que hay que aplicar.El estímulo externo probablemente se logre mejor con algún banco de pruebas externo (como lo ha descrito Adam Davis).

Sin embargo, una cosa a considerar es exactamente qué es lo que estás tratando de verificar.

Es tentador suponer que para verificar la interacción del hardware y el firmware realmente no tienes otra opción que aplicar directamente un estímulo externo (es decir,aplicar DAC a todas las entradas de su ADC, etc.).En estos casos, sin embargo, los casos extremos que realmente desea probar a menudo estarán sujetos a cuestiones de tiempo (por ejemplo,interrupciones que llegan cuando estás ejecutando la función foo()) que serán increíblemente difíciles de probar de manera significativa, y aún más difíciles de obtener resultados significativos.(es decir.Las primeras 100.000 veces que realizamos esta prueba estuvo bien.La última vez que lo ejecutamos falló.¿¡¿Por qué?!?)

Pero la verificación del hardware debe realizarse por separado.Una vez hecho esto, a menos que cambie regularmente (a través de imágenes fpga descargables o similares), entonces debería poder asumir que el hardware funciona y simplemente probar su firmware.

Entonces, en este caso, puede concentrarse en verificar los algoritmos que se utilizan para procesar sus estímulos externos.Por ejemplo, llamar a sus rutinas de conversión de ADC con un valor fijo como si vinieran directamente de su ADC.Estas pruebas son repetibles y, por lo tanto, beneficiosas.Sin embargo, requerirán versiones de prueba especiales.

Probar las rutas de comunicación de su dispositivo será relativamente sencillo y no debería requerir compilaciones de código especiales.

Answer 4

Hemos obtenido buenos resultados con las pruebas automatizadas en nuestros sistemas integrados.Contamos con pruebas escritas en lenguajes de alto nivel (fáciles de programar y depurar) que se ejecutan en máquinas de prueba dedicadas.Estas pruebas generalmente verifican la cordura o generan entradas aleatorias en los dispositivos y luego verifican el comportamiento correcto.Hay mucho trabajo para generar y mantener estas pruebas.Diseñamos un marco y luego dejamos que los pasantes trabajaran en las pruebas ellos mismos.

No es una solución perfecta y las pruebas ciertamente son propensas a errores, pero la parte más importante es mejorar los agujeros de cobertura existentes.Encuentre el agujero más grande y diseñe algo para cubrirlo de forma automática, incluso si no es perfecto o no cubre toda la característica.Más adelante, cuando todas sus cosas estén un poco cubiertas, puede regresar y abordar la peor cobertura o las características más críticas.

Algunas cosas a considerar:

• ¿Cuál es la penalización por un error de firmware?¿Qué tan fácil es actualizar el firmware en el campo?
• ¿Qué tipo de cobertura proporciona mi prueba?¿Es una simple comprobación de cordura?¿Es lo suficientemente configurable como para poder probar muchos escenarios diferentes?
• Una vez que una prueba falla, ¿cómo reproducirá ese valor para depurarlo?¿Registraste todas las configuraciones del dispositivo y las pruebas para poder eliminar tantas variables como sea posible?¿Configuración del dispositivo, versión de firmware, versión de software de prueba, todas las entradas externas, todo el comportamiento observado?
• ¿Contra qué estás probando?¿La especificación es lo suficientemente clara sobre cuál es el comportamiento esperado del dispositivo que está probando o está validando lo que cree que debería hacer el código?

Answer 5

Si su objetivo es probar su código de controlador de bajo nivel, probablemente necesitará crear algún tipo de dispositivo de prueba, utilizando cables loopback o múltiples unidades interconectadas para permitirle ejercitar cada controlador.Emparejar una placa con software en buen estado con una placa que ejecuta una compilación de desarrollo le permitirá probar regresiones en los protocolos de comunicación, etc.

Las estrategias de prueba específicas dependen del hardware que desee probar.Por ejemplo, los ADC se pueden probar presentando una forma de onda conocida y convirtiendo una serie de muestras, luego verificando el rango, la frecuencia, el valor promedio, etc. adecuados.

En el pasado, he descubierto que este tipo de pruebas son muy valiosas, ya que me permiten modificar y mejorar con confianza el código del controlador sin temor a dañar las aplicaciones existentes.

Answer 6

Sí, hago esto, aunque siempre he tenido un puerto serie disponible para E/S de prueba.

Con frecuencia es difícil salir de la unidad. totalmente sin modificar.Algunas pruebas requieren una línea comentada o una llamada agregada, p.tratar con un perro guardián.

En mi humilde opinión, esto es mejor que ninguna prueba unitaria.Y, por supuesto, también debe realizar pruebas completas de integración/sistema.

Answer 7

Las pruebas unitarias de proyectos integrados son bastante difíciles, ya que generalmente requieren un estímulo externo y una medición externa.

Hemos tenido éxito en el desarrollo de un protocolo serial externo (mensajes rs232 o udp o tcpip) con comandos básicos para ejercitar el hardware con el registro de depuración en los controladores de bajo nivel en busca de condiciones erróneas o incluso condiciones levemente anormales (especialmente para verificación de límites).

Pero una vez desarrollado, podemos ejecutar las pruebas después de cada compilación si es necesario.Definitivamente le permitirá entregar un producto de mejor calidad.

Answer 8

Sé que esto ya es viejo, pero tal vez ayude.Sí, puedes hacerlo pero depende de cuánto quieras invertir en la solución que deseas.Más de dos años he trabajado en pruebas y validación para la capa MCAL de AUTOSAR.Esto es lo más bajo que puede obtener cuando se trata de pruebas de software.Fue una especie de prueba a nivel de componentes.Algunos pueden llamarlo nivel de unidad, pero era un poco más alto porque estábamos probando las API de los componentes de MCAL.Cosas como:ADC, SPI, UCI, DIO, etc.

La solución utilizada implicó:- Un marco de prueba que se ejecutaba en el Micro de destino, un cuadro Dspace para proporcionar y leer señales hacia y desde el objetivo cuando sea necesario: acceso XCP a través de Vector Canape para activar la ejecución de la prueba y la recopilación de resultados - un marco de Python para realizar el control de prueba y validación de los resultados

Los casos de prueba se escribieron en C y se mostraron en el objetivo junto con el software bajo prueba.Fue una prueba de caja negra porque no alteramos de ninguna manera la implementación de la MCAL.Y creo que ni siquiera se tocó la secuencia de inicio.Se utilizó una tarea inactiva para verificar continuamente el estado de una bandera que era la señal para comenzar a ejecutar una prueba.Se utilizó una tarea de 10 ms para ejecutar la prueba.En realidad, un caso de prueba era un caso de cambio.Cada caso en este cambio fue un paso de prueba.Python estaba activando la ejecución de la prueba en el nivel del paso de prueba.Lo bueno de este enfoque fue la reutilización de pasos con diferentes parámetros.Python realizó este control de prueba, qué ejecutar y cómo, a través de una estructura de datos de control de prueba que actúa como una API entre la implementación de la prueba y el mecanismo de evaluación y activación de la prueba.Para esto se utilizó CANape.Para configurar la prueba a ejecutar y leer los resultados de la prueba.Cada valor obtenido en un paso de prueba se almacenó en una matriz que forma parte de la estructura de datos.El paso de prueba en sí no estuvo involucrado en ninguna validación porque el objetivo se consideraba un componente no confiable del entorno de prueba.La validación fue realizada por Python según las especificaciones de la prueba.Python estaba analizando estas especificaciones y pudo crear automáticamente scripts de activación de pruebas, incluidos los criterios de validación para cada paso de la prueba.La especificación de cada caso de prueba fue una serie de descripciones de pasos de prueba junto con sus criterios de validación.Algunos de estos pasos estaban relacionados con dSPACE.Como ejemplo, un paso era inicializar algo y requería capturar algunos bordes en un canal ya configurado, y el siguiente paso era aplicar la señal en ese canal comandando el equipo dSPACE.

Una solución más económica implicaría utilizar una placa interna en lugar del equipo dSPACE.Hasta cierto punto, incluso se puede utilizar un generador de señales programable, pero eso no ayudaría si necesita validar las señales emitidas por el objetivo.

Answer 9

Si su objetivo es la prueba de fabricación (asegurarse de que los módulos estén ensamblados correctamente, sin cortocircuitos/aperturas/etc. involuntarios), debe concentrarse primero en probar los cables y conectores, seguido de las conexiones enchufadas y soldadas, y luego la PCB en sí.Todos estos elementos se pueden probar para detectar cortocircuitos y aperturas encontrando patrones de acceso que elevan cada línea individual mientras que sus vecinas están bajas y viceversa, y luego leen los valores de las líneas.

Sin conocer más detalles de su hardware, es difícil ser más específico, pero la mayoría de los procesadores integrados pueden configurar los pines de E/S en un modo GPIO que simplifica este tipo de pruebas.

Si no realiza pruebas de base de clavos en sus PCA, estas pruebas deben considerarse un primer paso obligatorio para las placas recién fabricadas.