Mithilfe eines konkreten Beispiels lassen sich die für IoT-Systeme sinnvollen Testmethoden am einfachsten erläutern. Konkret soll es in diesem Beitrag um eine medizinische Lösung gehen, die im Wesentlichen aus vier Komponenten besteht (Bild 1):

  • einem Blutsensor als Wearable-Lösung (etwa ein Blutzucker-Messgerät),
  • einem Medikations-Injektor (etwa für Insulin) ebenfalls in Wearable-Ausführung,
  • einem Smartphone
  • sowie einem Cloud-basiertes Healthcare-System.
Tests

Bild 1: Schematischer Aufbau einer Cloud-basierten Lösung zur Bestimmung des Blutzuckerspiegels. Parasoft

Der Sensor untersucht das Blut auf einen bestimmten Parameter hin (beispielsweise den Blutzuckerspiegel). Die Übermittlung der Messergebnisse erfolgt drahtlos an eine Smartphone-App, die als Middleware fungiert. Neben einfachen Analysefunktionen übermittelt die App die Informationen über den Blutzuckerspiegel an ein Healthcare-System in der Cloud, das weitere Verarbeitungen vornimmt, etwa den Vergleich der aktuellen Messwerte mit historischen Daten und die Suche nach unerwünschten Mustern mithilfe aufwendigerer Analysen. Erkennt es eine potenzielle Gefahr, sendet das System eine Warnmeldung direkt an den Anwender oder informiert medizinisches Personal.

Im konkreten Anwendungsbeispiel sind der Glukosesensor und der Injektor als MCU-basierte, in C entwickelte Systeme implementiert. Die Middleware-Applikation im Smartphone und die Back-End-Lösung in der Cloud sind dagegen in Java programmiert. Sensor, Smartphone-App und Injektor tauschen ihre Daten per Funk mithilfe eines anwendungsspezifischen Protokolls aus. Der Datenaustausch zwischen der Smartphone-App und dem Healthcare-System in der Cloud erfolgt per HTTP.

End-to-End-Tests für das IoT

End-to-End-Tests auf der System-Ebene sind häufig die erste und einzige Option. Dies liegt hauptsächlich daran, dass es auf den ersten Blick als die logischste effektivste Nutzung der Qualitätssicherungs-Ressourcen erscheint, das System komplett zusammenzusetzen und dann zu testen. Nutzt man sie jedoch als primäres Mittel zur Qualitätssicherung, führt dies oft dazu, dass Fehler erst sehr spät entdeckt werden und das Produkt deshalb nur mit Verzögerung auf den Markt kommt.

Zweifelsohne sind End-to-End-Tests sinnvoll. Sie sollten aber dazu dienen, das korrekte Zusammenpassen aller Teile sicherzustellen, und nicht zum Aufdecken von Fehlern eingesetzt werden. Das System kann die Gültigkeit einiger Anforderungen überprüfen, aber nicht alle möglichen Situationen simulieren. Ein System mit diesen Fähigkeiten zu bauen, wäre zu zeit- und kostenintensiv.

Der primäre Testfall könnte die folgenden Aktionen abdecken:

  • Aktivierung des Blutzuckersensors
  • Erstellen eines Datenpakets
  • Weiterleitung der Daten an die Cloud
  • Generierung eines Alarms durch die Cloud
  • Abwarten der Reaktion des medizinischen Personals
  • Alarmierung des Patienten
  • Änderung des Injektionsplans oder Verabreichung einer Sofort-Injektion

Später erfolgende Tests zum Verifizieren dieses Szenarios sind extrem arbeits- und kostenaufwendig. Da zudem immer mehr Organisationen zu agilen Entwicklungskonzepten übergehen, wird das angemessene Testen innerhalb der Iterationen immer schwieriger. Außerdem fallen während des Entwicklungsprozesses potenziell lange Wartezeiten bis zum Beginn des Testens an. Hier müssen die Organisationen zwischen Schnelligkeit und Qualität abwägen.

Frühzeitigere Tests ermöglichen eine effektivere Automatisierung. Softwareingenieure und Prüfer können dann aussagefähigere Daten über den Code einholen, um die Aufgaben gemäß ihrer Entwicklungs-Prozedur zu priorisieren. Dies wiederum spart Zeit und Geld über den gesamten Entwicklungszyklus.

Effektiveres Testen durch Systemunterteilung

Als Voraussetzung für die Unterteilung eines Systems in verschiedene Ebenen muss die Lösung von vornherein so angelegt werden, dass eine Segmentierung in kleinere Abschnitte mit definierten Schnittstellen möglich ist. Außerdem müssen automatisierte Testlösungen um diese kleineren Abschnitte herum implementiert werden. Insgesamt sollte der Testplan eine Kombination aus Modultests, Integrationstests und bestimmten End-to-End-Tests vorsehen. Je komplexer die Lösung ist, umso wichtiger werden die Modultests, denn mit zunehmender Komplexität der Software wird es immer schwieriger, die übergeordneten Schnittstellen zu aktivieren, die sicherstellen, dass die verschiedenen Pfade auch ausgeführt werden.

Modultests sind zeit- und ressourcenaufwendig. Sie müssen von kundigen Fachleuten geschrieben werden und sind eng an den Code gebunden. Das erfordert die fortlaufende Pflege bei Änderungen am Code. Tests auf der Funktionsebene sind weniger anfällig, machen aber das Aufdecken systemischer Probleme schwieriger. Bei Modultests dagegen ist die Ursachenfindung einfacher. Empfehlenswert ist daher ein kombiniertes Konzept – nicht nur für IoT-Umgebungen, sondern für alle Anwendungen, in denen es auf Geschwindigkeit und Qualität ankommt.

 

Lesen Sie auf der nächsten Seite über automatisierte Tests für Teilkomponenten und die Isolation von einzelnen Komponenten.

Seite 1 von 212