... das aus der klassischen Software-Entwicklung etablierte Software-System Jenkins. Über das „ECU-TEST Jenkins Plug-in“ ist eine Interaktion von Jenkins mit ECU-TEST und damit auch mit der Testumgebung möglich. Der Workflow zur automatischen Testausführung mit Jenkins würde ungefähr so aussehen: Jenkins überwacht ein Datei-, Versionierungs- oder Ticketsystem. In diesem System werden neue Testaufträge hinterlegt. Sobald ein neuer Testauftrag erkannt wird, müssen ein geeigneter Prüfplatz bestimmt und anschließend die notwendigen Tests dort ausgeführt werden. Abschließend werden alle produzierten Ergebnisse in eine Ergebnisverwaltung, wie zum Beispiel TEST-GUIDE, zurückgespielt. Dort können sie dann letztendlich analysiert und ausgewertet werden.
Es hat sich in unserem Projektalltag allerdings gezeigt, dass die technischen Fragestellungen beim Aufbau einer Continuous-Testing-Lösung die einfacheren sind. Die größten Herausforderungen liegen in der Harmonisierung von Prozessen, der Verständlichkeit und Nachvollziehbarkeit von Arbeitsschritten, sowohl innerhalb der Tests als auch während der Ausführung, sowie in der Beschaffung von benötigten Informationen. Und leider wachsen diese Herausforderungen mit der Größe des Absicherungsteams.
Unsere Erfahrungen haben gezeigt, dass für den Aufbau einer Continuous-Testing-Lösung eine Reihe von Voraussetzungen erfüllt sein müssen. Wir haben versucht, diese Erfahrungen in Best Practices zu verpacken. Einige davon beziehen sich nicht ausschließlich auf eine hochautomatisierte Testausführung. Und nicht alle davon müssen vollständig umgesetzt sein, aber der Weg dahin sollte gegangen werden.

Um Steuergeräte (ECUs) möglichst realitätsnah abzusichern, werden diese an sogenannten Hardware-in-the-Loop-Prüfständen (HiLs) getestet. Der HiL simuliert die für den Betrieb des Steuergerätes nötigen Eingangs- und Ausgangssignale. Damit ist es möglich, die ECUs in definierte Betriebszustände zu versetzen. Die Echtzeitsteuerung des Prüfplatzes übernimmt dabei ein Modell, was auf dem HiL ausgeführt wird.
Damit kann man überprüfen, ob gewisse Stimulationen die erwarteten Reaktionen auslösen. Diese Tests werden mit der Testautomatisierungs-Lösung ECU-TEST ausgeführt.
Die wesentliche Aufgabe der Testenden ist es dabei, die Ursache der Abweichung in diesem komplexen System aus HiL, Modell, Hardware und Software zu identifizieren.
Das Testobjekt ist in unserem Projektkontext die Software, die auf dem Steuergerät ausgeführt wird. Jedoch kann immer nur Hardware und Software im Zusammenspiel getestet werden (im Gegensatz zu Software-in-the-loop-Tests).
Die Testumgebung bezeichnet die Gesamtheit aus Prüfplatz, Modell, Messtechnik, Restbussimulation, benötigten Software- und Hardware-Tools sowie Mess- und Simulationsrechner.
Ein Testfall prüft eine einzelne Anforderung oder Funktion des Testobjekts. Ein Testfall stellt die nötigen Voraussetzungen zu Beginn selbst her und setzt diese am Ende wieder zurück.
Ein Testkapitel ist eine inhaltliche Gruppierung von Testfällen.
Der Testauftrag beinhaltet alle zur Testausführung nötigen Informationen. Konkret sind das das Testobjekt, die durchzuführenden Testfälle und Testkapitel sowie alle für den Test notwendigen Artefakte.
Jenkins ist ein erweiterbares, webbasiertes Software-System zur kontinuierlichen Integration von Komponenten.
Auf Basis vonTriggern führt Jenkins sogenannte Jobs aus. In diesen Jobs ist die Abarbeitungslogik hinterlegt. Trigger können zeitlich, durch Ereignisse im Datei- oder Versionierungssystem oder durch andere Jobs ausgelöst werden.
Jenkins bietet die Möglichkeit, den Funktionsumfang über Plug-ins zu erhöhen.
Pipeline ist ein Jenkins Plug-in, das die Definition sogenannter Stages erlaubt. Stages bieten die Möglichkeit, die Job-Abarbeitung zu strukturieren, beispielsweise in „Vorbereitung“, „Testausführung“ und „Nachbereitung“. Es ist damit einfacher, Fehler im Ablauf einzugrenzen.
Ist eine automatisierte Testausführung durchgängig möglich?
Grundvoraussetzung für eine Continuous-Testing-Lösung ist, dass die Arbeitsschritte soweit automatisiert sind, dass zur Testausführung keine manuellen Schritte mehr nötig sind. Manuelle Schritte sind zum Beispiel das Hinzufügen fehlender Artefakte oder Anpassungen an Testumgebung oder Testobjekt.
Trennen Sie die Ausführungslogik von der Businesslogik
Die Businesslogik beinhaltet die Fragestellungen, was womit getestet wird. Dazu zählen Fragen wie:
- Welche Testumfänge sind für das Testobjekt relevant?
- Welche Artefakte werden für die Ausführung benötigt? Wo find ich diese?
- Welche zusätzlichen Informationen gehören zu meinem Testobjekt? Woher bekomme ich diese?
Die Businesslogik erstellt bzw. ergänzt den Testauftrag. Die Ausführungslogik dagegen kümmert sich um die Abarbeitung des Testauftrags und aller notwendiger Schritte zur Vorbereitung und Einrichtung des Prüfplatzes. Gerade die Businesslogik ist sehr anspruchsvoll und bietet viele Fallstricke. Unter Umständen lässt sich diese auch nicht vollständig automatisieren. Durch die Trennung ist es zumindest möglich, die Ausführung vollautomatisiert abzuarbeiten. Ein weiterer Vorteil der Trennung ist, dass sich diese beiden komplexen Systeme unabhängig voneinander besser warten und weiterentwickeln lassen.
Versuchen Sie die Testfälle so lesbar wie möglich zu halten
Mit der automatisierten Testausführung werden auch automatisiert viele Testergebnisse erzeugt. Im Fehlerfall muss jedoch in letzter Instanz ein Mensch die Tests bewerten. Dabei ist es ungemein von Vorteil, wenn man auf einem Blick erkennt, wo das Problem liegt.
Die Lesbarkeit von Testfall-Packages in ECU-TEST kann man durch eine Strukturierung mit Blöcken erhöhen. Außerdem sollte man drauf achten, dass die Struktur im Package flach bleibt. Idealerweise sind die Testfälle so aufgebaut, dass auch Personen, die nichts vom Testen am Prüfplatz verstehen, wie aus der Funktionsentwicklung oder -applikation, diese verstehen können.
Einigen Sie sich auf eine gemeinsame Arbeitsweise
Sonderbehandlungen sind möglich, aber sehr umständlich in der Wartung. Versuchen Sie daher, Ihren Workflow bei der Absicherung möglichst gleich zu halten. Unterschiedliche Behandlungen sollten vorher bekannt und explizit angegeben sein.
Geben Sie Informationen immer explizit an
Sowohl für die Ausführung eines Testfalls als auch für die Gesamtausführung werden oftmals weitere Informationen benötigt. Diese sollten immer explizit im Testauftrag angegeben sein. Das können sein:
- Testfallparametrierungen (z. B. unterschiedliche Leerlaufdrehzahl von Benziner und Diesel)
- Dynamische Testumfänge (z. B. spezielle Testfälle für Automatik und Handschalter)
- Exporteinstellungen bei unterschiedlichen Testtypen
- Weitere Artefakte, wie die der Testkonfiguration (z. B. tcf-, gcd-Dateien)
Informationen, die erst zur Laufzeit ermittelt werden, haben zwei wesentliche Nachteile: Zum einen ist bei der unbedarften Anwendung nicht klar, warum bei zwei verschiedenen Ausführungen zwei unterschiedliche Ergebnisse auftreten können. Zum anderen besteht bei implizit ermittelten Informationen oft das Problem der Pflege und Wartung, da der Zeitpunkt der Ermittlung während der Laufzeit nicht transparent ist.
Machen Sie einen Schritt nach dem anderen
Für die Jenkins-Jobs gilt: Je modularer sie geschnitten sind, desto einfacher lassen sie sich handhaben. Für komplexere Jobs empfiehlt sich die Verwendung von Pipelines. Damit lassen sich sogenannte Stages definieren und man kann schneller sehen, an welcher Stelle der Abarbeitung es zu einem Problem kam.
Modulare Jobs bieten außerdem den Vorteil, dass man sie einzeln (neu-)starten kann. Somit ist es z. B. möglich, unterschiedlich auf Fehler zu reagieren, je nachdem ob man sich in der Vorbereitung oder Ausführung eines Tests befindet.

Versuchen Sie so viel von der Tool-Kette zu testen wie möglich
Jede Änderung an Ihrem Absicherungsprozess sollte gut geprüft werden. Nichts erzeugt mehr Frust als eine schnelle Anpassung, die mehrere dutzend Prüfplätze plötzlich nur noch Datenmüll produzieren lässt. Beispiele:
- Ein neuer Testfall wurde nur für eine Variante in Betrieb genommen
- Ein Bibliotheks-Package muss angepasst werden
- Änderung an der Prüfplatzumgebung
Die gute Nachricht ist, die Continuous-Testing-Lösung hilft Ihnen dabei!
Mehrwerte für die Kundinnen und Kunden
Erhöhung der Auslastung von Prüfständen
Durch die automatische Abarbeitung von Testaufträgen kann ein Prüfplatz solange ausgelastet werden, wie geeignete Testaufträge vorhanden sind. Das ist besonders wertvoll für Absicherungen über Nacht oder am Wochenende.
Verbesserte Testabdeckung und -tiefe
Die Möglichkeit mehr Tests durchzuführen schafft die Kapazitäten um entweder mehr Testobjekte (Testabdeckung) oder einzelne Testobjekte intensiver (Testtiefe) abzusichern.
Schnelles Feedback für die Entwicklung
Eine höhere Prüfplatzauslastung heißt auch, dass Ergebnisse schneller zur Verfügung stehen und somit schneller wieder in die Software-Entwicklung einfließen können.
Fokussierung des Absicherungsteams
Durch die erhöhte Zuverlässigkeit und die verbesserte Lesbarkeit von Testfällen müssen Testende weniger Zeit in die Analyse von Abweichungen investieren, gegebenenfalls können funktionale Abweichungen des Testobjekts sogar direkt von der Entwicklung analysiert werden. Die Testenden haben so die Möglichkeit, frei werdende Kapazitäten in die Entwicklung von Testfällen oder die Wartung der Testumgebungen zu investieren.
Skalierbarkeit der Continuous-Testing-Lösung
Die zentrale Verwaltung und Steuerung über den Jenkins-Server ermöglichen es, neue Testumgebungen einfach zu integrieren."