Skip to main content
main-content

Über dieses Buch

Erfahren Sie in diesem Buch alles über die Bedeutung von Softwaretests zur QualitätssicherungSoftwaretests bekommen bei immer komplexer werdenden Programmen eine wachsende Bedeutung für den Projekterfolg. Obwohl Testkonzepte bereits etabliert sind, werden sie in Unternehmen häufig nur in geringem Maße genutzt, da sie zu aufwändig und teuer erscheinen. Mit diesem Buch beleuchtet Stephan Kleuker ausführlich die wichtige Rolle von Softwaretests im Rahmen der Qualitätssicherung. Neben einer intuitiven Einführung in die Testfallentwicklung ermöglicht Ihnen dieses Werk den schnellen Einstieg in das Testen von Java-Programmen mit Hilfe von einfachen Open-Source-Werkzeugen. Dabei werden neben klassischen Programmen auch unterschiedliche Vorgehensweisen und Werkzeuge für Systeme mit Datenbankintegration und Web-Applikationen betrachtet, die nicht nur für Java-Programme anwendbar sind.
Grundlagen und Spezialbereiche des Testens im FokusMit dem Buch „Qualitätssicherung durch Softwaretests“ liefert Ihnen Kleuker Impulse für systematische Softwaretests. Zunächst stehen Grundbegriffe der Qualitätssicherung und des Testens sowie die Erstellung von Testfällen mit Hilfe von Äquivalenzklassen und der Grenzwertanalyse im Fokus. In den folgenden Abschnitten bringt Ihnen dieses Buch folgende Bereiche der Qualitätssicherung mittels Softwaretests näher:
• JUnit • Testfallerstellung mit Äquivalenzklassen • Überdeckungsmaße • Testarchitektur und Mocking • Test von Nutzungsoberflächen • Applikationen mit Datenbankanbindung • Test von Web-Applikationen • Performance- und Lasttests
Mit Hilfe verschiedener Werkzeuge erarbeiten Sie sich eigenständig praktische Fähigkeiten Kleuker vermittelt Ihnen in seinem Buch weit mehr als nur theoretisches Wissen über Methoden, Verfahren sowie Systeme des Qualitätsmanagements im Softwarebereich. Sie erhalten darüber hinaus die praktischen Fertigkeiten, um mittels Softwaretests die Qualitätssicherung in Ihrem Unternehmen auf das nächste Level zu heben. Schließlich stehen alle vorgestellten Beispiele als Download bereit. Freiverfügbare Werkzeuge unterstützen Sie bei allen Arbeitsschritten. Die vorliegende zweite Auflage wurde aktualisiert und überarbeitet. Dazugekommen sind ein Kapitel zu JUnit 5 sowie zu Behaviour-Driven Development. „Qualitätssicherung durch Softwaretests“ ist dadurch eine echte Empfehlung für Informatik-Studierende, Studenten in Informatik-orientierten Master-Studiengängen, Entwickler kritischer Software-Systeme und IT-Projektmanager.

Inhaltsverzeichnis

Frontmatter

1. Einleitung

Zusammenfassung
Die Qualitätssicherung (QS) in der Software-Entwicklung wird häufig als Nebentätigkeit unterschätzt, obwohl 30 % – 70 % der Entwicklungszeit normaler Software-Produkte mit dieser Tätigkeit verbracht werden. Die Gründe hierfür sind vielfältig.
Ein wichtiger Grund ist der leider oft verbreitete Ansatz, bei Entwicklungen, die mehr Zeit als geplant in Anspruch nehmen, einfach die Zeit für die QS, die dann auch ausschließlich am Ende stattfindet, zu kürzen. Die naive Hoffnung „die Software wird schon keine Fehler haben, da sie von erfahrenen Entwicklern erstellt wird“ wird regelmäßig in allen Anwendungsbereichen der Software zerstört. Bananen-Software, die beim Kunden reift, ist ein längst angestaubter geflügelter Begriff. Der zunächst vermiedene Aufwand für die QS muss dann häufig in mehrfacher Form nachgeholt werden, da zu spät entdeckte Fehler oft zu großem Änderungsaufwand führen. Zum Glück gibt es mittlerweile viele Ansätze, die QS bereits in den Entwicklungsprozess durch agile oder iterativ-inkrementelle Vorgehensweisen zu integrieren, sodass die QS nicht mehr einfach gestrichen werden kann. Die Bedeutung der Tests vor einer Auslieferung ist spätestens dann verstanden worden, wenn man mit Bananen-Software negative Erfahrungen gemacht und vielleicht den Ruf eines Produkts beschädigt hat.
Stephan Kleuker

2. Grundbegriffe der Qualitätssicherung

Zusammenfassung
Wie in jeder ingenieurmäßigen Disziplin ist es auch in der Software-Qualitätssicherung sehr wichtig, dass alle Beteiligten die gleiche Sprache nutzen und unter den gleichen Fachbegriffen die gleichen Sachverhalte verstehen. Gerade die umgangssprachliche Formulierung von Anforderungen, die später auch Grundlage der Testfallentwicklung sind, ist häufig die Grundlage von Qualitätsproblemen. Da dieses Buch sich schwerpunktmäßig mit dem Testen beschäftigt, werden hier allerdings nur die dafür notwendigen Grundlagen genauer betrachtet. Dies umfasst typische Werkzeuge, Hintergründe der Qualitätssicherung und die Abklärung von Begriffen.
Stephan Kleuker

3. JUnit

Zusammenfassung
Das manuelle Ausführen von Tests kann leicht zu einer monotonen und dadurch selbst wieder zu einer fehleranfälligen Arbeit werden. Tests sollten einfach wiederholbar und schnell zu erstellen sein. Dies war die Motivation zur Erstellung von JUnit, einem Test-Framework für klassische Java-Programme. Genauer spricht man gerne von XUnit-Testwerkzeugen, da die Idee, Tests in der jeweiligen Programmiersprache der Programme zu schreiben, für viele Sprachen umgesetzt wird. Am Anfang stand die Umsetzung für Smalltalk [@SUn: http://​sunit.​sourceforge.​net/​]; weitere Sprachen, wie Java, aber auch C++, C# und PHP folgten.
In diesem Kapitel wird zunächst die Erstellung einfacher Testfälle beschrieben und so eine Einführung in die Konzepte von JUnit gegeben. Danach wird vorgestellt, wie man Testumgebungen, sogenannte Fixtures, programmiert. Ein weiterer wichtiger Punkt ist die Verwaltung größerer Mengen von Tests, die teilweise auch von JUnit unterstützt wird. Oftmals müssen auch Testfälle mit ähnlich strukturierten Daten erstellt werden. Hierzu gibt es in JUnit Möglichkeiten, diese Herausforderung systematisch abzuarbeiten.
Stephan Kleuker

4. Testfallerstellung mit Äquivalenzklassen

Zusammenfassung
Sollen erste Testfälle entwickelt werden, ist es auch ohne Schulung möglich, erste systematische Ideen zu generieren. Typischerweise wird überlegt, was die wichtigsten Aufgaben der Software sind, und überprüft, ob die Funktionalität gegeben ist. Mit etwas leidvoller IT-Erfahrung ist auch schnell klar, dass Randfälle zu untersuchen sind, da hier oft Probleme auftreten. Eine weitere Idee ist, viele einzelne Schritte zusammenzufassen und das Ergebnis genau zu analysieren.
In diesem Kapitel werden diese intuitiven Ideen weiter strukturiert, sodass beim Lesen die „Sehschärfe“ für potenzielle Software-Fehler geschult wird. Es wird gezeigt, wie systematisch nach verschiedenartigen Fehlern gesucht wird, wobei es gleichzeitig ein Ziel ist, möglichst wenige Testfälle für die Entdeckung potenzieller Fehler zu benötigen. So kann der Aufwand für die Testrealisierung und Testausführung verringert werden.
Stephan Kleuker

5. Überdeckungsmaße

Zusammenfassung
Nachdem in den vorherigen Kapiteln beschrieben wurde, wie man systematisch Tests mit Äquivalenzklassen und Grenzwerten erstellen und mit JUnit umsetzen kann, stellt sich unmittelbar die Frage: „Wann habe ich genug getestet ?“ Die Testerstellung benötigt einiges an Zeit und man muss wirtschaftlich diese Erstellungszeit und die Kosten möglicher Fehler gegenrechnen. Bei diesen Kosten sind nicht nur die Wartungsarbeiten, sondern auch ein möglicher Image-Schaden bei auftretenden Fehlern zu beachten. Diese Betrachtungen sind wieder projektindividuell durchzuführen, da hier z. B. für Werbe-Spiele und Software aus dem Medizin-, Luftfahrt-, aber auch Banken- und Versicherungsbereich andere Forderungen gelten.
Trotzdem steht die Frage im Raum, ob es wenigstens Indikatoren gibt, die andeuten, dass zumindest jeder Bereich der Software etwas getestet wurde. Hier liefern verschiedene Varianten von Überdeckungsmaßen eine interessante Antwort, da so z. B. festgestellt werden kann, dass jede Programmanweisung mindestens einmal ausgeführt wurde. In diesem Kapitel werden einige verschiedene Maße vorgestellt. Vorweg sei aber angemerkt, dass auch gezeigt wird, dass diesen Maßen niemals blind vertraut werden darf. Auch eine vollständige Überdeckung garantiert keine Abwesenheit gravierender Fehler, was allerdings generell für das Testen gilt. Anhand von Beispielen wird deshalb gezeigt, welche Fehler sich verstecken können, obwohl eine hohe Überdeckung erreicht wurde.
Stephan Kleuker

6. Testarchitektur und Mocking

Zusammenfassung
In allen modernen Software-Entwicklungsprozessen ist das Testen eng in die Entwicklung integriert und beginnt nicht erst nach der Fertigstellung einer ersten vollständigen Version. Dabei stellt sich die Frage, ob und wie getestet werden kann, wenn eine weitere in Entwicklung befindliche Teilsoftware, die man für eigene Tests benötigt, noch nicht vorliegt oder aus anderen Gründen nicht nutzbar ist. Die Antwort wird in diesem Kapitel mit der Erstellung einer minimalen Software, die das Testen ermöglicht, sogenannten „Mocks“, gegeben.
Die nächste Frage danach ist oft, ob man Mocks immer selbst herstellen muss oder ob es nicht zumindest Unterstützung dabei gibt. Diese wird hier in Form eines Frameworks vorgestellt. Die Antwort, ob pauschal immer ein solches Framework eingesetzt oder ob selbst solch einen Mock programmiert oder vielleicht doch gewartet wird, bis die benötigte Software vorliegt, hängt wieder von der individuellen Situation im Projekt ab und wird im Rahmen der Vorstellung des Frameworks diskutiert.
Stephan Kleuker

7. Technologien von Testwerkzeugen am Beispiel von JUnit 5

Zusammenfassung
JUnit 5 wird als Nachfolger des etablierten und konsolidierten Frameworks JUnit 4 entwickelt. Dieses Kapitel zeigt die wesentlichen Konzepte von JUnit 5 am Beispiel der bereits für JUnit 4 vorgestellten Möglichkeiten. Dabei wird genereller abgeleitet, welche typischen Anforderungen an ein Unit-Test- oder generell Test-Werkzeug gestellt werden können und wie sie umgesetzt werden.
Es ist immer hilfreich, etwas über die Technologie und Frameworks zu wissen, die ein Entwickler nutzt. Design-Entscheidungen sind so oft besser nachvollziehbar, so dass die Nutzung einfacher wird, aber auch etwaige Work-Arounds besser verstanden werden. In diesem Kapitel wird deshalb ein kleiner Einblick in die Erstellung von Annotationen, deren Nutzung über Reflection und weitere Möglichkeiten für Testwerkzeuge gegeben.
Stephan Kleuker

8. Behaviour-Driven Development

Zusammenfassung
In vielen Vorgehensmodellen schließt der Test an die Entwicklung an, was auch bei inkrementellen Vorgehensweisen in kurzen Schleifen aus Programmierung und Test der Fall ist. Ähnlich verhält es sich am Anfang der Entwicklung. Wenn Anforderungen definiert werden, wird danach über den Test, genauer die Testbarkeit, dieser Anforderungen auf Systemebene nachgedacht. In einem innovativen Schritt stellt sich die Frage, warum die Testerstellung nicht vorgezogen wird, da die Erfüllung der Tests das zentrale Maß für die Fertigstellung der Software ist. Anwendungsexperten und spätere Nutzer sind am besten in der Lage, gewünschte typische Abläufe, aber auch vielfältige Problemfälle zu beschreiben. Wird diesen Experten ermöglicht, die Erfahrungen in natürlicher Sprache zu beschreiben, stellt dies eine hervorragende Grundlage für Tests auf Systemebene dar. Dieser Ansatz, bei dem von Experten geschriebener Text in formale Tests verwandelt wird, die dann Basis der Entwicklung sind, wird mit der Vorgehensweise Behaviour-Driven Development (BDD) zusammengefasst.
Viele Ideen von BDD sind in anderen Testansätzen ebenfalls nutzbar und stellen eine wichtige Bereicherung dar. In diesem Kapitel wird zunächst die Idee der testgetriebenen Entwicklung als Motivation genutzt, um dann genauer auf die Konzepte von BDD und dessen Umsetzung einzugehen. Abschließend werden die Herausforderungen und Einsatzmöglichkeiten in der Praxis betrachtet.
Stephan Kleuker

9. Test von Nutzungsoberflächen

Zusammenfassung
Die grafische Oberfläche ist typischerweise für den ersten Eindruck einer Software verantwortlich. Neben dem sehr wichtigen, hier aber nicht behandelten Thema Usability, ist es genauso wichtig, dass der Nutzer mit seinen ersten Aktionen automatisch zum Tester der Software wird. Genauer versucht er die gewünschte Funktionalität anzusteuern, bei der er seine Erwartungen an die Ergebnisse hat. Mit gut getesteter und ergonomischer Software sollten die Erwartungen erfüllbar sein. Ansonsten enthalten fast alle Fehlerberichte von Endnutzern Beschreibungen, wie die Software bedient und welches Fehlverhalten dabei beobachtet wurde.
Aus der Sicht des Testens stellt sich die Frage, ob Oberflächen automatisch testbar sind und wann dieser Ansatz sinnvoll ist. In diesem Kapitel werden Konzepte zur Erstellung von automatisierten Oberflächentests gezeigt, die dann einmal mit einem mit der GUI-Technologie verknüpften Ansatz und dann mit einem terchnologieunabhängigen Ansatz umgesetzt werden.
Stephan Kleuker

10. Applikationen mit Datenbankanbindung

Zusammenfassung
Sind Daten langfristig zu speichern, also persistieren, sind Datenbanken meist eine gute Wahl, wenn es sich um strukturierte Informationen handelt. Datenbanken ermöglichen weiterhin, dass Informationen von verschiedenen Nutzern fast gleichzeitig gelesen und bearbeitet werden können. Durch die Transaktionssicherheit ist dabei sichergestellt, dass unerwünschte Situationen von sich gegenseitig beeinflussenden Veränderungen vermieden werden. Durch die lange Zeit, in der Datenbanken entwickelt wurden, gibt es mittlerweile viele sehr performante Lösungen für den generellen Betrieb und für Spezialaufgaben wie Datenanalysen.
Tests mit Datenbanken stehen vor den Herausforderungen Testdatenbanken mit sinnvollen Testdaten anzulegen und dass jeder Test die gleiche Ausgangssituation vorfinden muss. Dies ist zwar mit den bisherigen Mitteln erreichbar, wird auf durch ein konsequentes Vorgehen und die Nutzung von Werkzeugen wesentlich erleichtert.
Stephan Kleuker

11. Test von Web-Applikationen

Zusammenfassung
Generell können Web-Applikationen als Spezialfall der bereits vorher betrachteten Programmarten angesehen werden. Daraus folgt unmittelbar, dass die bisher vorgestellten Ideen und auch Werkzeuge zumindest für große Teile der Applikationen genutzt werden. Die Applikationen haben meist keinen einfachen Aufbau und nutzen unterschiedliche Techniken, ausgehend von der Gestaltung und Struktur der Oberflächen bis hin zu transaktionssicheren Operationen auf Datenbanken. Da die Techniken meist in nur einer Schicht genutzt werden, sind diese die zentrale Grundlage der Testplanung. Es gilt wieder, dass zunächst das darunter liegende System schichtweise und dann die Web-Oberfläche getestet wird, sofern dies möglich ist.
In diesem Kapitel wird anhand einer Web-Applikation ein weiteres Werkzeug mit seinen auf Web-Oberflächen ausgerichteten Konzepten vorgestellt, wobei das Werkzeug Selenium für fast alle Applikationen genutzt werden kann, die über einen Browser steuerbar sind.
Stephan Kleuker

12. Performance- und Lasttests

Zusammenfassung
Ein Programm, das alle gewünschten Funktionen korrekt umsetzt, hat auf dem Markt keine Chance, wenn es einfach zu langsam ist. Gerade mit schnelleren Rechnern erwarten Nutzer von Programmen unmittelbare Reaktionen, ansonsten sinkt die Akzeptanz enorm schnell. Zum Glück ist es auch eine Folge von schnellen Rechnern, dass nicht in allen Programmen bei jeder Zeile permanent über Performanz nachgedacht werden muss. Dabei wird davon ausgegangen, dass erfahrene Programmierer immer Probleme mit Laufzeiten und Speicherverbrauch im Hinterkopf haben, wie es in der Ausbildung gerne und intensiv mit dem Thema „Sortierverfahren“ in Veranstaltungen „Algorithmen & Datenstrukturen“ [SS10: Saake, G., Sattler, K.-U.: Algorithmen und Datenstrukturen: Eine Einführung mit Java, 4. Aufl. dpunkt, Heidelberg (2010)] gelehrt wird.
Zum Auffinden von prinzipiell immer möglichen Performance-Problemen und Speicherlecks ist die Überprüfung des Laufzeitverhaltens eine weitere wichtige Testaufgabe. In diesem Kapitel werden dazu Möglichkeiten aufgezeigt und darauf eingegangen, warum hier wieder die Auswahl von Testszenarien eine besondere Rolle für die Ergebnisqualität spielen kann.
Stephan Kleuker

13. Ausblick

Zusammenfassung
In den vorherigen Kapiteln wurde beschrieben, warum man was wie testen kann. Dies ist eine Grundlage, wenn man in den systematischen Test einsteigen möchte, da man zunächst wissen muss, was überhaupt möglich ist. Eine systematische Fundierung der Prozesse der Qualitätssicherung kann z. B. durch die in Kap. 1 erwähnten ISTQB-Kurse erreicht werden.
Stephan Kleuker

Backmatter

Weitere Informationen

Premium Partner

    Bildnachweise