#Softwaretests Teil 1 – Komponententests – Von Bits und Bytes

So – nach langer, arbeitsbedingter Blog-Pause melde ich mich zurück! Jetzt ist aber endlich meine Promotion beendet und ich habe (hoffentlich) wieder Zeit für einigermaßen regelmäßige Beiträge.

Anfangen möchte ich direkt mit dem Thema, mit dem ich mich die letzten Jahre über beschäftigt habe: dem Testen von Software. Konkret möchte ich im Rahmen einer kleinen Artikelserie zum Thema meiner Dissertation hinleiten und es im letzten Teil auch kurz vorstellen. Also – los geht es!

Jeder, der mit Computern arbeitet, kennt es vermutlich: Man benutzt eine Software (für die eventuell sogar viel Geld bezahlt wurde) und – zack! – stürzt sie ab oder zeigt ein anderes unerwünschtes Verhalten – kurz: einen Fehler. Warum sich Fehler in Programme einschleichen, ist nicht verwunderlich: da sie auch nur von Menschen programmiert werden, ist es nur natürlich, dass hin und wieder auch Fehler gemacht werden. Interessanter – und auch oft gestellt, nicht selten mit empörtem Unterton – ist dagegen die Frage, warum es diese Fehler ins fertige Produkt schaffen und sich scheinbar vorher niemand die Mühe gemacht hat, sie zu suchen und zu beseitigen.

Der Vorwurf ist natürlich einfach erhoben; es darf jedoch nicht vergessen werden, dass es in vielen Programmen oft unzählige Anwendungsfälle gibt, die oft auch vom Nutzerverhalten über einen längeren Zeitraum abhängen. Diese alle im Voraus zu erahnen und zu überprüfen, ist – vorsichtig ausgedrückt – nicht unbedingt einfach. Was uns auch direkt zur eigentlichen Frage des Beitrags führt: Wie kann Software überhaupt getestet werden?

Die einfachste Möglichkeit ist natürlich, dass sich jemand hinsetzt und die Software ausprobiert (vorzugsweise übrigens nicht der Programmierer selber, da er nur testet, ob die implementierten Sachen funktionieren – und nicht, was alles nicht klappt!). Wie gerade erwähnt, ist das bei hinreichend komplexer Software (und das heißt, alles, was über das einfachste hinausgeht) eine überaus undankbare, wenig zielführend und kaum zu bewältigende Aufgabe. Erschwert wird dies noch dadurch, dass an einem Programm natürlich auch immer noch weiter programmiert wird. Jede Änderung am Programmcode erfordert im Grunde ein neues Testprogramm. Auf diese Art könnte kaum sichergestellt werden, dass eine Software keine Fehler enthält (nichtsdestotrotz hat das manuelle Testen natürlich seine Daseinsberechtigung; insbesondere Software wie Computerspiele mit vielen Nutzereingaben über einen langen Zeitraum werden ausgiebig manuell getestet).

Wenn manuelles Testen keine Lösung ist, muss ein automatisierter Prozess her. Und in der Tat gibt es verschiedene Möglichkeiten, Software automatisiert zu testen. Eine der grundlegendsten Methoden ist die der Komponententests.

Software ist in der Regel aus mehreren Einzelteilen oder Komponenten zusammengesetzt. Was genau eine Komponente darstellt, ist etwas unscharf definiert; es kann sich hierbei um eine einzelne Methode eines Programms, eine Klasse (Randnotiz: Was eine Klasse ist, muss noch in einer eigenen Artikelserie behandelt werden!), ein ganzes Modul oder auch um einen funktionell zusammengehörigen Verbund von kleineren Komponenten handeln. Für den weiteren Verlauf des Artikels soll gelten, dass mit einer Komponente eine einzelne Methode gemeint ist.

Komponententests testen also (zum Beispiel!) Methoden automatisiert. Doch wie genau läuft das ab? Stellen wir uns einmal vor, wir haben eine einfache Funktion normalize, die einen Vektor normiert, ihn also auf eine Länge von genau 1 bei Beibehaltung der Richtung transformiert; dies wird erreicht, indem jede Koordinate des Vektors durch seine Länge geteilt wird (sqrt ist die Funktion zur Berechnung der Quadratwurzel):

(1)  normalize: v ∈ R³ → R³:
(2)    l ∈ R, l ← sqrt( v₀² + v₁² + v₂² )
(3)    return [v₀/l, v₁/l, v₂/l]

Auf den ersten Blick ganz einfach. Diese Funktion kann getestet werden, indem für sie ein Testfall geschrieben wird. Einfach gesagt ist ein Testfall wiederum eine Funktion, welche die zu testende Komponente mit einer bestimmten Eingabe aufruft und prüft, ob das gelieferte Ergebnis den Erwartungen entspricht. Ein Testfall für die Funktion normalize könnte zum Beispiel so aussehen: