Dreh- und Angelpunkt eines jeden Releases oder Sub-Releases ist die Frage: Wurden schon alle erforderlichen und geplanten Testfallausführungen durchgeführt? Bei der Antwort helfen Coverages. Mit ihnen wird im Nu deutlich, wie hoch der Grad der Testfallabdeckung für bestimmte Anforderungen, Parameterräume oder Varianten ist. Ein kurzer, geschulter Blick reicht oft schon, um die Testergebnisse in den Grafiken und Tabellen richtig bewerten zu können.

Coverages werden anhand von Abdeckungsfiltern definiert. Diese Filter stecken die Randbedingungen für den Testumfang einer Anforderung ab, beispielsweise für welche Fahrzeugvariante oder Motorklasse getestet werden soll. Nur die Testausführungen, die den eingestellten Filtereigenschaften genügen, werden auch beachtet und in die Analyse einbezogen.

Coverages lassen sich für jede Herausforderung individuell erstellen. Dafür gibt es bereits vorgefertigte Beispiele, die auf jeweilige Filterdefinitionen angepasst werden können und den Einstieg erleichtern. Zudem vereinfacht die zugrunde liegende XML-Struktur die Generierung komplett eigener Skripte für Abdeckungsfilter. Der Import von Filtern nach TEST-GUIDE ist sowohl aus Dateien und ALM-Systemen (z. B. Polarion, HP-ALM, Octane) als auch automatisiert über die REST-API möglich, z.B. für Continuous-Integration-Lösungen.

Im Kern geht es darum, einen Testauftrag an den richtigen Prüfplatz zu verteilen. Klingt erstmal einfach. Sollen aber tausende Testaufträge parallel, automatisiert und kontinuierlich auf skalierbare Testressourcen verteilt werden, ist volle Power gefragt. Gut, dass TEST-GUIDE hier die richtige Strategie verfolgt.
Mit TEST-GUIDE wird die Ausführung der Tests so automatisiert, dass sie nicht nur auf passend konfigurierten Prüfständen, sondern auch in der Reihenfolge ihrer Priorisierung ausgeführt werden. Hinzu kommt noch die optimale Nutzung der verfügbaren Testressourcen, damit kein Leerlauf entsteht.

Für letzteres sorgt der ResourceAdapter. Eine Software, die auf den Prüfständen installiert wird und durchgehend Informationen über Vitaldaten, Konfigurationen und Testfallausführungen an den zentralen TEST-GUIDE Server sendet. Dadurch kann die Testausführung live entscheiden, auf welchem Prüfstand der nächste Testauftrag ausgeführt werden kann. Darüber hinaus sorgt der ResourceAdapter dafür, dass der Prüfstand für den Test vorbereitet ist. Er checkt Repositories aus, kopiert Daten hin und her und löst weitere zusätzliche Abhängigkeiten auf – alles anhand der Beschreibung im Playbook.

Playbooks können in ECU-TEST erstellt und über die integrierte Schnittstelle direkt nach TEST-GUIDE hochgeladen werden. Auch die direkte Erstellung in TEST-GUIDE ist möglich. Darin beschrieben werden der zu verwendende Workspace inklusive der relevanten Testfälle, die Parametrierung globaler Konstanten, die Testbench-Konfiguration sowie das Clean-up nach der Ausführung. Mit Playbooks gelingt der Prozess der automatisierten Verteilung der Testaufträge auf physischen und virtuellen Prüfständen also noch komfortabler. Nämlich bereits beim Erstellen der Testsuite. Continuous Testing? Done.

Gerade bei vielen Testausführungen ist es überaus wichtig, die Testressourcen im Auge zu behalten. Zu wertvoll ist die Zeit am Prüfstand, um sie ungenutzt verstreichen zu lassen. Verfügbarkeit, Auslastung, Festplattenspeicherkapazität, Konfigurationen, laufende Testausführungen – all das gilt es zu maximieren.

Bewusst haben wir deshalb eine Schippe mehr drauf gepackt. Oder genauer gesagt, ein kleines Add-on: den ResourceAdapter. Er ist ein Agent, mit dem ein solch umfassendes Monitoring der Testressourcen gelingt. Einmal installiert, überträgt er über die Monitoring- API beständig sämtliche Informationen der Prüfstands-PCs an den zentralen TEST-GUIDE Server. Dort werden diese Daten zusammengeführt und sind in Echtzeit abrufbar – in unterschiedlichen Ansichtsoptionen, je nach Interesse.

Mit diesen umfassenden Details über angebundene Testressourcen lässt sich, beispielsweise in einer Continuous-Integration-Umgebung, einfach ermitteln, welcher Prüfstand für die nächste Testausführung bereit ist. Oder auch, wie hoch die Leistung und die Dauer während der letzten Ausführungen waren.

Normalerweise ist es enorm aufwendig, Testreports, also die Ergebnisse unzähliger Testausführungen, zu verwalten, zu sichten und zu analysieren. Nicht mit TEST-GUIDE. Das Tool zentralisiert die Ergebnisse in einer Datenbank und hilft mit vielen unterschiedlichen Filter- und Auswertemöglichkeiten dabei, relevante Testreports für ein Release abzugrenzen.

Der Import der Testreports erfolgt aus ECU-TEST automatisiert, ist aber auch für nutzerspezifische Testwerkzeuge dank der standardisierten ASAM-ATX Schnittstelle einfach möglich. Sobald die Testreports in TEST-GUIDE zur Verfügung stehen, kann die Auswertung der Testdurchläufe gezielt beginnen. Neben Testplänen und Teststatistiken stehen dafür umfangreiche zeit- und ereignisbasierte Filtermöglichkeiten bereit.

Testläufe und Regressionstests vergleichen, Testschritte nachvollziehen, Trends erkennen, Fehler beurteilen oder Übersichtsdiagramme erstellen. Der Ergebnisfilter ist hier die erste Wahl. Er ist das Multifunktionswerkzeug, wenn es auf Details ankommt. Über gesetzte Filtereigenschaften lassen sich eigene visuelle Dashboards entwerfen, die Testergebnisse gezielt nach Bedarf anzeigen. Auch das Team profitiert davon. Denn jeder Filter kann abonniert, exportiert oder per E-Mail geteilt werden.

Für noch mehr Extra sorgt die umfangreiche Review-Funktion. Mit ihr lassen sich für fehlgeschlagene Testläufe Notizen erfassen, Nachbewertungen vornehmen oder auch Defect-Tickets erstellen. Letzteres ist über die integrierte Anbindung an Ticketsysteme, wie Jira, Redmine, HP ALM.net oder Octane, einfach möglich. Ergänzend stehen verschiedene Exportoptionen (PDF, Excel, Test-Management-Tools, ATX-Dokumente und vollständige Backups) bereit, um jede Form von Ergebnisberichten zu teilen oder zu speichern. Für den kontinuierlichen Informationsfluss zu jeder Zeit und von überall – sowohl vom Arbeitsplatz als auch von unterwegs über mobile Endgeräte.

Wie eine Klammer schmiegt sich das Release um alle Testvorgänge. Verbindet Anfang und Ende. Vergleicht Ist-Zustand mit Soll-Zustand. Hilft, Entscheidungen zu treffen. Auch die Entscheidung, ob ein Release geschlossen werden kann. Das geschieht, wenn der anfänglich festgelegte Testumfang erfolgreich umgesetzt wurde. Der Workflow für ein Release ist fast immer gleich. Erstellen > Überwachen > Unregelmäßigkeiten aufdecken > Nachrüsten > Gegebenenfalls ergänzen > Prüfen > Schließen. Der Unterschied liegt dabei in der Erstellung.

Denn ein Release kann im Vorfeld oder im Nachgang angelegt werden. Baut sich das Release auf bereits erfolgten Testausführungen auf, werden relevante Testreports über den Ergebnisfilter gefiltert und einem Release zugewiesen. Oftmals wird aber ein Release schon vor der ersten Testfallausführung angelegt, während der Planungsphase.

Dann stellt ein definierter Coverage-Filter mit einem bestimmten Umfang an Anforderungen die Basis dar. Alle Testreports, die diesen Anforderungen genügen, werden automatisiert dem entsprechenden Release zugeordnet. Solange, bis das Release geschlossen wird.

Steht ein Release, bemisst sich der Erfolg an bestandenen Tests und fortgeschrittener Coverage. Mit der Release-Übersicht wird man bestens über den Status informiert – sowohl grafisch als auch in tabellarischer Form. Zudem lässt es sich von hier aus einfach per Klick in jeden Release-relevanten Bereich von TEST-GUIDE navigieren. Praktisch! Vor allem, wenn es mehrere Releases gleichzeitig zu organisieren gibt. Wurde das Release erfolgreich geschlossen, können die Ergebnisse in unterschiedlichen Formaten exportiert werden (ALM-Systeme, z.B. Polarion oder Octane, Excel, PDF).