Embedded QA (Qualitätssicherung für eingebettete Systeme)
Liefern Sie evidenzbasierte, reproduzierbare Tests, ohne Fähigkeiten zu beanspruchen, die die Testumgebung nicht nachweisen kann. Wählen Sie ein oder mehrere Backends, die zur jeweiligen Funktion und ihren Fehlermodi passen, nicht eine vorgeschriebene Testpyramide für jede Änderung.
Testablauf
- Inspizieren: Identifizieren Sie das tatsächliche Firmware-Ziel, die Board-/Siliziumrevision, die Toolchain, die vorhandene Testinfrastruktur, Anforderungen, Sicherheits-/Leistungs-/Timing-Einschränkungen, Build-Artefakte und verfügbare Host-/Emulator-/Probe-Hardware. Nutzen Sie vorhandene Tests und Werkzeuge, bevor Sie ein neues Framework einführen.
- Definieren Sie das Testorakel unabhängig: Übersetzen Sie Anforderungen in beobachtbare positive, negative, Grenzwert-, Fehler- und Wiederherstellungs-Erwartungen. Überprüfen Sie erwartete Werte anhand von Spezifikationen und Testvektoren, anstatt blind Implementierungsergebnisse nachzubilden.
- Wählen Sie das günstigste vertrauenswürdige Backend: Testen Sie portable Zustandsautomaten und Protokolle auf dem Host. Verwenden Sie Renode nur, wenn dessen CPU-, Interrupt-, Speicher- und Peripheriemodellierung für jede Behauptung ausreichend ist; markieren Sie andernfalls
BLOCKED_BY_MODELund verwenden Sie Mocks, Modellarbeit oder HIL. Verwenden Sie echte Board-/Probenmessungen für elektrisches Verhalten, Leistung, DMA/Cache, Timing und Reset-Verhalten. - Erstellen und ausführen: Erfassen Sie genaues Firmware-Image/Revision, Modellversion, Skripte, Stimuli, Exit-Status und begrenzte Timeouts. Führen Sie gezielte Prüfungen vor umfassender Regression durch. Isolieren Sie Testressourcen, Portnummern und Bereinigung; flashen/löschen Sie niemals echte Hardware ohne Autorisierung.
- Berichten nach Evidenzstufe: Host, statisch, simuliert, HIL und physikalische Messung erhalten jeweils ein eigenes PASS/FAIL/NOT_RUN/INCOMPLETE-Ergebnis. Markieren Sie fehlende Modellabdeckung und Testabdeckung getrennt. Bewahren Sie nützliche maschinenlesbare Protokolle, keine ausführlichen Transkripte im LLM-Kontext.
- Nachverfolgen: Liefern Sie die kürzeste reproduzierbare Fehlerreproduktion, Ursachennachweise oder Umfangseinschränkungen. Fügen Sie stabile Tests zusammen mit Korrekturen hinzu, falls angemessen.
Bedingte Referenzen
- host-testing.md für Mocks, Sanitizer, Eigenschafts- und Fehlertests.
- renode-workflow.md für
.resc/.repl, Robot Framework, UART und CI. - simulation-coverage.md für präzise Renode-Durchführbarkeit und Evidenz-Gates.
- hil-testing.md für ST-Link, J-Link, OpenOCD, seriell/RTT und reale Board-Instrumentierung.
Verwenden Sie scripts/summarize_robot.py, um Robot output.xml (falls erstellt) zusammenzufassen. Erfinden Sie keine Renode-MCP-Integrationen: Überprüfen Sie einen tatsächlich installierten Adapter, bevor Sie sich darauf verlassen. Schützen Sie gemeinsam genutzte Debug-Probes, UART-Sockets und Leistungsgeräte vor gleichzeitigen Tests.
Liefern: Testumgebung und Einschränkungen; ausgeführte Befehle; Behauptungen/Ergebnisse mit Nachweisort; simulierte gegenüber physikalischer Abdeckung; verbleibende Risiken.