Wie baut man eigentlich ein generisches Testsystem?
Die Aufgabenstellung lautete kurz und knapp: “Bauen Sie ein generisches Testsystem ”.
So einfach die Aufgabenstellung scheint, so vielfältig sind die Fragen, die sich daraus ergeben.
Wir wissen es!
Die Vorgeschichte
Die Aufgabenstellung lautete kurz und knapp: “Bauen Sie ein generisches Testsystem ”.
So einfach die Aufgabenstellung scheint, so vielfältig sind die Fragen, die sich daraus ergeben.
Was will der Auftraggeber mit dem generischen Testsystem erreichen? Verstehen alle dasselbe unter den Begriffen SUT (System under Test), EUT (Equipment under Test), DUT (Device under Test), MUT (Modul under Test), Prüfling? Ist ein Modul ein Hardware Teil, das ich in ein System einbauen und damit Systemtests fahren kann? Oder ist es ein Software Element für Unit Tests. Soll ich bei den Unit Tests auch die Testabdeckung bezüglich Anforderungen oder bezüglich Source Code nachweisen? Ist die Code Coverage pro Zeile genügend oder muss auch jede Verzweigung mit Tests abgedeckt sein? Soll ich nun ein Testsystem bauen, das alle möglichen Tests (Unit, Modul, System, Funktion, Type, Routine, Produktion, Integration, Debug, Entwickler) mit “Hardware in the Loop” oder sogar simulierten Elementen unterstützt?
Was sind die Umgebungsbedingungen? Prüfen wir bei Raumtemperatur in unserem Labor oder braucht es eine akkreditierte Prüfstelle? Soll das Gerät in einer Klimakammer getestet werden oder sogar zu jeder Jahreszeit im Feld? Soll ein HALT (Highly Accelerated Lifecycle Test) mit verschiedenen Temperatur Zyklen, Vibrationen oder sogar EMV Beeinflussung durchgeführt werden? Wie viele Geräte stehen für die Tests zur Verfügung und dürfen wir die Belastungsgrenze suchen? Oder handelt es sich um Stress-, Last-, Performance-Tests, die dokumentiert werden sollen, um Schwachstellen zu finden? Will der Entwickler ein Testsystem, um seine Software auf dem Target Controller effizienter zu debuggen?
Abbildung: Generische Testarchitektur
Lösungsansatz
Um in diesem Fragendschungel die richtige Antwort zu finden, ist ein strukturiertes Vorgehen wichtig. Wir haben uns darauf geeinigt, zuerst die Anforderungen an das Testsystem zu formulieren und dabei die bereits vorhandene Infrastruktur zu nutzen. Das Testsystem soll nur im Labor verwendet und schrittweise ausgebaut werden. Die Hauptanwender sind Entwickler, die ihre Entwicklungstests automatisieren wollen.
Für die Diskussionen der weiteren Anforderungen und Begriffe verwenden wir die links abgebildete Testarchitektur.
Die Tests werden als Blackbox Tests mit den Testpunkten TP1, TP2 durchgeführt. Spätere Erweiterungen sollen auch Whitebox Tests mit den Testpunkten TP3, T4 ermöglichen. Die Umgebungsbedingungen TP5 müssen zum jetzigen Zeitpunkt nicht berücksichtigt werden.
Fazit
Es gibt zahlreiche Möglichkeiten, einen Test zu definieren, aufzubauen und durchzuführen. Zuerst müssen deshalb folgende Fragen gestellt und beantwortet werden:
1. Welche Begriffe will ich als Team/Firma wie verwenden?
2. Was will ich mit dem Test erreichen?
3. Wie sieht meine Testarchitektur aus?
4. Wie stelle ich sicher, dass der Test nachvollziehbar ist? Muss er überhaupt nachvollziehbar sein und wenn ja, für wen?