Neben der Funktionalität von Anwendungen ist es wichtig, dass Software stabil und zuverlässig läuft. Im Laufe der Zeit steigt nicht nur die Funktionalität von Programmen, sondern auch die Anzahl möglicher Fehlerquellen mit hinzukommenden Codezeilen an. Möglichst viele Fehler zu finden und zu korrigieren, ist ein wichtiger Aspekt von qualitativ hochwertiger Software. Das Testen und das Finden von Fehlern kann nur in begrenzten Maßen händisch getestet werden, beispielsweise werden dabei grundlegende Funktionalitäten vorausgesetzt.
Modultests¶
Software-Anwendungen sind dabei in der Regel in einzelne Module, also abgeschlossene Einheiten, unterteilt. Um die Funktionalität von Anwendungen zu testen, werden daher Modultests geschrieben, welche dann in regelmäßigen Abständen automatisiert ausgeführt werden. Die Modultests werden besonders im englischsprachigen Raum auch häufig Unit Tests genannt. Modultests können dabei für verschiedene Schnittstellen geschrieben werden. Die Art der Implementierung hängt hingegen von der Software ab. In der Regel gibt es eine Gruppe an Modultests, die die direkte Funktion von Methoden auswertet. Ein einzelner Test prüft dabei beispielsweise, ob die Methode genau das zurückliefert, was erwartet wird. Dieses Verhalten wird dann mit einigen beispielhaften Daten getestet.
Als Beispiel für einen Modultest kann man sich folgendes Einsatzszenario vorstellen: Das Objekt des Feedgenerators für den Planeten wird mit Daten gefüllt, zum Beispiel mit Artikeln aus einem Blog. Beim Aufruf einer Methode werden die Daten in den RSS-Feed (als XML-Datei) geschrieben. Hierbei müssen mehrere Problemfälle überprüft werden: Zum einen, ob alle eingegebenen Daten auch den Erwartungen entsprechend in die XML-Datei geschrieben worden sind. Des Weiteren sollte überprüft werden, ob die entsprechende XML-Datei auch valide und wohlgeformt ist – also den Regeln entsprechen. Die Überprüfungen übernimmt dabei ein Test-Framework.
Die Besonderheit von Modultests ist, dass diese automatisiert ausgeführt und ausgewertet werden. Dies hängt auch mit dem Konzept der kontinuierlichen Integration zusammen. Bei der kontinuierlichen Integration handelt es sich um das stetige Hinzufügen von neuem Entwicklungsquellcode zu einem Projekt. Entwickler nutzen dabei ein Versionsverwaltungssystem für den Quellcode. Darunter fallen beispielsweise Git, Subversion oder auch das in LaunchPad genutzte bazaar.
Jenkins¶
 |
| Jenkins-Logo |
Die Software Jenkins hilft dabei die testgesteuerte Entwicklung von Software durchzuführen. In Jenkins können Jobs definiert werden, die als sich wiederholende Arbeitsabläufe zu verstehen sind. In der Regel umfasst dies mehrere Schritte, die automatisiert ausgeführt werden. Innerhalb der Konfiguration eines Jenkins-Jobs ist es möglich verschiedene Arbeitsabläufe zu definieren die unter Linux in der Regel Shell-Skripte enthalten. Jenkins kann man daher auch als Aufsatz für derartige Skripte verstehen. Der Vorteil von Jenkins ist, dass sich die Jobs leicht und intuitiv erstellen lassen und die Entwickler zudem viele Konfigurationsmöglichkeiten nutzen können.
Generell werden Jenkins-Jobs in zwei verschiedenen Varianten ausgeführt, die erste ist das Konzept der täglichen Builds, die dann ausgeführt werden, wenn Änderungen am Quellcode vorgenommen worden sind. Das zweite Konzept ist die bereits erwähnte kontinuierlichen Integration von Quellcode. Hierbei wird ein Jenkins-Job immer dann gestartet, wenn Änderungen im Projektarchiv durchgeführt wurden. Bei den täglichen Builds hingegen, werden die Änderungen von einem Tag stets zusammengefasst.
Wenn nun ein Jenkins-Job startet, wird zunächst der Quellcode aus dem Projektarchiv geladen und neu kompiliert. Sofern dies fehlerfrei ausgeführt wurde, ist der nächste Schritt der Test der einzelnen Module. Die Modultests schreiben die Ergebnisse der durchgeführten Tests in Log-Dateien. Die Art der Log-Dateien unterscheidet sich dabei vom eingesetzten Test-Framework. Häufig werden hierzu XML-Dateien genutzt, die der Jenkins-Job zum Schluss auswertet. Bei der Auswertung werden dann die Log-Dateien nach einem festgelegten Schema eingelesen und interpretiert. Dabei wird die Anzahl der fehlgeschlagenen Modultests gezählt und als Ergebnis des Jenkins-Jobs ausgegeben.
 |
| Status und Wetterbericht zu verschiedenen Jenkins-Jobs |
Anschließend erzeugt Jenkins mit dem Testergebnissen den Status des aktuellen Builds in Form von Farben und einen sogenannten „Wetterbericht“. Der Status ist „Rot“, sobald zu viele Fehler aufgetreten sind, „Gelb”, wenn eine geringe Fehlernanzahl aufgetreten ist und die Farbe „Blau“, sofern keiner der Modultests fehlgeschlagen ist. Häufig werden alternativ auch die „Ampel-Farben“ genutzt, so dass ein erfolgreicher Build mit Grün statt Blau gekennzeichnet ist. Was unter einer „geringen Anzahl der Fehler“ verstanden werden soll, lässt sich einstellen. Wenn ein Jenkins-Jobs mehrmals durchgelaufen ist - der Quellcode also mehrfach Veränderungen erfahren hat, wird daraus der „Wetterbericht“ erstellt. Der Wetterbericht zeigt an, wie der Verlauf der letzten fünf Jenkins-Jobs war. Strahlenden Sonnenschein gibt es, sofern alle Builds erfolgreich durchgeführt werden konnten, wohingegen es Gewitter gibt, wenn alle letztmaligen Builds fehlgeschlagen sind. Zudem existieren noch weitere Status wie zum Beispiel „Wolken“, sofern nur wenige der letzten Vorgänge fehlgeschlagen sind. Die einzelnen Werte aus denen der Status eines Jenkins-Jobs erzeugt werden, lassen sich hierbei ebenfalls selbst konfigurieren, so dass Entwickler-Teams die volle Kontrolle über ihre Jenkins-Jobs besitzen. Es gibt natürlich auch noch alternative CI Software, die man statt Jenkins nutzen kann; beispielsweise Bamboo oder das kommerzielle Travis.
Der nächste Teil der Reihe über „Qualitätssicherung in Software“ behandelt die Arbeitsweise des Ubuntu-Qualitätssicherungsteams.
