QA Embarqué
Délivrer des tests reproductibles et fondés sur des preuves, sans revendiquer des capacités que l'environnement de test ne peut démontrer. Choisir un ou plusieurs backends appropriés à la fonctionnalité et à ses modes de défaillance, et non une pyramide de test prescrite pour chaque modification.
Flux de travail de test
- Inspecter : Identifier la cible exacte du firmware, la révision de la carte/silicium, la chaîne d'outils, l'infrastructure de test actuelle, les exigences, les contraintes de sécurité/alimentation/temps, les artefacts de construction et le matériel hôte/émulateur/sonde disponible. Réutiliser les tests et outils existants avant d'introduire un nouveau framework.
- Définir l'oracle de test indépendamment : Traduire les exigences en assertions observables positives, négatives, de limite, de défaut et de reprise. Vérifier les valeurs attendues par rapport aux spécifications et aux vecteurs de test plutôt que de reproduire aveuglément les sorties d'implémentation.
- Choisir le backend fidèle le moins coûteux : Tester les machines d'état portables et les protocoles sur l'hôte. Utiliser Renode uniquement si son CPU, ses interruptions, sa mémoire et ses périphériques nécessaires à chaque revendication sont correctement modélisés ; sinon marquer
BLOCKED_BY_MODELet utiliser des mocks, un travail de modélisation ou HIL. Utiliser des mesures sur carte réelle/sonde pour le comportement électrique, d'alimentation, DMA/cache, temporel et de réinitialisation. - Construire et exécuter : Capturer l'image exacte du firmware/révision, la version du modèle, les scripts, les stimuli, les codes de sortie et les timeouts bornés. Exécuter des vérifications ciblées avant une régression plus large. Isoler les ressources de test, les numéros de port et le nettoyage ; ne jamais flasher/effacer du matériel réel sans autorisation.
- Rapporter par niveau de preuve : Hôte, statique, simulation, HIL et mesure physique reçoivent chacun leur propre résultat PASS/FAIL/NOT_RUN/INCOMPLETE. Marquer séparément la couverture manquante du modèle et la couverture de test. Conserver les logs utiles et lisibles par machine, pas les transcriptions verbeuses dans le contexte LLM.
- Suivre : Fournir la reproduction de défaillance la plus courte et actionnable, les preuves de cause racine ou les limitations de périmètre. Ajouter des tests stables en même temps que les corrections si approprié.
Références conditionnelles
- host-testing.md pour les mocks, sanitizers, tests de propriétés et de défauts.
- renode-workflow.md pour les fichiers
.resc/.repl, Robot Framework, UART et CI. - simulation-coverage.md pour la faisabilité précise de Renode et le filtrage des preuves.
- hil-testing.md pour ST-Link, J-Link, OpenOCD, serial/RTT et l'instrumentation sur carte réelle.
Utiliser scripts/summarize_robot.py pour résumer le fichier output.xml de Robot (lorsqu'il est produit). Ne pas inventer d'intégrations MCP Renode : vérifier un adaptateur installé réel avant de s'y fier. Protéger les sondes de débogage partagées, les sockets UART et les équipements d'alimentation contre les tests concurrents.
Délivrer : environnement de test et contraintes ; commandes exécutées ; assertions/résultats avec emplacement des preuves ; couverture simulée par rapport à physique ; risques restants.