Qualitätssicherung

Das dynamische Testverfahren wird dadurch gekennzeichnet, dass die zu prüfende Software mit einer konkreten Eingabe in einer realen Umgebung ausgeführt wird. Hierbei handelt es sich um ein Stichprobentest, was heißt, dass die Software stichprobenartig mit möglichen Eingaben ausgeführt wird, um Fehler zu finden. Werden keine Fehler gefunden, so impliziert dies nicht, dass es keine Fehler gibt. Demnach kann mit diesem Verfahren die Korrektheit des Prüflings nicht nachgewiesen werden. Das muss jedem beim Testen bewusst sein.

Automatische Tests (auch Unit-Tests genannt) sind im Prinzip kleine Programme, die ein Modul oder eine Komponente der Software testen. Sie werden von dem Tester einmalig programmiert und können danach jederzeit erneut ausgeführt werden, um beispielsweise nach einer Änderung des Prüflings zu schauen, ob sich Fehler eingeschlichen haben. Für die meisten Programmiersprachen existieren dazu Frameworks, die das Schreiben von automatischen Tests stark vereinfachen. Ein Testfall ist im einfachsten Fall wie folgt aufgebaut:

• Initialisierung des Systems, sodass der gewählte Test durchgeführt werden kann (zum Beispiel das Laden bestimmter Daten, oder die Überführung in einen bestimmten Zustand)
• Ausführung der zu testenden Methode mit den für den Testfall gewählten Parametern
• Überprüfung des Rückgabeergebnis der zu testenden Methode mit dem Soll-Ergebnis
• Logging des Testergebnis

Etwas komplizierter wird es, wenn nicht nur eine einzelne Methode getestet werden soll sondern vielmehr das Systemverhalten beim Aufruf einer ganzen Kette von Methoden. Dann reicht es nicht mehr nur die Rückgabewerte der Methoden zu überprüfen (sofern diese überhaupt existieren) sondern es muss der resultierende Systemzustand evaluiert werden. Dieser ist oft nicht ganz so einfach zu ermitteln und hier kommt der oben erwähnte Qualitäts-Begriff der Testbarkeit ins Spiel. Bereits im Entwurf der Software sollte berücksichtigt werden, dass später geschriebene Testfälle an bestimmte Informationen leicht heran kommen müssen, um das Resultat der getesteten Aktion evaluieren zu können. Oft ist es so, dass dies immer irgendwie mit entsprechendem Aufwand möglich ist. Dem Tester kann jedoch sehr viel Arbeit abgenommen werden, wenn das von vorne herein berücksichtigt wird.

Wie kommt nun zu sinnvollen Testfällen? Einerseits sollen alle Fehler gefunden werden, andererseits können nicht alle möglichen Eingaben ausprobiert werden. In der Literatur findet man häufig Begriffe wie Äquivalenzklassenbildung^[19] und Grenzwertanalyse^[20]. Dahinter verbergen sich Vorgehensweisen zur systematischen Bildung von Testfällen, die möglichst viel Abdecken sollen. Bei der Wahl der Testfälle können folgende Dinge helfen:

• Die Spezifikation der Methoden. Welchen Definitionsbereich gibt es? Welchen Wertebereich? In welchen Fällen soll ein Fehler geworfen werden? Gibt es Sonderfälle?
• Die Usecase-Diagramme aus dem Entwurf. Zuvor aufgeführte Use-Cases sind gute Kandidaten für Testfälle, da sich typische Abläufe bei der Benutzung der Software beschreiben. Dies kann dann schwierig sein, wenn dabei eine Interaktion mit der grafischen Benutzeroberfläche notwendig ist. Wie diesen Schwierigkeiten entgegengewirkt werden kann, ist weiter oben in dem Abschnitt zum Thema MVP beschrieben. Für viele Programmiersprachen gibt es auch Frameworks zum Test von GBOs.
• Die eigene Phantasie. Es gibt meist sehr viele Bedienschritte bei der Verwendung der Software, die so in der gewählten Reihenfolge erstmal keinen Sinn ergeben. Doch gerade bei ungeschulten Benutzern können diese tatsächlich auftreten. Auch hier sollte die Software nicht unkontrolliert abstürzen. Dies ist vielleicht der schwierigste Teil beim Testen.

Abschließend sei gesagt, dass der Tester eines Moduls nach Möglichkeiten nicht gleichzeitig der Author sein sollte. Für die Auswahl der Testfälle ist es besser nicht die Internen Strukturen des Modul zu kennen, sondern ausschließlich die Spezifikation.

Unittest-Frameworks gibt es für die meisten Sprachen:

• Für Java und Eclipse: JUnit^[21]
• Eine umfangreiche Liste von Unittest-Frameworks für viele Sprachen findet sich auf Wikipedia^[22]

Beim Erstellen von Testfällen kann es hilfreich sein zu wissen, welche Teile des Quellcodes tatsächlich abgedeckt sind und welche nicht. Struktur-Tests in Form von Quellcode-Überdeckungs-Tests können diese Frage beantworten. Dabei wird der Quellcode zunächst instrumentiert und die Testfälle dann ausgeführt. Bei der Ausführung kann das Test-Framework feststellen, welche Teile des Quellcodes ausgeführt wurden und welche nicht. Daraus können verschiedene Metriken berechnet werden, die jeweils ein unterschiedliches Maß der Überdeckung beschreiben. Eine Befehls-Überdeckung von 100% würde beispielsweise bedeuten, dass jede Zeile Quellcode von mindestens einem Testfall ausgeführt wurde. Des Weiteren gibt es noch Zweig-Überdeckung, Schleifen-Überdeckung und schließlich auch die Pfad-Überdeckung, sowie noch einige mehr. Die zuletzt genannte ist in der Praxis jedoch irrelevant, denn eine vollständige Pfad-Überdeckung würde bedeuten, dass wirklich jeder mögliche Ausführungspfad der Software von Testfällen abgedeckt wäre.

Die Erreichung bestimmter Überdeckungsmaße kann als Anforderung für Testfälle herangezogen werden. Dabei sollte jedoch stets klar sein, was die Maße im Einzelnen aussagen. Schnell suggeriert die Erreichung einer bestimmten Überdeckungsrate eine gewisse Testvollständigkeit und läutet somit das vorzeitige Ende der Bemühungen ein. Tatsächlich sagen die Maße nichts über den Sinn und Zweck der Testfälle aus. Um diesen Trugschluss von vorne herein zu vermeiden, ist es eine gute Idee den Quellcode-Überdeckungs-Test erst dann durchzuführen, wenn man der Meinung ist, dass nun alles ausreichend getestet sei. Auf diese Weise profitiert man von diesem, indem er dem Tester noch die eine oder andere Stelle Quellcode aufweist, die von den Testfällen noch nicht erreicht wurde.

Die meisten Frameworks für Quellcode-Überdeckungs-Tests bieten eine Integration für diverse Entwicklungsumgebungen an. Für Java sind zur Zeit folgende Frameworks mit unterschiedlich ausgeprägter Feature-Auswahl verfügbar:

• CodeCover (Eclipse-Plugin) ^[23]
• Emma^[24]
• EclEmma (Eclipse-Plugin basierend auf Emma)^[25]
• Cobertura ^[26]

Es ist gute Praxis, mit einer leicht destruktiven Mentalität an das Testen heranzugehen. Ein Testlauf ist dann "erfolgreich", wenn tatsächlich Fehler dabei gefunden wurden, d.h. wenn Testfälle fehlschlagen. Fehler sind in größern Projekten mit Sicherheit vorhanden, sowohl kritische als auch weniger kritische. Wenn also die gerade geschriebenen automatischen Testfälle ohne Zwischenfall zu Ende laufen, wurden "leider" keine weiteren Fehler gefunden. Es ist wichtig, diese Mentalität bei allen Team-Mitgliedern zu forcieren. Niemand im Team sollte sich über gefundene Fehler in einem fertig geglaubten Modul ärgern, im Gegenteil: Der Fehler war schon immer da, wurde aber gerade erst aufgedeckt - herzlichen Glückwunsch! Ein Grund zur Freude, denn seine Beseitigung führt zur Steigerung der Softwarequalität.

Beim Testen von Softwaresystemen mit Datenbanken kann das Testen recht umständlich werden, wenn man bedenkt dass vor jedem Test ein bestimmter Zustand in der Datenbank angenommen werden muss und nach dem Test der Ursprungszustand wieder hergestellt sein soll. Da in vielen Test-Frameworks die Ausführungsreihenfolge der Testfälle nichtdeterministisch ist, muss die Datenbank in jedem Fall immer wieder zurückgesetzt werden. Anstatt die Datenbank nun nach jedem Testfall immer wieder manuell zurückzusetzen (z.B. mit einer Kette von Löschoperationen) empfiehlt es sich, die von den meisten Datenbanksystem zur Verfügung gestellten Transaktions-Mechanismen zu verwenden. Ein Datenbank-Test könnte dann wie folgt aufgebaut sein:

• Datenbankverbindung herstellen
• Für den Testfall notwendige Einträge durchführen (zuvor Auto-Commit auf False setzen!)
• zu testende Aktionen durchführen
• System- bzw. Datenbankzustand entsprechend überprüfen
• Rollback durchführen

Manipulationen, die nicht mit einem Datenbank-Commit abgeschlossen sind, können in der aktuellen Session sehr wohl mit einem Select gelesen werden. Diese Tatsache kann man sich beim Testen zu Nutze machen.