Synchrone Software-Tests im agilen IoT-Entwicklungsprozess

Das Internet der Dinge (IoT) über ein Internet des Lichts zu organisieren, birgt ein hohes Potenzial. Tridonic hat auf Basis dieser Idee Net-4-More (Eigenschreibweise: net4more) entwickelt: eine skalierbare, offene IoT-Systemarchitektur, die updatefähig ist und die die Basis für zukünftige Anwendungen mit IPv6-Konnektivität bis zum Endknoten (einzelne Leuchten) bereitstellt (Bild 1).

Bild 1: Visualisierung der offenen IoT-Systemarchitektur von Net-4-More. Tridonic

Die Toolbox setzt sich aus einer Vielzahl an unterschiedlichen Komponenten zusammen: Das System besteht zum einen aus modularen Hardware-Komponenten mit Embedded-Software-Applikationen, so zum Beispiel Geräte zum Leuchteneinbau sowie unabhängige Geräte, die Wandschalter- oder Sensor-Informationen ins Netzwerk bringen. Auf der anderen Seite, der App- und Server-Seite des Systems, handelt es sich um reine Software: Apps, die zum Planen, Kommissionieren oder zum Schalten und Dimmen der Beleuchtungslösung notwendig sind. Gemeinsam mit dem Link-Server und der Software-Suite bilden sie das Herz des Lichtsystems. Hinzu kommen der Cloud-Server zum Speichern sowie das Management-Portal zur Visualisierung der Daten. Um eine hohe Qualität der Toolbox gewährleisten zu können, ist Software-Testing neben der Überprüfung der Hardware-Komponenten ein integraler Bestandteil der Produktentwicklung.

Herausforderung Software-Testing

Bild 2: Testaufbau von Net-4-More mit PoE-Geräten (v.l. oben im Uhrzeigersinn): LED-Module, Sensoren und Kommunikationsmodule, PoE-Switches, Lichtschalter und Stromversorgung. Tridonic

Die technischen Herausforderungen des Net-4-More-Testings liegen vor allem der Pionierarbeit zu Grunde, die Tridonic im Rahmen der Entwicklung des Konzepts leistet. Eine drahtgebundene IP-basierte Kommunikation übermittelt Befehle zwischen den Geräten und ermöglicht nicht nur das Ein- und Ausschalten von Leuchten, sondern beispielsweise auch das Monitoring von Sensorinformationen wie beispielsweise den Energieverbrauch oder die Bewegungsaktivität (Bild 2).

Für Wireless-Geräte wurde mit Thread ein IPv6-basiertes WPAN (wireless personal area network) mit niedrigem Energieverbrauch auf IEEE-802.15.4-Basis gewählt. Über dieses können sich drahtlose Geräte, die in Reichweite sind, untereinander zu einem sogenannten Mesh verbinden. Auf diese Weise benötigt nicht jede Leuchte eine direkte Verbindung zu einem Border-Router, sondern Leuchten lassen sich selbst zur Weitergabe von Daten an andere, entfernte Leuchten einsetzen.

Die Erprobung und Sicherstellung dieser Funktion stellt eine besondere Aufgabe dar – vor allem im Hinblick auf nicht alltägliche, aber doch gelegentlich auftretende Probleme. Zum Beispiel kann sich die Qualität der drahtlosen Verbindung verändern oder es können sogar Funkstörungen und damit Unterbrechungen der Datenübertragungen auftreten. Für diesen Fall ist es notwendig, Strategien zu entwickeln, wie der Normalbetrieb nach definierten Fehlerzuständen wieder aufgenommen wird.

Welche Vorteile Software-Tests bereits in der Entwicklungsphase bringen, beschreibt der Beitrag auf der nächsten Seite.

Software-Tests bereits in der Entwicklung

Die Vielzahl an Komponenten sowie der Innovationsgrad des Projekts bringen eine hohe Komplexität mit sich und somit auch einige Risiken in der Testing-Phase. Daher hat sich Tridonic entschieden, bei der Software-Entwicklung von Net-4-More neue Wege zu gehen. Als eine Neuerung arbeiten an dem Projekt zwei verschiedene Scrum-Teams, in denen im Rahmen des agilen Entwicklungsprozesses jeweils Entwickler und Tester vereint sind. Grundidee dabei ist, den Test stets synchron zum jeweiligen Entwicklungsvorgang zu halten – anders als in klassischen Vorgehensmodellen wie Wasserfall- oder V-Modell. Auf diese Weise sind Probleme und Fehler schneller erkennbar, was letztlich Zeit und Geld in der Entwicklung spart.

Im Rahmen der Systemintegration wird das Gesamtsystem anschließend von Testern in mehreren Stufen erprobt. Die Aufgabe besteht darin, die geplanten Anwendungsfälle zu testen und Testreports sowie Metriken zur Reife und Skalierbarkeit des Systems zu generieren. Dabei kommt den Skalierungstests eine wesentliche Rolle im Hinblick auf die Produktreife zu: Ein System, das in kleinen Ausbaustufen und mit wenigen Komponenten gut funktioniert, kann in größeren Ausbaustufen und über eine längere Nutzungsdauer Probleme aufzeigen. Zur Veranschaulichung: In großen Bürokomplexen sind oftmals hunderte bis tausende Leuchten verbaut. Im Vergleich zu kleineren Gebäuden ist dadurch auch die Gesamtmenge an Kommunikation innerhalb des Systems deutlich erhöht. In so genannten Skalierungstests überprüft das Team, ob das Produkt auch für größere Projekte reif ist.

Testen am Übergang zur Produkteinführung

Das für die Systemintegration verantwortliche Team hat eine sehr wichtige Funktion innerhalb des gesamten Projekts: Es ist die Hauptansprechstelle, wenn es um Net-4-More geht. Hintergrund ist dabei, dass das Team das vollumfängliche Wissen zu den aktuellen Funktionen des Systems besitzt. Gleichzeitig kennt es auch den gegenwärtigen Stand, welche Funktionen bereits realisiert oder noch geplant beziehungsweise für eine Implementierung nicht vorgesehen sind. Hinzu kommt eine detaillierte Expertise über die einzelnen Komponenten und insbesondere auch in Bezug auf die Netzwerktechnologie.

Im Übergang zur Produkteinführung hat sich dieses Wissen als ungemein nützlich und hilfreich erwiesen. In dieser Phase erfolgt zunächst intern und später auch bei ausgewählten Kunden die Planung der Pilotinstallationen, der Aufbau, die Inbetriebnahme, die Überwachung sowie das Aufspielen von Software-Updates. Im realen Anwendungsfall zeigen sich neue, im Laboraufbau nicht erkannte Fehler, da jeder Applikationsfall andere Bedingungen aufweist, beispielsweise im Hinblick auf die Skalierbarkeit und die zu integrierenden Geräte. Für den Support der Piloten hat sich das Software-Testing als unverzichtbarer Dreh- und Angelpunkt erwiesen. Gleichzeitig dienen diese Pilotinstallationen der Wissensvermittlung an das Supportteam.

Auf der folgenden Seite zeigt der Artikel, was bei der Automatisierung von Software-Tests zu beachten ist und wie sich Pseudofehler vermeiden lassen.

Automatisierte Tests und kontinuierliche Integration

Tests zu automatisieren bedeutet zwar einen höheren, einmaligen Aufwand für das Automatisieren selbst. Im Gegenzug verringert sich die Dauer der Durchführung, weshalb sich Automatisierung vor allem in einer großen Anzahl wiederkehrender Tests lohnt. Automatisierte Lösungen sind aber meistens nicht perfekt, sondern selbst mit Fehlern behaftet. Das verschlechtert die Gesamtbilanz für die Testautomatisierung deutlich, da sie eine gewisse Menge an falschen Resultaten liefert. In einem agilen Prozess, wie er bei Tridonic zum Einsatz kommt, finden viele Testwiederholungen statt. Am Ende jedes zweiwöchigen Sprints beziehungsweise jeder Entwicklungsphase testet das Team das potenziell lieferbare Produkt. So finden im Gegensatz zu einer nicht-agilen Herangehensweisen sehr viel mehr Prüfungen statt.

Bild 3: Das Test-Automation-Framework für den Software-Test: Testfall (links) zum Test der User-Control-App (mitte) sowie der generierte Testreport (rechts). Tridonic

Das Konzept „Continuous Integration“ (CI) beschreibt eine Vorgehensweise für Software-Entwicklungsteams, in der jeder Entwickler seine Implementierungen oder Änderungen möglichst schnell (ungefähr täglich) seinen Kollegen zur Verfügung stellt. So entsteht nach jeder Änderung eines Software-Entwicklers ein automatisierter Build (Generierung von ausführbarem Code) – und bestenfalls auch ein automatisierter Test (Bild 3).

Die Idee hinter CI ist: Kleinere Software-Änderungen können nur kleinere beziehungsweise lokal begrenzte Fehler hervorrufen, die von einem direkt nachgelagerten Test schnell gefunden und einfach korrigiert werden können. Ändern dagegen mehrere Entwickler größere Teile des Codes zur selben Zeit (konventionelle Vorgehensweise), ist ein Fehler schwerer zu lokalisieren. Im schlimmsten Fall ist der Fehler sogar durch eine Kombination der verschiedenen neuen Codes der einzelnen Entwickler entstanden.

Mehrstufiges CI-Konzept

Bild 4: Die Hardware-Seite von Net-4-More: ein Treiber, verbunden mittels PoE mit einem Sensor und einem Kommunikationsmodul. Tridonic

Tridonic setzt im Projekt Net-4-More ein mehrstufiges CI-Konzept um. Diverse Pipelines auf den verschiedenen Software-Modulen (Embedded-Geräte, Cloud, Apps) beinhalten einen automatisierten Test. Dafür stehen unterschiedliche Test-Umgebungen zur Verfügung (inklusive LED-Treiber, Kommunikationsmodule, Tablet sowie Smartphone, Bild 4), auf denen die Tests gesteuert und durch die Software Gitlab zur Ausführung kommen. Das System gipfelt in einer Teststufe für die Systemintegration mit mehr als 100 drahtlosen Kommunikationsmodulen und vielen anderen Geräten. Tester können mit standortübergreifenden Installationen arbeiten und zum Beispiel mit ihrer lokalen User-Control-App LEDs an anderen Standorten fernsteuern und deren Reaktion über Videokameras und Netzwerk-Tracing überwachen.

Pseudofehler bei der Testautomatisierung lassen sich durch eine sinnvolle Auswahl der Testfälle sowie die Vermeidung einer potenziell unendlichen Detaillierung von Spezialfällen vermeiden. Für eine optimierte Identifizierung und Behandlung von Pseudofehlern, die durch Testautomatisierung verursacht werden, entwickelt Tridonic einen toolgestützten Prozess, der instabile Testfälle quantifiziert. Unzuverlässige Testfälle werden aus den automatisierten Tests aussortiert, lassen sich über geeignete Filter anzeigen und verbessern oder aus den Testläufen entfernen.

(na)