← Blog Prozess

IoT-Geräte testen: von Unit-Tests bis zur Feldvalidierung

KonzeptPCB-DesignFirmwareTestingProduktion››››

IoT-Testpyramide: Unit-Tests (schnell, viele) — Integration — Hardware-in-the-Loop — Feldvalidierung (langsam, wenige)

Das Testen von IoT ist schwieriger als das Testen von Software, weil man die Physik nicht simulieren kann. Funkstörungen, Batterieentladung, mechanische Belastung und Temperaturzyklen verursachen Fehler, die Unit-Tests nie erfassen.

Ebene 1: Firmware-Unit-Tests

// Unity-Test — GEST-Zustandsautomat für Servicerufe

void test_service_call_queues_on_button_press(void) {
    event_t evt = {.type = BUTTON_PRESS};
    state_machine_process(&evt);
    TEST_ASSERT_EQUAL(STATE_SERVICE_CALL_PENDING, get_current_state());
    TEST_ASSERT_TRUE(ble_queue_has_pending_event());
}

Ebene 2: Hardware-in-the-Loop-(HIL-)Tests

HIL verbindet ein reales Gerät mit einem PC-gesteuerten Testaufbau, der Hardware-Eingaben simuliert und Ausgaben validiert. Erkennt Timing-Fehler und Interrupt-Handler, die Unit-Tests übersehen.

Ebene 3: Netzwerksimulation

  • OTA-Download bei 50 % unterbrochen — Gerät setzt ab dem Prüfpunkt fort
  • MQTT-Broker 24 Stunden offline — Gerät speichert Ereignisse lokal, überträgt sie bei der Wiederverbindung
  • Stromausfall während des Flash-Schreibvorgangs — Rollback zur vorherigen Partition beim nächsten Start
🧪 Regressionsrichtlinie
Jedes OTA-Release durchläuft einen 48-stündigen Dauertest auf 10 Laborgeräten, bevor es in die Flotten-Bereitstellung der Stufe 1 übergeht. Allein im Jahr 2025 haben wir 3 Produktions-Firmware-Releases aufgrund von Fehlern im Dauertest blockiert.

RF- und Funktests

Das Testen der Funkübertragung ist einer der am häufigsten übersprungenen — und am häufigsten bereuten — Aspekte des IoT-Hardware-Tests. Ein Gerät, das im Labor neben dem Testequipment perfekt funktioniert, kann im Feld versagen — durch Antennenverstimmung durch nahegelegenes Metall, Störungen aus benachbarten Kanälen durch nebenstehende Geräte oder schlicht durch unzureichende Sendeleistung für die geforderte Reichweite.

RF-Charakterisierungstests sollten umfassen: Messung der Sendeleistung bei allen Modulationsraten, Messung der Empfängerempfindlichkeit (minimaler Signalpegel für zuverlässigen Empfang), Nachbarkanalunterdrückung (wie verhält sich das Funkmodul, wenn ein anderes Gerät 5 MHz entfernt sendet?) und Koexistenztests (BLE und WiFi gleichzeitig, sofern beide vorhanden sind). Diese Tests erfordern einen leitungsgebundenen RF-Messaufbau oder eine geschirmte, reflexionsarme Umgebung — improvisierte Freiraummessungen sind für die Produktionsqualifizierung nicht reproduzierbar genug.

Beschleunigte Lebensdauertests (ALT)

Beschleunigte Lebensdauertests komprimieren Monate oder Jahre betrieblicher Belastung in Tage oder Wochen, indem die Belastungsniveaus über die normalen Betriebsbedingungen hinaus erhöht werden. Temperaturzyklen (thermische Ermüdung), Feuchtigkeit (Korrosion von Leiterbahnen und Steckerkontakten), Vibration (Ermüdung von Lötstellen) und UV-Belastung (Materialdegradation des Gehäuses) sind gängige ALT-Belastungsfaktoren.

ALT-Ergebnisse prognostizieren Ausfallraten im Feld mithilfe statistischer Modelle (Arrhenius für thermische Belastung, Coffin-Manson für Temperaturzyklen). Die Kenntnis der MTTF (Mean Time To Failure) Ihres Geräts vor der Markteinführung ermöglicht es Ihnen, angemessene Garantiebedingungen zu gestalten, einen Bestand an Ersatzteilen vorzuhalten und Ihr Produkt so zu bepreisen, dass die erwarteten Garantiekosten gedeckt sind. Produkte, die ohne ALT-Daten auf den Markt kommen, erleben regelmäßig Überraschungen bei den Garantiekosten, die die Margen in den Jahren 2–3 aufzehren.

Automatisierte Regressionstests in CI/CD

Jede Firmware-Änderung sollte vor dem Zusammenführen automatisierte Tests auslösen. Für IoT-Firmware bedeutet das mindestens: Unit-Tests auf dem Host (simulierte Hardware), Integrationstests auf einem Hardware-in-the-Loop-Prüfstand (echter MCU, simulierte Peripherie) und einen Smoke-Test auf echter Hardware in einer Laborumgebung. Pull-Requests, die eine dieser Kontrollen nicht bestehen, werden nicht zusammengeführt, unabhängig von der Dringlichkeit.

Der Aufbau dieser CI/CD-Pipeline erfordert Investitionen — Hardware-Prüfstände, automatisierte Bereitstellung von Testgeräten und eine robuste Testinfrastruktur. Die Investition amortisiert sich bei jedem Produkt mit regelmäßigen Firmware-Updates innerhalb weniger Monate. Manuelle Regressionstests im Release-Rhythmus sind nicht skalierbar und führen zum denkbar ungünstigsten Zeitpunkt zu menschlichen Fehlern.

Entwickeln Sie ein IoT-Produkt?

FSS ist ein Full-Stack-IoT-Engineering-Team — Hardware, Firmware, Cloud und Mobile aus einer Hand.

Unsere Entwicklungskompetenzen →