Mobile-Menu

Intelligente Testautomatisierung in der Praxis

Autor / Redakteur: Dr. Roman Nagy und Hermann Ilmberger* / Sebastian Gerstl

Testautomatisierung ist heute ein fester Bestandteil vieler Softwareprojekte. Testfälle werden automatisch ausgeführt, ein Testreport wird generiert. In einigen Projekten werden durch modellbasierte Ansätze Testfälle aus einem Testmodell automatisch generiert. Reicht das aber? Wo ist die Grenze des Möglichen und wo die des Sinnvollen?

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH
Axivion GmbH
Parasoft® Deutschland GmbH
Testautomatisierung hat sich inzwischen als Konzept in der Softwareentwicklung durchgesetzt. Aber in welchem Maß ist es für ein individuelles Projekt wirklich sinnvoll?
Testautomatisierung hat sich inzwischen als Konzept in der Softwareentwicklung durchgesetzt. Aber in welchem Maß ist es für ein individuelles Projekt wirklich sinnvoll?
(Bild: gemeinfrei / Pixabay )

Der Zweck der Testautomatisierung ist es, die manuellen Aufwände im Testprozess auf das Minimum zu reduzieren. Die Testarchitekten müssen sich immer die Frage stellen: „Was kostet mich die meiste Zeit?“.

Es muss eine Analyse durchgeführt werden, die die richtigen „Zeitfresser“ aufdeckt. Sonst läuft man die Gefahr, dass Testaktivitäten automatisiert werden, die hätten ohne weiteres auch manuell durchgeführt werden können. Auf der anderen Seite bleiben zeitintensive Aufgaben immer noch manuell. Eine solche Analyse sollte idealerweise iterativ durchgeführt werden, um immer den nächsten Schritt in der Testautomatisierung zu bestimmen.

Auch die Einführung der Testautomatisierung kostet Aufwand – und oft nicht wenig – deshalb ist es sehr wichtig das Richtige und zum richtigen Zeitpunkt zu automatisieren. Eine solche Analyse wurde auch in einem der Softwareprojekte bei BMW durchgeführt. Es handelt sich um ein Projekt für die Entwicklung des zentralen Steuergeräts für Body Funktionen im Fahrzeug, dem sogenannten Body Domain Controller. Die Software in diesem Steuergerät steuert die Kunden-Grundfunktionen, die in jedem Fahrzeug notwendig sind.

Es handelt sich um Funktionen wie z.B. elektrischer Fensterheber, Wischer, Außenlicht, Innenlicht oder Fahrzeugzugang. Insgesamt steuert das Steuergerät über 150 Kundenfunktionen, die einen hohen Vernetzungsgrad mit anderen Funktionen im Fahrzeug aufweisen. Die Softwaregröße beläuft sich auf über 2,3 Millionen Lines of Code.

Bereits zu Beginn des Projekts wurde festgelegt, dass alle Testfälle automatisch ausführbar sein müssen. Sie kommunizieren mit dem Steuergerät ausschließlich über eine Schnittstelle in der Form von Bus-Nachrichten und digitalen und analogen Ein- und Ausgängen. Die Testautomatisierung wurde in drei aufeinander folgenden Phasen eingeführt:

  • Dezentrale Steuerung der Testausführung
  • Zentrale Steuerung der Testausführung
  • Optimierte Steuerung der Testausführung und der Analyse

Dezentrale Steuerung der Testausführung

In der ersten Phase des Projekts wurde für jede Funktionsgruppe (sog. Domäne) ein HiL-Testaufbau zur Verfügung gestellt. Die Testfälle wurden als kleine Programme manuell in VB.Net implementiert und über eine proprietäre Schnittstelle auf die Nachrichten und Ein-/Ausgänge des Steuergeräts abgebildet. Die Testausführung einer Testserie wurde pro HiL-Testaufbau immer abends manuell gestartet. Die Testergebnisse wurden am nächsten Tag in der Früh gesammelt und manuell zu einem Testreport zusammengefügt.

Diese Vorgehensweise wurde schnell etabliert und brachte rasch gute Ergebnisse. Die Tester waren in der Lage, sehr schnell neue Testfälle zu implementieren und zusammen mit den Entwicklern die fehlerhaften Situationen für das Debugging nachzustellen. Allerdings brachte diese Vorgehensweise auch einige Nachteile:

  • Unzuverlässige bzw. fehlende Testergebnisse. Da die HiL-Testaufbauten auch für Debugging-Zwecke verwendet wurden, wurden sie am Tag oft anders konfiguriert, als die automatisierte Testausführung verlangt hat. Am nächsten Tag lagen deshalb oft nicht komplette oder falsche Ergebnisse vor, die man sich aber trotzdem manuell anschauen musste.
  • Zu komplizierte Testfälle. Obwohl VB.Net als die Sprache für die Testfälle ein schnelles Erstellen von Testfällen bot, war ihr Nachteil die Mächtigkeit der Sprache. Es wurden immer kompliziertere Konstrukte in die Testfälle rein implementiert und die Tester brauchten immer mehr Zeit, sowohl eigene als auch Testfälle von anderen Testern zu verstehen und nach einer Software-Änderung anzupassen.
  • Unzureichende Anzahl der neuen Testfälle. Da die Tester oft in Debugging-Tätigkeiten gebunden waren, fehlte regelmäßig die Zeit um neue Testfälle zu erstellen.

Zentrale Steuerung der Testausführung

Aufgrund dieser Nachteile wurden in der zweiten Phase der Testautomatisierung mehrere Änderungen beschlossen und umgesetzt. Die HiL-Aufbauten wurden zentralisiert und die Testausführung wurde durch ein zentrales Steuerungssystem ASIA (Automated Software Integration and Automation) übernommen. Die Aufgabe von ASIA war es, die Testfälle auf alle existierenden HiL-Aufbauten zu verteilen und die Ergebnisse nach dem Testlauf wieder zusammenzufahren.

Der manuelle Schritt des Startens und vor allem der manuellen Zusammenführung der Testergebnisse entfiel. Gleichzeitig wurde der Aufwand für die Analyse von Infrastrukturproblemen deutlich reduziert, da keine händischen Aktionen mehr auf den Testrechnern ausgeführt wurden, sondern nur noch definierte automatische Einstellungen. Die HiL-Aufbauten wurden in einen zentralen Raum verlagert, was ebenfalls ein falsches Konfigurieren erschweren würde.

Zusätzlich wurde für die Testfallerstellung eine Domain Specific Language namens tCF [1] entwickelt und ausgerollt, um die Übersichtlichkeit und Lesbarkeit der Testfälle zu erhöhen. Es wurden modellbasierte Ansätze eingesetzt, um verschiedene Varianten eines Testfalls automatisch generieren zu lassen [2, 3]. Dadurch konnten sich die Tester noch stärker auf die zu testende Funktionalität konzentrieren. Der manuelle Aufwand für das Verstehen, Durchsuchen und Anpassen der Testfälle wurde deutlich reduziert.

Durch diese Änderungen ist die Anzahl der Testfälle deutlich von ca. 1.000 auf über 10.000 gestiegen. Das allerdings brachte das Projekt vor eine neue Herausforderung. Mit der Anzahl der Testfälle ist automatisch auch die Anzahl der roten Testfälle pro Testlauf gestiegen. Und dadurch stieg auch die Zeit, die die Tester benötigen, um sich diese anzuschauen, sie zu analysieren.

Es wurde schnell klar, dass die Analysezeiten bei dieser Menge von Testfällen so groß werden, dass die Tester keine Zeit mehr haben, neue Testfälle zu entwickeln oder die alten bei Bedarf anzupassen. Es wurde deshalb eine Lösung entwickelt, mit der man direkt in ASIA das rote Ergebnis eines Testfalls mit der eigentlichen Ursache für das Scheitern verbinden konnte (dem sogenannten Root-Cause), meistens in Form eines JIRA-Tickets. Solange der Root-Cause nicht behoben wurde (also das Ticket nicht geschlossen wurde), wird der Testfall in weiteren Läufen nicht mehr zur Analyse angezeigt.

Damit war ein erster Schritt getan, um den manuellen Aufwand zu reduzieren – es mussten nicht mehr alle gescheiterten Tests analysiert werden. Es war aber klar, dass auch die Zahl der insgesamt ausgeführten Tests deutlich reduziert werden musste – es sollten nur noch die „richtigen“ Testfälle ausgeführt werden.

Optimierte Steuerung der Testausführung und der Analyse

In der dritten Phase wurden deshalb im ASIA-System Algorithmen entwickelt, die nicht alle, sondern nur die „richtigen“ Testfälle auswählen und ausführen. Es sollte für jeden Testlauf die optimale Menge der Testfälle dynamisch ausgewählt werden, bei der die Wahrscheinlichkeit dafür, einen Fehler in der zu testenden Software zu finden, am höchsten ist. So bleibt das Ziel des Testens – Fehler zu finden – im Fokus, trotzdem wird der Aufwand für die manuelle Analyse der roten Testfälle deutlich reduziert.

Es wurden mehrere Ansätze gewählt, die eine solche optimale Menge der Testfälle finden sollten. Dabei wurde sowohl die Historie der Test-fälle als auch die Zugehörigkeit zu den aktuellen Software-Änderungen betrachtet. Ebenso wurde die Laufzeit der Testfälle berücksichtigt, um das Ausführungsfenster voll auszuschöpfen, aber nicht zu überlasten.

Bei der Auswahl der Testfälle wurden diese Hauptkriterien ausgewertet:

  • Basisfunktionalität: Eine Standard-Serie, die die Grundfunktionalität abtestet. Wenn Tests daraus scheitern liegt ein größeres Problem vor.
  • Alter des Testfalls: Neue Testfälle, die neu implementierte Funktionalität testen, wurden stärker gewichtet.
  • Rot-Grün Kipper: Testfälle, die den Zustand rot/grün oft wechseln und dadurch viele Fehler finden, wurden stärker gewichtet.
  • Commit-basierte Auswahl: Testfälle, die Funktionalität testen, die jüngst durch einen Source-Code-Commit geändert wurde, wurden stärker gewichtet.

Zusätzlich zu der optimierten Testauswahl wurde auch die Analyse der roten Testfälle deutlich beschleunigt. Durch wissensbasierte Algorithmen wurden virtuelle Beziehungen zwischen einzelnen Testfällen erstellt. Die Semantik einer solchen Beziehung ist, dass Testfälle, die die gleiche oder eine ähnliche Ursache für das Rotwerden vorweisen, verknüpft werden.

Dies bedeutet, dass nur einer der Testfälle analysiert werden muss. Die verknüpften Testfälle haben mit einer gewissen Wahrscheinlichkeit den gleichen Fehler gefunden. Diese Verknüpfungen werden aus den früheren Test- und Analyse-Ergebnissen vor jedem Testlauf dynamisch neu ermittelt.

Fazit

In den letzten drei Jahren haben wir im Projekt erfahren, dass die Möglichkeiten zur Reduzierung manueller Aufwände weit über die Automatisierung der Ausführung der Testfälle hinaus reichen. Man muss darüber hinaus analysieren, welche Aktivitäten im Testprozess viel Aufwand kosten und ob diese mit vertretbaren Kosten automatisiert werden können. Das Ergebnis ist dann ein hoch-automatisierter und vor allem ein skalierbarer Testprozess.

Literatur und Quellenverzeichnis

[1] R. Nagy, Use-Case-basiertes Testen von AUTOSAR-Softwarekomponenten, ATAMI 2012, Berlin

[2] R. Nagy, Der Weg der Effizienz bei der Absicherung von Automotive-Software, German Testing Day 2013, München

[3] H. Ilmberger, Interactive Testing of Automotive Functions, ETSI UCAAT 2014, München


​


* Roman Nagy ist als Softwareingenieur bei der BMW Group in München tätig. In seiner aktuellen Rolle verantwortet er als Gruppenleiter die Entwicklung und Absicherung von mehreren Softwarekomponenten für aktuell entwickelte Fahrzeugmodelle.

* Hermann Ilmberger entwickelt Fahrzeug-Software bei der BMW Group in München. Außerdem verantwortet er die Plattform zum automatischen Software-Test.

(ID:44842618)

Weiterführende Inhalte