Komponententest

R 2.0.0

Was ist ein Komponententest?

Was ist ein Komponententest?

Eine Teststufe mit dem Schwerpunkt auf einer einzelnen Hardware- oder Softwarekomponente.

Diese Teststufe wird mit anderen Begriffen gleichgesetzt:

  • Modultest

  • Klassentest

  • Unittest

  • Entwicklertest

Anwendungsbeispiel

Anwendungsbeispiel
ALT MISSING

Eddy ist Komponentenverantwortlicher und verantwortet die Pflege und Weiterentwicklung einer komplexen Softwareanwendung, in der Datenbestände mit denen von Sicherheitsbehörden abgeglichen werden. Natürlich muss die Software vor Inbetriebnahme ausführlich getestet werden, damit die Daten schnell und verlässlich abgerufen werden können. Um Zeit zu sparen wurden neue Softwareanwendungen in Eddys Team und dem Fachbereich bisher immer erst am Ende auf Funktionalität getestet. Typischerweise wurde kurz vor Inbetriebnahme ein Systemtest geplant und durchgeführt.

Die Korrektur von Fehlern, die dann gefunden wurden, war immer sehr aufwendig und kostenintensiv. Und leider, so überlegt sich Eddy, wurde die Zeit ganz oft zum Inbetriebnahmetermin hin immer knapper, da die Fachabteilungen immer noch dringende Ergänzungs- oder Änderungswünsche hatten. So blieben von Testphasen, die über mehrere Wochen geplant waren, oftmals nur wenige Tage übrig.

ALT MISSING

Dieses Mal möchte Eddy anders vorgehen und hat sich vor dem eigentlichen Projektstart ausführlich über verschiedene Teststufen informiert. „Es muss doch möglich sein, fertiggestellte Teile der Anwendung zu einem viel früheren Zeitpunkt zu testen", überlegt er. In der Schulung zum Testmanager hat er gelernt, dass die vier Stufen: Komponententest - Integrationstest - Systemtest - Abnahmetest aufeinander aufbauen und Schwächen bei den frühen Teststufen nicht durch verstärkte Bemühungen im System- oder Abnahmetest „geheilt" werden können.

Eddy vertraut auf die Theorie und nimmt sich fest vor den Komponententest während der Entwicklungsphase einzusetzen. Er liest noch einmal in seinen Schulungsunterlagen nach. "Der Komponententest wird üblicherweise von dem Entwickler durchgeführt, der den Code geschrieben hat". Das vereinfacht den Prozess, da vorerst keine Termine mit Kolleginnen und Kollegen organisiert werden müssen. Aber gut, dass er noch einmal nachgelesen hat. Er hatte irrtümlich unter Komponententest etwas anders verstanden, und zwar den Test seiner Komponente aus der Softwareanwendung. Dabei ist beim Komponententest die kleinste zu testende Einheit {Modul, Klasse, Unit} einer Anwendung gemeint.

ALT MISSING

Der beauftragte Entwicklungsdienstleister liefert neben den Sourcen auch regelmäßig generierte Testberichte und Komponententests aus, aber Eddy hat sich diese noch nie so richtig angesehen, sondern darauf vertraut, dass das schon irgendwie richtig gemacht wird. Warum eigentlich? Ein Blick auf die Testberichte zeigt, dass die Testabdeckung wirklich höher sein könnte. Und er staunt, wie viele Hinweise es auf 'Code Smells' gibt und findet darunter auch einige kritische. „Aber jetzt sollten wir uns das mal genauer ansehen", findet er. Zusammen mit Theo, dem Testmanager, macht er ein Quellcodereview der ausgelieferten Tests.

ALT MISSING

Was sie dort sehen kann noch verbessert werden, finden sie. Das werden sie zeitnah mit dem Hersteller besprechen. In Zukunft möchte Eddy die Komponenten in regelmäßigen Abständen testen. Dafür hat er mit Theo einen Testplan entworfen. Zum Glück konnte Theo ihm eine Vorlage für die Erstellung eines solchen Plans zur Verfügung stellen. Das war eine große Erleichterung. Außerdem legen sie fest wie hoch die Software durch Komponententests abgedeckt werden soll. Damit keine Informationen verloren gehen, möchte Eddy die durchgeführten Tests und die gefundenen Fehler in einem Tool dokumentieren.

Nach Rücksprache mit Theo steht fest, dass Eddy für die Dokumentation Jira nutzen möchte. Eine ausführliche Anleitung wie mit Jira gearbeitet wird, hat er im Intranet gefunden. "Das läuft ja super", denkt sich Eddy. Die ersten Komponenten sind fertig programmiert und durch das Befolgen des Testplans hat er regelmäßige Kontrollpunkte. Gefundene Fehler werden direkt dem Hersteller zwecks Behebung gemeldet.

ALT MISSING

"Immer die gleichen Testschritte", denkt sich Eddy, "ich sollte mir ein Werkzeug suchen, um meinen Testplan zu automatisieren. So bin ich nicht nur schneller, sondern finde vielleicht auch noch mehr Fehler?! Ich könnte häufiger testen und vor allem würden Regressionsfehler, die sich durch Änderungen am Programmcode ergeben, direkt gefunden.

Theo rät Eddy sich mit Unit Test auseinander zu setzen. "Unit Tests ermöglichen eine automatisierte, wiederholbare und kontinuierliche Prüfung des Testobjekts." Das bringt Eddys Testkonzept auf ein neues Level.

Beschreibung

Softwareanwendungen können sehr umfangreich sein, daher ist es eine Herausforderung solche Systeme vollumfänglich zu testen. Bevor ein gesamtes System getestet wird, ist es wichtig, dass jede Komponente bzw. die kleinste Einheit der Anwendung gründlich getestet wird.

Die Hauptziele des Komponententests bestehen darin, das Eingabe- und Ausgabeverhalten eines Testobjekts zu überprüfen. Es soll sichergestellt werden, dass die Funktionalität des Testobjekts gemäß der gewünschten Spezifikation ordnungsgemäß und vollständig gegeben ist.

Fehlerzustände werden meist behoben, sobald sie gefunden werden, oftmals ohne formales Fehlermanagement.

Das übergeordnete Ziel ist es mithilfe der Unit Tests alle wichtigen Bestandteile der Implementierung mit hoher Testabdeckung zu testen. Je nach Geschäftsanforderungen und Kritikalität des Software-Produktes variieren die Anforderungen an die minimale sinnvolle Testabdeckung der Unit Tests. Komponententests helfen bei der Regression, stellen Dokumentation bereit und unterstützen Sie beim Entwerfen guten Codes.

Der Komponententest wird üblicherweise von dem Entwickler durchgeführt, der den Code geschrieben hat.

ALT MISSING
Abb. 1: Testpyramide Komponententest

Manuell durchgeführte Komponenten- bzw. Regressionstests haben einen niedrigeren Testabdeckungsgrad also automatisierte Tests.

Für normale, nicht-kritische Software-Produkte ist eine Testabdeckung von mindestens 60% anzustreben. Im Umfeld kritischer Systeme wie z.B. Medizintechnik werden üblicherweise deutliche höhere Unit Test Testabdeckungswerte verlangt.

Unit Tests werden überwiegend als White-Box Tests implementiert, die sowohl die positiven als auch negativen Interaktionspfade und Zustände in den jeweiligen Code-Einheiten abdecken.

Ein Unit Test ist automatisiert, d.h. er wird von einer Software (Unit Testing Framework/Unit Testing Tool) und nicht von einem Menschen manuell durchgeführt. Der Vorteil der Unit Test ist, dass man schnell und damit häufiger testen kann als bei manuellen Tests und somit Fehler (insbesondere Regressionsfehler, die sich durch Änderungen am Programmcode ergeben haben) zeitnah feststellen kann. Unit Test erlauben die automatisierte, wiederholbare, kontinuierliche Prüfung (werkzeuggestützt!).

Video: Komponententest (Länge: 20:28)

Vorteile der Unit Tests

Der große Vorteil der Unit Tests besteht darin, dass man sie in einer sehr frühen Software-Entwicklungsphase unmittelbar während der Entwicklung schreiben und zur sofortigen Überprüfung der gerade programmierten Code-Stücke einsetzen kann.

Damit können Unit Tests auch unfertige und nicht-lauffähige Softwarekomponenten testen. Die einzige Voraussetzung bei den meisten Programmiersprachen ist, dass das zu testende Software-Modul kompilierfähig ist.

Aufgrund der geringen (oder im Optimalfall sogar gar keinen) Abhängigkeiten von anderen Modulen und Daten laufen die Unit Tests nicht nur blitzschnell, sondern in der Regel sehr stabil. Das liegt daran, dass es wegen der hohen Isolation kaum externe Ereignisse gibt, die das Verhalten bzw. die Stabilität beeinflussen können (wie z.B. Änderung der Datenbasis in der Datenbank, Nicht-Verfügbarkeit eines Web-Services u.v.m.)

Durch ein gemeinsames Test-Framework werden Debugging-Prozesse und Fehlersuche erleichtert.

Jede Teststufe hat individuelle Testziele, Testbasis, Testobjekte, Testvorgehensweisen, Verantwortlichkeiten sowie typische Fehlerzustände & -wirkungen.

Wie funktioniert Unit-Test-Traceability?

Rückverfolgbarkeit (Traceability)

In einem agilen Softwareentwicklungsprojekt werden zu Beginn Epics definiert, welche für ein Feature oder einen Teil eines Features repräsentativ sind. Im nächsten Schritt werden User Storys definiert und auf Basis dieser Tasks abgeleitet. Die Entwicklung implementiert diese Tasks und daraus resultiert der eigentliche Programm-Code und natürlich Unit Tests, welche den Code auf Herz und Nieren prüfen.

Auf der rechten Seite wird erkennbar, wie die Beziehung vom Programm-Code bis hin zu den funktionalen Anforderungen zurückverfolgt werden kann. Voraussetzung dafür ist die Verwendung eindeutiger Identifikationsnummern, welche die Artefakte durchgängig durch den Softwarelebenszyklus begleiten.

Genau durch diese Eigenschaft ist es möglich, von unserem Blatt (Programm-Code und Unit Tests) auf einen Task, eine User-Story und in weiterer Folge auf ein Epic zu schließen. Somit sind alle Informationen, welche wir für eine Rückverfolgbarkeit (Traceability) brauchen, gegeben und können verwertet werden.

Falls Sie noch nicht auf den agilen Zug aufgesprungen sind, machen Sie sich keine Sorgen, dasselbe Modell ist auch auf ein nicht-agiles Softwareentwicklungsmodell anwendbar.

ALT MISSING
Abb. 2: Rückverfolgbarkeit eines Unit-Tests

Mock-Objekt

Ein Mock-Objekt ist ein Platzhalter in der Softwareentwicklung für noch nicht realisierte Objekte, die frühzeitige Komponenten- / Integrationstests ermöglicht. Mocks simulieren das Verhalten der realen Objekte.

Beispielsweise lassen sich Mock-Objekte nutzen, wenn:

  • das gewünschte Objekt noch nicht zur Verfügung steht.

  • das reale Objekt nicht durch einen Test beschädigt werden soll – bspw. Daten dauerhaft löscht.

  • ein Verhalten nachgestellt werden soll, das nur schwierig auszulösen ist.

  • die reale Lösung zu komplex und langsam für einen Test ist – z. B. eine vollständige Datenbank, die vor jedem Test initialisiert werden müsste.

Reifegradbestimmung & Entscheidungshilfen

Quellen