Soy un ingeniero de software que/será contratado como ingeniero de pruebas de firmware. Solo quiero tener una idea de algunas herramientas de software disponibles en el mercado que se usan para probar el firmware. ¿Puede decirlos y explicar un poco sobre qué tipo de prueba proporcionan al firmware? Gracias por adelantado.¿Cuáles son algunas de las herramientas de software disponibles para probar el firmware hoy?
Las pruebas se presentan en diferentes formas y se pueden realizar en diferentes etapas. Además de la validación del diseño incluso antes de escribir el código, las pruebas de código se pueden dividir en pruebas unitarias, pruebas de integración, pruebas del sistema y pruebas de aceptación (aunque los términos exactos y el número de etapas pueden ser muy). En el modelo V, estos se corresponderían horizontalmente con las etapas en los requisitos y el desarrollo del diseño. También en desarrollo y mantenimiento puede realizar pruebas de regresión, asegurando que los errores fijos permanezcan fijos cuando se aplican otros cambios.
En lo que respecta a las herramientas, estas se pueden dividir en análisis estáticos y análisis dinámicos. Las herramientas estáticas analizan el código fuente sin ejecución, mientras que el análisis dinámico se refiere al comportamiento del código durante la ejecución. Algunas herramientas (costosas) realizan "ejecución abstracta", que es una técnica de análisis estático que determina cómo el código puede fallar durante la ejecución sin ejecución real. Este enfoque es computacionalmente costoso pero puede procesar muchas más rutas de ejecución y estados variables que el análisis dinámico tradicional.
La forma más simple de análisis estático es la revisión del código; hacer que un humano lea tu código Hay herramientas para ayudar incluso con este proceso ostensiblemente manual como SmartBear's Code Collaborator. Del mismo modo, la forma más simple de análisis dinámico es simplemente pasar por su código en su depurador o incluso simplemente ejecutar su código con varios escenarios de prueba. La primera puede ser realizada por un programador durante el desarrollo de la unidad y la depuración, mientras que la segunda es más adecuada para las pruebas de aceptación o integración.
Si bien la revisión del código bien hecha puede eliminar una gran cantidad de errores, especialmente errores de diseño, tal vez no sea tan eficaz al encontrar ciertos tipos de errores causados por la semántica sutil o arcana de los lenguajes de programación. Este tipo de error se presta para la detección automática usando herramientas de análisis estático como Gimpel's PC-Lint and FlexeLint tools o Programming Research's QA tools, aunque también son útiles los enfoques de menor costo, como establecer un alto nivel de advertencia del compilador y compilar con más de un compilador.
Las herramientas de análisis dinámico vienen en una variedad de formas, tales como análisis de cobertura de código, perfil de rendimiento de código, análisis de gestión de memoria y comprobación de límites.
herramientas de gama superior/proveedores incluyen los gustos de Coverity, PolySpace (una herramienta de análisis abstracto), Cantata, LDRA, y Klocwork. En el extremo inferior (en el precio, no necesariamente la eficacia) son herramientas tales como PC-Lint y Tessy, o incluso el de código abierto splint (sólo C), y un gran número de unit testing tools
Es importante destacar que los analizadores estáticos extremadamente caros no son mejores que los que cuestan una décima parte del precio. Estoy usando LDRA y cuesta una fortuna, pero no funciona mejor que otras herramientas. La diferencia es que LDRA es extremadamente feliz para los gatillos e incluso con una gran cantidad de cheques eliminados, da aproximadamente 100 errores falsos por cada problema real. Es una buena idea verificar el código con varios analizadores diferentes, ya que todos tienen sus defectos. – Lundin
@Lundin: Absolutamente. Lo mencioné, aunque quizás no con énfasis. @Lemual quería saber sobre las herramientas disponibles, supongo que quiere saber qué puede encontrar. Si a ella se le encomendó la selección de tal herramienta, eso justificaría un tipo diferente de respuesta. – Clifford
Estas son algunas de las técnicas de pruebas de firmware que he encontrado útil ...
Unidad de prueba en el PC; es decir, extraer una función del firmware y compilarla y probarla en una plataforma más rápida. Esto le permitirá, por ejemplo, probar exhaustivamente una función, mientras que esto consumiría mucho tiempo in situ.
Instrumento el firmware controladores de interrupción utilizando un temporizador de hardware funcionamiento libre: las garrapatas en la entrada y salida, y el recuento de interrupciones. Mantenga un registro de la frecuencia mínima y máxima y el período de cada controlador de interrupción. Estos datos se pueden usar para hacer un análisis monotónico de frecuencia o un análisis monotónico de fecha límite.
uso de un protocolo estándar, como Modbus RTU, para hacer una serie de datos de estado disponibles bajo demanda. Esto se puede usar para datos de configuración y verificación.
Cree el número de versión del firmware en el código utilizando un proceso de compilación automático, por ejemplo, obteniendo la información de la versión del repositorio de código fuente. Haga que el número de versión esté disponible usando el # 3.
Uso pelusas u otra herramienta de análisis estático. Exija cero advertencias de pelusa y del compilador con -Wall.
aumentar sus herramientas de construcción con un medio para incrustar CRC del firmware en el código y comprobar que funciona en tiempo de ejecución.
he encontrado pruebas de tensión útil . Esto generalmente significa darle al sistema una gran cantidad de información en poco tiempo y ver cómo lo maneja. La entrada podría ser
Estos tipos de pruebas pueden eliminar muchos errores (especialmente en sistemas donde el rendimiento es crítico y limitado). Un buen sistema de registro también es bueno para tener que rastrear las causas de los errores planteados por una prueba de estrés.
Veo muchas ofertas de trabajo para trabajo de estilo integrado, quiero familiaridad con la depuración [jtag] (http://en.wikipedia.org/wiki/Joint_Test_Action_Group). – sarnold
@sarnold: JTAG en sí mismo no es una "herramienta de prueba"; simplemente se refiere a la conexión física y la comunicación entre un depurador de host de desarrollo y un procesador que incorpora hardware de depuración en el chip, evitando la necesidad de costoso hardware de emulador en circuito externo o monitores de depuración remota basados en software menos robustos. Cualquiera que lo incluya como un requisito de trabajo específico probablemente tenga poca comprensión de qué es exactamente, y en realidad simplemente quiere experiencia en depuración de hardware/ICE en general. De cualquier manera, no creo que sea muy relevante para la pregunta en cuestión. – Clifford