Vorschau_eCall

Hohe Softwarequalität durch mocking und massive Automatisierung

Einleitung

Wir haben für einen Kunden den Softwaretest für ein eCall Steuergerät durchgeführt. Der eCall (Emergency Call) soll im Falle eines Unfalls einen Notruf auslösen, damit den Betroffenen schnell und zielgerichtet geholfen werden kann und die Hilfe gerade in entlegenen Gebieten schneller eintreffen kann. (Mehr dazu in der Wikipedia: https://de.wikipedia.org/wiki/ECall)

Da beim Notruf der Anruf zuverlässig funktionieren muss, sind möglichst viele verschiedene Szenarien durchzuspielen, um sicherzustellen, dass die Implementierung der eCall Softwaremodule diese auch erfüllt.

Da die Software auf dem eCall Steuergerät während der Entwicklung ständigen Änderungen unterworfen ist, ist es unerlässlich die Tests zu automatisieren, um schnell und zuverlässig eine Rückmeldung darüber zu erhalten, ob sich durch aktuelle Softwareänderungen eventuell Fehler in das bereits bestehende System eingeschlichen haben.

In diesem Artikel beschreibe ich, welche Maßnahmen wir ergriffen haben, um die Softwaretests im Bereich der Telefonie zu automatisieren, auf welche Schwierigkeiten wir dabei gestoßen sind und wie wir mit diesen umgegangen sind.

Dazu werde ich zuerst einen groben Überblick über die Anforderungen an das eCall Steuergerät geben und anschließend mögliche Tests beschreiben. Anhand dieser Tests werde ich dann zeigen, warum eine Automatisierung in diesem Kontext aus meiner Sicht unerlässlich ist. Zuletzt stelle ich die Lösung vor, die wir für unser Testszenario gewählt haben.

Anforderungen an ein eCall Steuergerät

Ein typisches eCall Szenario
Ein typisches eCall Szenario

Wenn ein eCall ausgelöst wird, versucht das Steuergerat zuerst eine Verbindung mit dem Callcenter des Fahrzeugherstellers herzustellen. Nur wenn dies nicht gelingt, versucht es eine Telefonverbindung mit der öffentlichen Notrufzentrale (112) aufzubauen.

Beim Verbindungsaufbau mit dem Callcenter des Fahrzeugherstellers wird zusätzlich eine SMS (auch MSD-SMS genannt, wobei MSD für Most Significant Data steht) mit den wichtigsten Informationen über das Fahrzeug (Auslösezeitpunk, Fahrzeugidentifikation, vermutete Anzahl Personen, etc.) an das Callcenter gesendet, damit zielgerichtet Hilfe geleistet werden kann.

Des weiteren ist das Steuergerät in der Lage SMS vom Callcenter zu empfangen, die bestimmte Kommandos enthalten, wie zum Beispiel das Beenden des eCalls, das erneute Senden der MSD-SMS oder das Weiterleiten des Anrufes an ein Abschleppunternehmen.

Ein eCall kann automatisch, zum Beispiel beim Auslösen des Airbags, oder manuell per Knopfdruck ausgelöst und von beiden Seiten beendet werden.

Mögliche Testszenarien

Schon aus dieser groben Beschreibung der Anforderungen ergeben sich mehrere mögliche Testszenarien, welche die Funktionalität des Steuergerätes testen.

  1. Teste, ob ein manueller eCall gestartet und beendet werden kann
  2. Teste, ob das Steuergerät beim Auslösen des eCalls ein Anruf zum Callcenter startet
  3. Teste, ob das Steuergerät ein Anruf zur Notrufzentrale startet, wenn der Rufaufbau zum Callcenter fehlschlägt

Dies sind drei mögliche Testszenarien, die sich noch weiter in spezifischere Testfälle zerteilen ließen, was aber für diesen Artikel zu weit führt. Diese drei Szenarien sind ausreichend, um zu verdeutlichen, warum eine Automatisierung dieser Tests unerlässlich ist.

Beispiel für eine Testfallbeschreibung

Für die im nächsten Abschnitt folgende Aufwandsabschätzung werde ich das zuerst beschriebene Testszenario in eine detaillierte Testbeschreibung überführen:

Vorbedingungen:

  • Das Steuergerät ist in Betrieb.
  • Das Steuergerät ist mit dem GSM-Netz verbunden.
  • Das Steuergerät ist im Testmodus (spezieller Modus, bei dem Notrufe nicht zu eigentlichen Nummern aufgebaut werden, sondern an ein Testcallcenter).
  • Die eCall-Taste ist mit dem Steuergerät verbunden.

Testschritte:

Testschritt
Erwartetes Ergebnis
1. Drücke eCall-Taste
  • Steuergerät löst eCall aus
  • Steuergerät versendet die MSD-SMS
  • Steuergerät baut eine Sprachverbindung zum Test-Callcenter auf
2. Warte bis Sprachverbindung zum Test-Callcenter aufgebaut wurde. Die Sprachverbindung ist spätestens 10 Sekunden nach drücken der eCall-Taste aktiv.
3. Verifiziere, ob MSD-SMS mit korrektem Inhalt empfangen wurde Die MSD-SMS enthält die korrekten Informationen (welche diese sind, ist für unseren Fall nicht relevant)
4. Beende Sprachverbindung
  • Das Steuergerät hat die Sprachverbindung erfolgreich beendet
  • Das Steuergerät ist im Nach-eCall-Status

Aufwandsabschätzung/-abwägung

Um ermitteln zu können, wie lange das Ausführen eines Tests dauert, müssen ein paar Annahmen getroffen werden:

  • Es dauert ca. 60 Sekunden, bis das Steuergerät vollständig in Betrieb und mit dem GSM-Netz verbunden ist (Kaltstart).
  • Das Drücken der eCall-Taste dauert etwa 5 Sekunden, wenn der Tester sich in einer “Ruheposition” befindet, und der Finger nicht auf der eCall-Taste bereit liegt.
  • Der Rufaufbau, bis das Call-Center den Anruf annimmt, dauert 10 Sekunden
  • Der Inhalt der MSD-SMS kann über ein Webinterface vom Call-Center abgefragt werden. Dafür ist eine Benutzerauthentifizierung erforderlich.

Unter diesen Annahmen dauert die Testausführung vom Kaltstart des Steuergerätes bis der eCall beendet ist etwa 100 Sekunden, wenn der Anruf etwa 30 Sekunden aktiv gehalten wird, bevor der eCall beendet wird. Anschließend muss noch die MSD-SMS ausgewertet werden. Dazu muss man sich beim Webinterface des Callcenters anmelden, um den Inhalt der MSD-SMS auswerten zu können. Der Inhalt der SMS wird auf dem Webinterface decodiert dargestellt. Der Abgleich der Daten ist fehleranfällig, da er manuell gemacht werden muss und falsche Werte dabei durchaus schon des Öfteren übersehen wurden. Die Auswertung der MSD-SMS dauert somit noch zusätzlich etwa zwei Minuten. Damit liegt die Testausführungszeit bei etwa 3,5 Minuten.

Je mehr Tests dazukommen und je komplexer die Testabläufe werden, desto länger ist die gesamte Testausführung. Ich habe hier nur den Aufwand von einem (einfachen) der drei oben genannten möglichen Testszenarien genannt. Zum Beispiel muss beim dritten Testszenario die Wiederholungsstrategie für nicht erfolgreiche Anrufversuche zum Callcenter mit berücksichtigt werden.

Wenn sich gleichzeitig während der Weiterentwicklung die Software auf dem Steuergerät sehr oft ändert, weshalb das System regelmäßig einer kompletten Regression unterzogen werden muss, bleibt dem Tester irgendwann keine Zeit mehr neue Tests zu erstellen. Es sei denn, er verzichtet auf das Ausführen von Tests, was natürlich keine Option ist. Zusätzlich sollte die Testdurchführung immer gleich ablaufen, um die Vergleichbarkeit von Testergebnissen  zu gewährleisten.

Aus diesen Gründen müssen die Tests zwangsläufig automatisiert werden, sodass die Tests bei einer neuen Softwareversion nur gestartet werden müssen, ohne dass ein Tester zwischendurch irgendeinen Schritt manuell durchführen muss.

Umsetzung

Nachdem ich nun erklärt habe, warum das Automatisieren von Tests wichtig ist. Möchte ich nun zeigen, wie wir diese Tests für das eCall Steuergerät automatisiert haben, auf welche Probleme wir dabei gestoßen sind und wie wir diese gelöst haben.

Zum Automatisieren von Anrufen ist ein automatisierbares und konfigurierbares Telefonie-Backend notwendig. In unserem Fall schloss sich eine Konfiguration über HTTP(s) aus, da zum einen das eCall Steuergerät zwar über eine mobile Datenverbindung verfügt, diese sich aber aus Sicherheitsgründen in einem privaten Netzwerk befindet und zum anderen das eCall-Steuergerät auch einige Dienste anbietet, bei der eine Datenverbindung notwendig ist, es aber nicht möglich sein soll, eine Datenverbindung ins “richtige” Internet aufzubauen, bzw. das Gerät darüber irgendwie von außen zu erreichen. Zusätzlich werden in unserem Fall die Softwaretests direkt auf dem Steuergerät ausgeführt, sodass die Konfiguration eines Telefoniebackends vom Steuergerät aus auf jeden Fall notwendig ist.

Die Tatsache, dass das eCall Steuergerät ohne Einschränkung SMS versenden und empfangen kann, brachte uns schließlich auf die Idee, ein zweites eCall Steuergerät zu nehmen und dort eine spezielle selbst entwickelte Software zu installieren, sodass dieses über SMS konfigurierbar, als eine Art Callserver verwendet werden kann.

Steuergerät als Backend Simulator
Steuergerät als Backend Simulator

Diese spezielle Software nimmt eingehende SMS entgegen und überprüft, ob es sich um eine unserer Steuer-SMS handelt. Wenn ja, wird der Inhalt der SMS ausgewertet und der Testserver entsprechend der Konfiguration, die in der SMS steht, konfiguriert. Die Konfigurations-SMS besteht aus einer Befehlssequenz von Aktionen, die auf dem Testserver ausgeführt werden sollen.

Folgende Aktionen sind möglich:

  • Nehme Anruf an
  • Lehne Anruf ab
  • Beende Anruf
  • Warte <Zahl> Sekunden
  • Versende eine SMS mit gegebenen Inhalt an das Steuergerät

Diese Aktionen können miteinander verkettet werden. Für den oben genannten Test könnte zum Beispiel folgende Aktionssequenz verwendet werden: “Nehme Anruf an”, “Warte 30 Sekunden”, “Beende Anruf”.

Dies ermöglicht uns nun voll automatisierte Tests auf dem eCall-Steuergerät durchzuführen, sodass die Tests zwar noch händisch aufgespielt und das Steuergerät gestartet werden muss, aber die Tests selbst ohne zusätzliche Interaktion eines Testers laufen können. Wie wir später auch noch das Aufspielen der Tests automatisiert haben, ist Bestandteil eines späteren Artikels.

Zusätzlich habe wir mit dem automatisierten Backend das Problem gelöst, dass das offizielle Callcenter zu Beginn der Implementierung des eCalls noch nicht verfügbar war, sodass wir auf diese Weise den eCall vollständig ohne das eigentliche Callcenter entwickeln und testen konnten.

Fazit

Mithilfe dieser Automatisierung haben wir etwa 100 vollständig automatisierte Softwaretests für den eCall erstellt. Für die spätere Erweiterung um den ServiceCall (umfasst zum Beispiel Pannenhilfe) wurden etwa 70 weitere voll automatisierte Tests erstellt, die das zweite eCall-Steuergerät als Testserver verwenden.

Insgesamt haben wir für das Steuergerät ca. 240 von über 700 Tests erstellt, die mit dem Testserver arbeiten.

Die Durchführung von allen vollständig automatisierten Tests dauert insgesamt etwa 48 Stunden, das entspricht etwa 6 Arbeitstagen, wenn die Tests von einem Tester alleine durchgeführt würden. Es gibt aktuell ca. 560 vollständig automatisierte Tests. Das bedeutet, dass im Durchschnitt ein Test etwa 5 Minuten (inklusive Neustart des Steuergerätes nach jedem Test) dauert. Da die Tests einmal gestartet werden und dann so lange laufen, bis alle Tests durchgeführt sind, haben die Tester Zeit sich um das Erstellen von neuen Tests zu kümmern, statt die ganze Zeit schon bestehende Tests durchzuführen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *