Qualitätssicherung durch Softwaretests

Inhaltsverzeichnis

1. Frontmatter

2. 1. Einleitung

   Stephan Kleuker

   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.

3. 2. Grundbegriffe der Qualitätssicherung

   Stephan Kleuker

   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.

4. 3. JUnit

   Stephan Kleuker

   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]; 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.

5. 4. Testfallerstellung mit Äquivalenzklassen

   Stephan Kleuker

   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 meist, möglichst viele Schritte gleichzeitig auszuführen, auf das Ergebnis zu warten und die Reaktionszeit zu messen.

   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.

6. 5. Überdeckungsmaße

   Stephan Kleuker

   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.

7. 6. Testarchitektur und Mocking

   Stephan Kleuker

   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.

8. 7. JUnit Jupiter

   Stephan Kleuker

   Zusammenfassung

   JUnit 5 und 6 wurden als Nachfolger des etablierten und konsolidierten Frameworks JUnit 4 entwickelt. Dieses Kapitel zeigt zunächst exemplarisch einen Ausschnitt aus der JUnit-Historie mit typischen Beispielen aus JUnit 3 und JUnit 4, die so auch in JUnit 5 laufen. Danach wird JUnit 5 als Framework betrachtet und auf die Erweiterungsmöglichkeiten innerhalb von JUnit Jupiter fokussiert. Dieses Ideen sind direkt auf JUnit 6 übertragbar. Die Möglichkeiten werden durch die Erstellung einer vollständigen, funktionalen Erweiterung abgeschlossen. Durchgehend in diesem Kapitel wird dabei generell abgeleitet, welche typischen Anforderungen an ein Unit-Test- oder generell Test-Werkzeug gestellt werden können und wie sie umgesetzt werden.

9. 8. Behaviour-Driven Development

   Stephan Kleuker

   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.

10. 9. Test von Nutzungsoberflächen

    Stephan Kleuker

    Zusammenfassung

    Die graphische 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 technologieunabhängigen Ansatz umgesetzt werden.

11. 10. Applikationen mit Datenbankanbindung

    Stephan Kleuker

    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.

12. 11. Test von Web-Applikationen

    Stephan Kleuker

    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 von Web-Applikationen 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. Der zweite große Teil des Kapitels beschäftigst sich konkret mit dem Test von REST-basierten Applikationen, bei den einige bereits bekannte Testansätze wieder Anwendung finden.

13. 12. Performance- und Lasttests

    Stephan Kleuker

    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] 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.

14. 13. Testen von und mit künstlicher Intelligenz

    Stephan Kleuker

    Zusammenfassung

    Der Einfluss künstlicher Intelligenz (KI) auf die Gesellschaft und auch die Software Entwicklung wird kontrovers diskutiert. KI wird immer häufiger in Software Systeme eingebaut und auch in der Software Entwicklung genutzt. Daraus folgt aus Sicht der Software-Qualität die Frage wie die Korrektheit von Software mit eingebauter KI geprüft werden kann und die zweite Frage, wie mit KI entwickelte Software überprüft wird.

15. 14. Ausblick

    Stephan Kleuker

    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.

16. Backmatter