Zur Rolle des Moduls im Studium

 

Das Modul "Software-Testen" ist ein Pflichtmodul im Studiengang "Web- und Medieninformatik". Es wird dort dem Studienbereich "Softwaretechnik" zugerechnet. Formal darf das Modul jederzeit belegt werden, aber als fachliche Grundlage werden viele andere Module empfohlen: 

• Grundlagen der Informatik 1
• Grundlagen der Informatik 2
• Grundlagen der Informatik 3
• Softwaretechnik 1
• Softwaremanagement 1

 

Diese Empfehlung finde ich im Großen und Ganzen plausibel, auch wenn ich selbst das Modul "Softwaremanagement" nocht nicht belegt hatte. Aufgrund der vielfältigen Voraussetzungen wundert es nicht, dass die Belegung erst für das 5. Fachsemester empfohlen wird. Es ist also eines der letzten Pflichtmodule.

 

Für den Studiengang "Wirtschaftsinformatik" ist das Modul nicht vorgesehen, nicht einmal im Wahlpflichtbereich. Es ist aber ein Baustein des Hochschulzertifikates "Software-Manager".

 

Das Lehrbuch

 

Das Buch "Basiswissen Testen von Software" von Torsten Cleff hat knapp 300 Seiten. Der Umfang ist für ein Modul bei Springer Campus also unterdurchschnittlich. Ziel des Lehrbuches ist, Grundwissen zu Testtechniken aber auch zu Prüftechniken zu vermitteln, so dass Fehler möglichst früh entdeckt und behoben werden. Die Erfahrung zeigt, dass die Kosten für die Behebung von Fehlern umso niedriger ausfallen, je früher ein Fehler entdeckt wird. Gemeint sind hier nicht nur Fehler im Quellcode, an die ich zu Beginn des Moduls als erstes gedacht habe. Fehler können auf allen Ebenen der Software-Entwicklung passieren, z.B. auch beim Erfassen von Anforderungen, bei der objektorientierten Analyse oder beim Entwurf, also bevor auch nur die erste Zeile Code geschrieben ist.

 

Grundlagen

 

Im ersten Teil des Buches werden vor allem Begriffe geklärt. Interessant war für mich z.B. die Unterscheidung von Teststufen, die jeweils mit Entwicklungsstufen eines Softwaresystems korrespondieren. Zu den vertraglichen Anforderungen an ein Software-Produkt gehört ein Abnahmetest, zur Produktdefinition ein Systemtest, zum Produktentwurf ein Integrationstest und zum Komponentenentwurf ein Komponententest.

 

Nun ist klar, dass der Komponententest der erste Test ist, den man machen kann, wenn Quellcode vorliegt. Erst kann man die Integration von Komponenten testen und so fort. Die Teststufen folgen also in entgegensetzter Reihenfolge wie die Entwicklungsstufen. Visualisiert man diesen Ablauf, steigt man vom Anforderungsdokument Stufe um Stufe hinab bis zur Implementierung und arbeitet sich dann mit den Tests Stufe im Stufe wieder hinauf bis zu den Anforderungen. Der visualisierte Ablauf hat die Form des Buchstabens V, weshalb man auch vom V-Modell spricht.

 

Interessant sind auch die verschiedenen Integrationsstrategien. Bei der Bottom-up Integration, baut und testet man zunächst Komponenten, die keine Dienste untergeordneter Komponenten in Anspruch nehmen. Dann baut und testet man die Komponenten, die auf diesen aufsetzen. So arbeitet man sich Stufe für Stufe nach oben. Ein Vorteil dieser Strategie ist, dass man keine Platzhalter programmieren muss. Der Nachteil ist, dass man das Zusammenspiel der Komponenten im Großen erst spät testen kann. Darum gibt es auch eine Top-down Integrationsstrategie. Hier werden möglichst bald Komponenten höherer Ordnung getestet. Da diese untergeordnete Komponenten brauchen, die noch nicht vorliegen, muss man viele Platzhalter programmieren. Dafür bekommt man früh einen Eindruck des Gesamtsystems aus Benutzersicht.

 

Interessant waren auch die verschiedenen nicht-funktionalen Testverfahren. So werden z.B. bei einem Stresstest die definierten Leistungsgrenzen eines Systems bewusst überschritten, etwa um zu testen, ob das System nach einer Überlastung wieder in den Normalzustand zurückkehren kann.

 

Testfälle entwickeln

 

Diesen Kursabschnitt betrachte ich als den inhaltlichen Kern des Moduls. Der größte Anteil der Einsendeaufgaben aber auch der Aufgaben in der Online- und Präsenzklausur bezieht sich hierauf.

 

Black-Box-Tests

 

Zunächst geht es um spezifikationsorientierte Testtechniken. Komponenten sollen zu bestimmten Kombinationen von Eingabewerten eine Ausgabe entsprechend der Spezifikation liefern. Diese Tests werden auch als Black-Box-Tests bezeichnet, weil hier nicht interessiert, wie eine Komponente intern arbeitet. Es geht allein darum, ob sie zu gegebenen Eingaben die erwarteten Ausgaben liefert.

 

Die erste derartige Testtechnik ist die funktionale Äquivalenzklassenbildung. Hier fasst man gleichwertige Eingabewerte zu einer Klasse zusammen, aus der man einen Repräsentanten auswählt. Getestet wird nur mit dem Repräsentanten, was den Testaufwand beträchtlich reduziert. Da die Erfahrung zeigt, dass Fehler vor allem an Klassen- und Intervallgrenzen auftreten, gibt es die Grenzwertanalyse. Hier wählt man als Repräsentanten Werte an den Grenzen eines Intervalls. Bei beiden Testtechniken ist wichtig, dass man gültige und ungültige Repräsentanten testet. Ungültige Repräsentanten sollten dann z.B. dazu führen, dass eine Exception geworfen wird.

 

Der Entscheidungstabellentest eignet sich, wenn eine natürlich-sprachliche Testbasis vorliegt. Er ermöglicht, die verschiedenen Kombinationen von Eingangsbedingungen übersichtlich darzustellen. Oft ist es dann möglich, Fälle zusammen zu fassen und die Tabelle auf diese Weise stark zu vereinfachen. Auch dies kann den Testaufwand erheblich reduzieren.

 

Bei der Ursache-Wirkungsanalyse visualisiert man die Beziehungen zwischen Ursachen und Wirkungen als Graph, dessen Kanten logische Verknüpfungen sind. Solche Graphen lassen sich in Entscheidungstabellen überführen.

 

Beim zustandsbezogenen Test modelliert man ein System als Zustandsautomaten. So kann man die Historie des Systems in den Test einbeziehen. Das Zustandsdiagramm lässt sich in eine Zustandstabelle und in eine Zustandsmatrix überführen. Daraus lassen sich wiederum Testfälle ableiten. Interessant ist diese Testart z.B. für Systeme aus der Automatisierungstechnik.

 

Auf höheren Teststufen gibt es den anwendungsfallbasierten Test. Ein konkreter Anwendungsfall wird als Use-Case-Diagramm modelliert. Auch hieraus lassen sich Testfälle ableiten.

 

White-Box-Tests

 

Während bei den spezifikationsorientierten Testtechniken nicht relevant ist, wie eine Komponente ihre Leistung erbringt (Black-Box-Test), muss man für die kontrollfluss-orientierten Testtechniken den Quellcode eines Programmes kennen. Darum werden diese auch als White-Box-Tests bezeichnet. Bei diesen Testtechniken visualisiert man den Kontrollfluss durch den Quelltext als Graph.

 

Beim Anweisungsüberdeckungstest möchte man durch geschickte Auswahl möglichst weniger Testfälle sicherstellen, dass alle Anweisungen des Quellcodes ausgeführt werden. Beim Zweigüberdeckungstest sollen die Testfälle nicht nur alle Anweisungen (Knoten) des Graphen abdecken. Auch alle Zweige (Kanten) sollen mindestens ein Mal durchlaufen werden. Dieser Test ist also umfassender als der Anweisungsüberdeckungstest. Noch weiter geht der Bedingungsüberdeckungstest. Er beschäftigt sich mit der Kombination von Bedingungen, die erfüllt sein müssen, damit ein Zweig durchlaufen werden kann. Diese lassen sich z.B. wie eine Digitalschaltung visualisieren. Beim Pfadüberdeckungstest müssen nicht nur alle Kanten durchlaufen werden, sondern jeder mögliche Pfad vom Startpunkt bis zum Endpunkt eines Programmes. Die Zahl möglicher Pfade wächst oft sehr schnell. Entsprechend wächst auch die Zahl nötiger Testfälle.

 

Erfahrungsbasiertes Testen

 

Freies Testen ist ein erfahrungsbasiertes Verfahren. Die Testfälle basieren auf Testhypothesen eines erfahrenden Testers. Da hier die Intuition eine große Rolle spielt, sind solche Verfahren schlecht formalisierbar und nicht leicht in den Entwicklungsprozess zu integrieren. Sie werden daher meist nur ergänzend eingesetzt.

 

Fehlerhypothesen lassen sich methodischer ableiten, wenn man auf der Grundlage bisher entdeckter Fehler Fehlerklassen bildet. Das sind Gruppierungen typischer Schwachstellen, die in vergangenen Tests an ähnlichen Systemen aufgefallen sind. Ein Beispiel für so eine Fehlerklasse wären etwa Fehler bei Klassen oder Datentypen. Konkrete Ausprägungen dieser Fehlerklasse wären dann z.B. Fehler bei Mehrfachvererbung, Typtransformationen oder fehlerhafte Deklarationen von Attributen oder Methoden. 

 

Exploratives Testen ergänzt das erfahrungsbasierte Testen um ein Element der Analyse und Reflexion. Die dadurch gewonnenen Einsichten werden für die Entwicklung der nächsten Fehlerhypothesen genutzt. Auch dies ist ein Versuch, erfahrungsbasiertes Testen methodischer zu machen.

 

Testen vs. prüfen

 

Ein weiterer thematischer Schwerpunkt des Moduls sind Prüftechniken. Während bei Tests vorausgesetzt ist, dass man ein Testobjekt ausführen kann, wird bei einer Prüfung ein Artefakt der Softwareentwicklung nicht ausgeführt sondern inhaltlich nach formalen Kriterien kontrolliert. Dies hat verschiedene Vorteile:

• Nicht nur Quellcode kann geprüft werden, sondern auch Spezifikationen, Modelle, Dokumentationen oder andere Artefakte des Entwicklungsprozesses.
• Man benötigt keine Testumgebung, Testdaten oder Testtreiber
• Testen kann man erst, wenn Code vorliegt. Prüfen kann man dagegen in jeder Phase.

 

Entscheidend ist, dass man durch Prüfverfahren Fehler viel früher entdecken kann als durch Tests. Dadurch lassen sich Kosten vermeiden. Allerdings lassen sich durch Prüfungen nicht alle Arten von Fehlern entdecken. Zum Beispiel lassen sich Leistungskennzahlen auf diesem Weg nicht ermitteln, denn dazu müsste Code ausgeführt werden. Im Kurs behandelte manuelle Prüftechniken sind die Inspektion, das technische Review, der Walkthrough und das informelle Review.

 

Softwaremaße

 

Es gibt aber auch automatisierte Prüftechniken. So lassen sich z.B. mit geeigneten Werkzeugen sogenannte Softwaremaße bestimmen. Ein gängiges Maß ist sind zum Beispiel die Lines of Code (LOC), mit denen der Umfang eines Quellcodes angegeben wird. Dieses Maß ist nicht so selbstverständlich, wie es auf den ersten Blick scheint. LOCs können stark schwanken, je nachdem welche Formatierungskonventionen angewendet wurden. Dennoch werden LOCs häufig für grobe Umfangsschätzungen verwendet.

 

Ein genaueres Umfangsmaß ist das Halstead-Maß. Dazu muss man zunächst alle Operanden und Operatoren eines Quellcodes auszählen. Die Anzahl unterschiedlicher Operatoren bezeichnet man mit N1, die der unterschiedlichen Operanden als N2. Operatoren sind z.B. Schlüsselwörter einer Programiersprache, Klammern aber auch Modifier, die die Sichtbarkeit einer Variable festlegen. Operanden sind z.B. Variablen oder auch boolesche Werte wie true oder false. Halstead bezeichnet nun die Summe N1+N2 als Vokabular eines Programmes. Als Volumen bezeichnet er die Summe N1+N2+log(N1+N2). Man kann sich vorstellen, dass das manuelle Auszählen von Operatoren und Operanden für Menschen eine mühselige Arbeit ist. So etwas kann automatisch von Werkzeugen erledigt werden, weshalb man in diesem Zusammenhang von automatisierten Prüftechniken spricht.

 

Das McCabe Maß wird auch als zyklomatische Komplexität beschrieben. Um das McCabe-Maß berechnen zu können, muss man die Knoten und Kanten eines Kontrollflussgraphen auszählen und die Anzahl verbundener Kontrollflussgraphen bestimmen. McCabe liefert die maximale Zahl linear unabhängiger Programmpfade. Damit kann man abschätzen, wieviele Testfälle man für einen Zweigüberdeckungstest braucht.

 

Es gibt auch Maße für Bindung und Kopplung von Komponenten.

 

Problemmuster

 

Problemmuster sind Anomalien im Quelltext, die erfahrungsgemäß die technische Qualität eines Programms senken. Sie lassen sich durch geeignete Werkzeuge aufspüren, damit sie überarbeitet werden können. Ein bekanntes Beispiel ist die Codedopplung. Wenn an verschiedenen Stellen des Programmes identischer Quellcode steht, muss man bei Änderungen alle entsprechenden Stellen finden. So etwas wird von einem Wartungsprogrammierer leicht übersehen. Meist ist es dann besser, solchen Code in einer eigene Komponente oder Methode zusammenzufassen. Das vermeidet Probleme bei künftiger Wartung. Im Kurs werden viele weitere Problemmuster vorgestellt, etwa mangelnder Polymorphismus, die Verletzung des Geheimnisprinzips, die Verwendung einfacher Typen, die zu Datenklumpen führt oder auch problematisch zusammengesetzte Datentypen.

 

In den letzten Kapiteln geht es um das Management von Softwaretests sowie die Automatisierung von Tests. In diesem Zusammenhang werden auch ein paar Testwerkzeuge knapp vorgestellt.

 

Online-Tests und Einsende-Aufgaben

 

Die Tests decken die Inhalte des Moduls gut ab. Die Einsendeaufgaben konzentrieren sich vor allem auf die Kapitel zur Entwicklung von Testfällen. Aber auch das Entdecken von Problemmustern in Quellcode und die Bestimmung von Softwaremaßen spielt eine Rolle. Man vereinfacht Entscheidungstabellen, zeichnet Kontrollflussgraphen zum Quelltext, verbessert Anomalien in Quellcode, visualisiert komplexe Bedingungen als Digitalschaltung, zeichnet Zustandsautomaten, findet Testklassen, Repräsentanten und Testfälle. Die Aufgaben sind also recht vielfältig. Bei einigen Aufgabentypen hätte ein wenig mehr Übungsmaterial nicht geschadet. Die Aufgaben sind aber didaktisch geschickt gewählt, so dass sie zum Verständnis der vermittelten Konzepte beitragen. Insbesondere geben die Aufgaben einen guten Vorgeschmack auf das, was einen in der Online- und in der Präsenzklausur erwartet.

 

Die Rückmeldungen meines Tutors kamen auch in diesem Modul sehr zügig. Sein Stil war manchmal etwas knapp, so dass ich gelegentlich noch einmal nachfragen musste. Das hat sich aber dann auch gelohnt und kleinere Unsicherheiten behoben. Ich hatte übrigens den gleichen Tutor wie im Modul "Grundlagen der Informatik 2" zu Beginn meines Studiums. Bei ihm habe ich objektorientiertes Programmieren gelernt. Ich habe mich sehr gefreut, gegen Ende meines Studiums noch einmal von ihm betreut zu werden.

 

Präsenzklausur

 

Die Aufgabentypen der Klausur ähnelten den Einsendeaufgaben, so dass man eigentlich gut vorbereitet sein sollte, wenn man alle Aufgaben bearbeitet und die Rückmeldungen seines Tutors genutzt hat. Wissensfragen zu den Prüftechniken spielten auch eine gewisse Rolle. Ich empfand das Arbeitspensum als angemessen für die Dauer der Klausur.

 

Bei den Aufgaben zur Äquivalenzklassenbildung und Grenzwertanalyse wollte man den Studierenden anscheinend etwas Zeit ersparen, indem man Tabellen zur Verfügung gestellt hat, in die man z.B. Testfälle eintragen konnte. Das Layout dieser Tabellen war für mich allerdings ungewohnt und überraschend. Ich selber hätte meine Tabellen anders aufgebaut, so dass ich gelegentlich Lösungen in falsche Felder eingetragen habe, was ich dann wieder korrigieren musste. Das hat Zeit und Nerven gekostet. Nach der Klausur sprach ich mit einem Kommilitonen, dem es ähnlich ergangen war wie mir. Der hatte die zur Verfügung gestellten Tabellen gar nicht erst genutzt sondern sich lieber selbst welche gezeichnet. Diese Freiheit hätte ich mir auch nehmen sollen. Die dafür nötige Zeit hätte ich bestimmt mit Zinsen zurück bekommen. Wegen dieser Schwierigkeiten rechnete ich damit, ein paar Flüchtigkeitsfehler gemacht zu haben.

 

Diese Sorge war anscheinend unbegründet. Das Klausurergebnis war erfreulich und spiegelte auch meinen subjektiven Eindruck wieder, den Stoff des Moduls im wesentlichen verstanden zu haben.

 

Fazit

 

Grundsätzlich finde ich es sehr sinnvoll, dass das Curriculum ein eigenes Modul zum Thema Testen enthält. Gut gefallen haben mir vor allem die Kapitel zur Entwicklung von Testfällen, weil ich hier die Einsendeaufgaben didaktisch klug gewählt und auch interessant und abwechslungsreich fand. Auch das Thema Problemmuster war für mich spannend. Es hat Spaß gemacht, in fremdem Quellcode nach problematischen Stellen zu suchen und sich bessere Lösungen zu überlegen. Weniger interessant waren für mich die Kapitel zu Prüftechniken und zum Management von Testfällen. Diese empfand ich als theoretischer und trockener, was sich bei diesem Stoff wohl auch nicht vermeiden lässt. Wegen dieser für mich etwas zäheren Abschnitte zählt Softwaretesten zwar nicht zu meinen Favoriten im Studienbereich Softwaretechnik, aber ich ziehe hier ein positives Fazit.