Systemtests für Küchengeräte in der Großgastronomie bedeuten, Heizung, Motorsteuerung und Bussysteme vollautomatisiert auf echten Geräten zu prüfen. Ein Python-Framework steuert dabei Hardware wie Relaismodule und Stromversorgungen. Rund 2.000 Testfälle laufen jede Nacht, am Wochenende bis zu 30 Stunden am Stück.
Das Wichtigste in Kürze
- Rund 700.000 Zeilen Code stecken in den Kombidämpfern von RATIONAL, verteilt über mehrere Elektronikkomponenten, die über Bussysteme miteinander kommunizieren.
- Zehn Testautomatisierungsfachleute stehen bei RATIONAL etwa 70 Embedded-Entwicklern gegenüber, weshalb Skalierbarkeit der Automatisierungsinfrastruktur die größte strategische Herausforderung ist.
- Nächtliche Testläufe über mehrere Branches decken rund 2.000 Testfälle ab, wobei nicht das Framework, sondern die physikalische Aufheizzeit der echten Geräte den Laufzeitengpass bildet.
- Wo Heizzyklen zu lange dauern würden, simuliert das Team gezielt Temperaturwerte im System, um Abschaltlogiken zu testen, ohne das Gerät jedes Mal aufheizen zu müssen.
- RATIONAL verlagert das Testdesign schrittweise in die Fachbereiche: Das Testteam stellt Infrastruktur und Framework bereit, während die Fachabteilungen eigene Tests schreiben und pflegen sollen.
Großküchengeräte sind Software-Systeme mit Stahlmantel
Ein Kombidämpfer für die Großküche ist ein vernetztes Softwaresystem. In den Geräten von RATIONAL stecken rund 700.000 Zeilen Code, verteilt auf mehrere Elektronikkomponenten, die über Bussysteme miteinander kommunizieren und mit unterschiedlichen Firmwares laufen.
Die Hauptsoftware entwickelt der Hersteller selbst, die Elektronikkomponenten kommen von externen Firmen. Beide Welten müssen zusammenspielen, und genau an dieser Schnittstelle entscheidet sich, ob ein Gerät zuverlässig funktioniert.
Die Dimensionen sind nicht die einer Heimküche. Die größten Geräte verarbeiten über 90 Hähnchen auf einen Schlag, sind übermannshoch und bringen bis zu 70 Kilowatt Heizleistung mit. Software, die so viel Energie steuert, braucht einen Test, der diese Leistung real abbildet.
Warum der Test echte Hardware statt reiner Simulation braucht
Wer ein Gerät mit 70 Kilowatt Heizleistung testet, kommt mit Software allein nicht aus. Bei RATIONAL steht hinter dem Test eine eigene Hardware-Infrastruktur in eigenen Racks: Relaismodule, Remote-Stromversorgungen, Logic-Analyser und die Möglichkeit, Strom, Gas und Wasser gezielt an- und abzuschalten.
Bis hinunter zur seriellen Konsole am Gerät ist alles über Netzwerk erreichbar. USB läuft über Netzwerk, was Andreas Berger selbst als Herausforderung benennt. Diese Hardware ist ein Haufen Geld und Material, klar benannt als der teure Teil der Anlage.
Der limitierende Faktor im Testbetrieb ist nicht die Software, sondern die getestete Hardware. Wenn ein Gerät hochheizen muss, um die Heizung zu prüfen, wartet der Test die meiste Zeit auf physikalische Prozesse. Ein Server mit acht Kernen und 8 GB Speicher managt 18 gleichzeitig laufende Testgeräte locker. Die Wärme braucht trotzdem ihre Zeit.
Klarer Fokus: Systemtest und Regression, kein Unit-Test
Das Testautomatisierungsteam hat seinen Schwerpunkt früh festgelegt. Es macht Systemtests, Regressionstests und Low-Level-Tests bis hinunter auf die Bussysteme. Unit- und Modultests bleiben auf der Entwicklungsseite, Abnahmetests beim Anforderer.
Diese Abgrenzung ist eine Entscheidung, kein Zufall. Wer alles testen will, testet am Ende nichts richtig. Der Fokus auf Systemverhalten passt zu einem Produkt, bei dem das Zusammenspiel vieler Komponenten den Unterschied macht.
Ein typischer Testfall steuert eine Betriebsart an, etwa Kochen mit Heißluft, und prüft dann auf der Reglerebene, ob die richtigen Regler ansprechen, ob der Motor dreht, ob die Heizungen anspringen und ob die eingestellte Zieltemperatur erreicht wird. Darüber liegen Systemintegrationstests, die auch die Vernetzungslösung einbeziehen.
Was die Vernetzung der Geräte konkret leistet
Vernetzung bedeutet hier nicht, dass die Geräte untereinander kommunizieren. Sie bedeutet, dass Updates und Programme remote ausgerollt werden können. Große Ketten haben die Anforderung, ihre Gar-Programme oder ein Software-Update auf alle Geräte in allen Filialen zu verteilen.
Den dafür nötigen Dienst stellt der Hersteller bereit. Auch eine kleine Gaststätte kann dieselbe Vernetzungslösung nutzen, mit einem eigenen Account. Für den Test heißt das: das Ausrollen muss genauso geprüft werden wie das Garen selbst.
Warum Python die richtige Wahl für das Testframework war
Die Sprachwahl fiel auf Python, weil das Team nichts kompilieren wollte und eine kompakte Sprache mit vielen Bibliotheken brauchte. Andreas Berger kommt aus der C- und C++-Welt und kennt den Unterschied genau.
Wenn ich da versuche, eine Netzwerkverbindung zu machen oder eine serielle Verbindung, programmiere ich mir erstmal einen Wolf. Wenn ich das gleiche in Python mache, sind es zwei Zeilen Code.
Andreas Berger
Die Kompilierzeiten sollten weg. Heute pflegt das Team mehrere eigene Python-Packages, lädt sie automatisch in eigene Registries hoch und betreibt darum eine eigene Package-Infrastruktur. Die Entscheidung für Python bewertet Andreas im Rückblick als richtig.
Neben Python bilden GitLab und ein Testdesign-Tool das Grundgerüst. GitLab trägt die Pipelines und die Qualitätssicherung des eigenen Frameworks. Das Testdesign-Tool hilft beim Variantenmanagement: Ein abstrakter Testfall lässt sich über variable Testschritte auf 14 verschiedene Gerätetypen anwenden, ohne den Testfall zu vervielfachen.
Wie der Testbetrieb über Tag und Nacht getaktet ist
Das Ziel ist klar: Alle notwendigen Branches laufen nachts vollautomatisch durch, vom Start bis zum ausgewerteten Bericht. Pro Nacht werden zwei Branches getestet, jeder rund vier bis fünf Stunden, weil die Geräte nicht doppelt belegt werden können und eine Queue dahinter steht.
Pro Branch laufen etwa 2000 Testfälle. Um sechs Uhr morgens sollen die Ergebnisse vorliegen. Am Wochenende läuft ein Kompletttest, der in der Größenordnung von 30 Stunden liegt.
Tagsüber sind die Geräte im Einsatz für andere Aufgaben. Dann gibt es On-Demand-Läufe, wenn ein Entwickler etwas geändert hat und das direkt prüfen will. Außerdem entsteht hier neues Testdesign, das Team gibt Debug-Support bei komplexen Fehlern, prüft die eigenen Packages nach Refactorings und pflegt die Hardware.
Die folgende Übersicht ordnet die Taktung:
| Zeitfenster | Aufgabe | Umfang |
|---|---|---|
| Nacht | Automatisierter Lauf, zwei Branches | ca. 2000 Testfälle pro Branch, 4 bis 5 Stunden je Branch |
| Wochenende | Kompletttest | rund 30 Stunden |
| Tagsüber | On-Demand-Läufe, Testdesign, Debug-Support, Hardwarepflege | nach Bedarf |
Risikobasiert testen heißt: nah am Kunden priorisieren
Das Team findet regelmäßig Fehler, und es priorisiert sie nach Wirkung. Kritisch ist, was dem Kunden wehtut oder viele Serviceeinsätze auslösen würde. Ein Fehler in der zehnten Unterebene eines Servicemenüs ist normalerweise weniger dringend.
Stabilisierungsbranches sind ruhiger, der Hauptzulieferbranch ist der kritischere. Ein klassisches Problem kennt jede Firma: Etwas wird geändert, und der Test bekommt es vorher nicht mit. Es kommt vor.
Gefundene Fehler bleiben nicht im Tool stecken. Das Team geht zu den Entwicklern, redet und klärt gemeinsam, wo das Problem liegt und wie es gelöst wird. Manche Störungen sind auch Infrastrukturprobleme, etwa ein ausgefallenes Netzwerk, die zuerst ausgeschlossen werden müssen.
Sicherheit testen, bevor das Gerät überhaupt Schaden nimmt
Der Personenschutz ist zunächst durch die Eigensicherheit der einzelnen Komponenten und deren Zulassung abgedeckt. Diese Schutzabschaltungen greifen spät, sie sollen Personen- und Gebäudeschaden verhindern, auch wenn das Gerät dabei schon zerstört ist.
Der Test setzt früher an. Er prüft die Abschaltungen, die die Software auslöst, bevor ein Geräteschaden entsteht. Wenn eine Komponente durchzuschalten droht, soll die Heizung rechtzeitig abschalten.
Solche Tests haben ihre eigenen Tücken. Ein leerer Dampfgenerator ist innerhalb kurzer Zeit kaputt, wenn man hineinheizt. Also darf er beim Test der Heizsperre nicht wirklich leer sein, das System muss aber annehmen, dass er es ist. An jede dieser Bedingungen muss man denken.
Genau hier hilft die Simulation. Ist die Heizung in vorgelagerten Tests bereits geprüft, spielt das Team Temperaturwerte direkt ins System ein und setzt gezielt ein Grad darüber oder darunter, um Heizabschaltungen auszulösen. So bleibt das Gerät heil, und der Test bleibt aussagekräftig.
Die eigentliche Herausforderung ist Skalierung, nicht Technik
Die größte Herausforderung ist das Skalieren mit der Entwicklung. Die Embedded-Entwicklung liegt bei rund 70 Software-Entwicklern an zwei Standorten, dem stehen zehn Leute in der Testautomatisierung gegenüber. Das Team will standhalten, ohne personell mit der Entwicklung gleichzuziehen.
Daraus folgt ein Strategiewechsel. Statt komplette Testframeworks und fertiges Testdesign zu liefern, verschiebt sich der Fokus Richtung Infrastruktur. Das Team stellt Hardware und Software für die Tests bereit, das Testdesign sollen zunehmend die Fachbereiche übernehmen.
Die Logik dahinter ist einleuchtend: Wer die Requirements ändert, kann die Tests gleich mitpflegen und im Gegenzug seine manuellen Tests reduzieren. Das verteilt die Last dorthin, wo das fachliche Wissen sitzt.
Hinzu kommt die räumliche Verteilung. Ein Labor steht in Landsberg, eines in Wittenheim in Frankreich, wo eine Tochtergesellschaft die Kippbratpfannensysteme betreut. Zwei Kollegen dort gehören fachlich zum Team. Regelmäßige Besuche in beide Richtungen halten die Zusammenarbeit zusammen und verhindern, dass sich Gruppen an je einem Standort verselbstständigen.
Test-Impact-Analyse als nächster Schritt
Der nächste große Hebel ist eine Test-Impact-Analyse. Das Team arbeitet daran, Testfälle automatisiert umzusortieren, je nachdem was sich im Code geändert hat. Statt jede Nacht stur denselben Block abzufahren, sollen die relevanten Tests nach vorn rücken.
Gefragt nach dem Highlight der kommenden Jahre, nennt Andreas zwei Dinge: dass die Test-Impact-Analyse läuft und dass das Team die Skalierung der Firma gut mitgemacht hat. Beide Ziele hängen zusammen, denn eine kluge Testauswahl ist genau das, was ein kleines Testteam neben einer wachsenden Entwicklung handlungsfähig hält.
Häufig gestellte Fragen
Welche Hardware braucht ein automatisierter Systemtest von Geräten mit hoher Leistungsaufnahme?
Neben dem Prüfling gehört eine eigene Testinfrastruktur in Racks dazu: Relaismodule, Remote-Stromversorgungen, Logic-Analyser und die Möglichkeit, Strom, Gas und Wasser gezielt an- und abzuschalten. Bei RATIONAL ist alles über Netzwerk erreichbar, bis hinunter zur seriellen Konsole am Gerät. Diese Hardware ist der teure Teil der Anlage, nicht die Software.
Was begrenzt die Laufzeit nächtlicher Testläufe auf echter Hardware?
Die Physik des Prüflings, nicht die Rechenleistung. Wenn ein Gerät zum Test der Heizung erst hochheizen muss, wartet der Testlauf die meiste Zeit auf diesen Vorgang. Ein Server mit acht Kernen und 8 GB Speicher managt 18 parallel laufende Testgeräte ohne Mühe. Zwei Branches pro Nacht brauchen dennoch je vier bis fünf Stunden.
Welche Teststufen sollte ein Testautomatisierungsteam für Embedded-Systeme übernehmen?
Nicht alle. Das Team bei RATIONAL konzentriert sich auf Systemtests, Regressionstests und Low-Level-Tests bis hinunter auf die Bussysteme. Unit- und Modultests bleiben bei der Entwicklung, Abnahmetests beim Anforderer. Diese Abgrenzung ist bewusst gesetzt: Wer alles testen will, testet am Ende nichts richtig.
Lohnt sich eine Skriptsprache gegenüber C oder C++ für ein Testframework?
Für den Testbau ja. Der Ausschlag gab, dass nichts kompiliert werden muss und viele Bibliotheken bereitstehen. Eine Netzwerk- oder serielle Verbindung, die in C oder C++ längeren Code kostet, sind in Python zwei Zeilen. Der Preis dafür ist eigene Package-Infrastruktur: mehrere selbst gepflegte Pakete, die automatisiert in eigene Registries geladen werden.
Wie hält man Testfälle für viele Gerätevarianten pflegbar?
Über abstrakte Testfälle mit variablen Testschritten statt Kopien pro Variante. Bei RATIONAL lässt sich ein Testfall so auf 14 verschiedene Gerätetypen anwenden, ohne ihn zu vervielfachen. Das Variantenmanagement übernimmt ein Testdesign-Tool, während GitLab die Pipelines und die Qualitätssicherung des eigenen Frameworks trägt.
Nach welchen Kriterien priorisiert man gefundene Fehler im Systemtest?
Nach Wirkung beim Kunden. Kritisch ist, was dem Anwender wehtut oder viele Serviceeinsätze auslösen würde. Ein Fehler in der zehnten Unterebene eines Servicemenüs ist normalerweise weniger dringend. Auch der Branch zählt: Stabilisierungsbranches sind ruhiger, der Hauptzulieferbranch ist der kritischere.
Wie prüft man Schutzabschaltungen, ohne den Prüfling zu zerstören?
Durch gezielte Simulation einzelner Messwerte im laufenden System. Ist die Heizung in vorgelagerten Tests bereits geprüft, spielt das Team Temperaturwerte ein und setzt sie ein Grad über oder unter die Schwelle, um die Abschaltung auszulösen. Beispiel: Ein leerer Dampfgenerator wäre beim Hineinheizen schnell defekt, also muss das System ihn nur für leer halten.
Was tut ein kleines Testteam, wenn die Entwicklung schneller wächst als es selbst?
Es verlagert das Testdesign dorthin, wo das fachliche Wissen sitzt. Zehn Leute in der Testautomatisierung stehen bei RATIONAL rund 70 Embedded-Entwicklern an zwei Standorten gegenüber. Statt fertige Tests zu liefern, stellt das Team Hardware, Framework und Infrastruktur bereit; die Fachbereiche schreiben und pflegen ihre Tests und reduzieren im Gegenzug manuelle Prüfungen.
