QA Embebido
Entregar pruebas basadas en evidencia, reproducibles, sin reclamar capacidades que el entorno de prueba no pueda demostrar. Elegir uno o más backends apropiados para la funcionalidad y sus modos de fallo, no una pirámide de pruebas prescrita para cada cambio.
Flujo de trabajo de pruebas
- Inspeccionar: Identificar el objetivo real de firmware, revisión de placa/silicio, cadena de herramientas, infraestructura de pruebas actual, requisitos, restricciones de seguridad/alimentación/temporización, artefactos de compilación y hardware de host/emulador/sonda disponible. Reutilizar pruebas y herramientas existentes antes de introducir un marco de trabajo.
- Definir el oráculo de prueba de forma independiente: Traducir los requisitos en aserciones observables positivas, negativas, de límite, de fallo y de recuperación. Verificar los valores esperados contra las especificaciones y vectores de prueba en lugar de reproducir ciegamente las salidas de la implementación.
- Elegir el backend más económico y fiel: Probar máquinas de estado y protocolos portables en host. Usar Renode solo si su CPU, interrupciones, memoria y periféricos necesarios para cada afirmación están modelados adecuadamente; de lo contrario, marcar como
BLOQUEADO_POR_MODELOy usar maquetas, trabajo de modelo o HIL. Usar mediciones reales de placa/sonda para comportamiento eléctrico, de alimentación, DMA/caché, temporización y reinicio. - Construir y ejecutar: Capturar la imagen/revisión exacta de firmware, versión del modelo, scripts, estímulos, estados de salida y tiempos de espera acotados. Ejecutar comprobaciones dirigidas antes de una regresión más amplia. Aislar recursos de prueba, números de puerto y limpieza; nunca flashear/borrar hardware real sin autorización.
- Informar por nivel de evidencia: Cada uno de los resultados de host, estático, simulado, HIL y medición física recibe su propio estado PASS/FAIL/NOT_RUN/INCOMPLETE. Marcar la falta de cobertura del modelo y la cobertura de prueba por separado. Conservar registros útiles legibles por máquina, no transcripciones verbosas en el contexto del LLM.
- Seguimiento: Proporcionar la reproducción de fallo accionable más corta, evidencia de causa raíz o limitaciones de alcance. Agregar pruebas estables junto con las correcciones si es apropiado.
Referencias condicionales
- pruebas-host.md para maquetas, sanitizadores, pruebas de propiedades y fallos.
- flujo-renode.md para
.resc/.repl, Robot Framework, UART y CI. - cobertura-simulacion.md para viabilidad precisa de Renode y compuerta de evidencia.
- pruebas-hil.md para ST-Link, J-Link, OpenOCD, serial/RTT e instrumentación de placa real.
Usar scripts/summarize_robot.py para resumir el output.xml de Robot (cuando se produzca). No inventar integraciones de MCP de Renode: verificar un adaptador real instalado antes de confiar en él. Proteger las sondas de depuración compartidas, los sockets UART y el equipo de alimentación de pruebas concurrentes.
Entregar: entorno y restricciones de prueba; comandos ejecutados; aserciones/resultados con ubicación de evidencia; cobertura simulada versus física; riesgos restantes.