1 - Inhaltsverzeichnis [Seite 7]
2 - 1 Einleitung [Seite 11]
3 - 2 Test gegen die Anforderungen [Seite 19]
4 - 3 Statische Verfahren [Seite 23]
4.1 - 3.1 Codereview [Seite 25]
4.2 - 3.2 Compiler [Seite 26]
4.3 - 3.3 Analysewerkzeuge [Seite 29]
4.4 - 3.4 Analysebeispiele [Seite 31]
4.4.1 - 3.4.1 Clang als Analysewerkzeug [Seite 31]
4.4.2 - 3.4.2 Scan-Build [Seite 33]
5 - 4 Testentwurf und Testdurchführung [Seite 35]
5.1 - 4.1 Das Google-Test-Framework [Seite 35]
5.1.1 - 4.1.1 Installation [Seite 36]
5.1.2 - 4.1.2 Anwendung [Seite 38]
5.2 - 4.2 Happy-Path-Test [Seite 41]
5.3 - 4.3 Äquivalenzklassentest [Seite 44]
5.3.1 - 4.3.1 Ein Beispiel mit einem Parameter [Seite 45]
5.3.2 - 4.3.2 Das Beispiel in C++ [Seite 48]
5.3.3 - 4.3.3 Erweiterung auf andere Datentypen [Seite 49]
5.3.4 - 4.3.4 Mehrere Parameter [Seite 52]
5.4 - 4.4 Grenzwertanalyse [Seite 65]
5.4.1 - 4.4.1 Ein Beispiel [Seite 68]
5.4.2 - 4.4.2 Mehrere Parameter [Seite 69]
5.4.3 - 4.4.3 Ergänzung: Grenzen im Programmtext [Seite 70]
5.5 - 4.5 Klassifikationsbaummethode [Seite 71]
5.5.1 - 4.5.1 Ein Beispiel [Seite 72]
5.5.2 - 4.5.2 Das Beispiel in C++ [Seite 77]
5.6 - 4.6 Kombinatorisches Testen [Seite 85]
5.6.1 - 4.6.1 Orthogonale Arrays [Seite 87]
5.6.2 - 4.6.2 Covering Arrays [Seite 87]
5.6.3 - 4.6.3 n-weises Testen [Seite 88]
5.6.4 - 4.6.4 Werkzeugnutzung [Seite 93]
5.6.5 - 4.6.5 Das Beispiel in C++ [Seite 95]
5.6.6 - 4.6.6 Ein Beispiel ohne Orakel [Seite 98]
5.7 - 4.7 Entscheidungstabellentest [Seite 102]
5.7.1 - 4.7.1 Ein Beispiel [Seite 103]
5.7.2 - 4.7.2 Ein Beispiel in C++ [Seite 107]
5.8 - 4.8 Zustandsbasierter Test [Seite 113]
5.8.1 - 4.8.1 Ein Beispiel [Seite 116]
5.8.2 - 4.8.2 Der minimale Zustandstest [Seite 119]
5.8.3 - 4.8.3 Das Beispiel in C++ [Seite 123]
5.8.4 - 4.8.4 Test von Übergangsfolgen [Seite 124]
5.9 - 4.9 Syntaxtest [Seite 134]
5.9.1 - 4.9.1 Das Beispiel in C++ - Variante 1 [Seite 137]
5.9.2 - 4.9.2 Das Beispiel in C++ - Variante 2 [Seite 139]
5.10 - 4.10 Zufallstest [Seite 143]
6 - 5 Strukturbasierte Testverfahren [Seite 151]
6.1 - 5.1 Kontrollflussbasierter Test [Seite 153]
6.1.1 - 5.1.1 Werkzeugunterstützung [Seite 154]
6.1.2 - 5.1.2 Anweisungstest [Seite 155]
6.1.3 - 5.1.3 Entscheidungstest [Seite 159]
6.1.4 - 5.1.4 Pfadtest [Seite 163]
6.1.5 - 5.1.5 Schleifentest [Seite 164]
6.2 - 5.2 Test komplexer Entscheidungen [Seite 168]
6.2.1 - 5.2.1 Einfacher Bedingungstest [Seite 169]
6.2.2 - 5.2.2 Mehrfachbedingungs- oder Bedingungskombinationstest [Seite 171]
6.2.3 - 5.2.3 Modifizierter Bedingungs-/Entscheidungstest [Seite 172]
6.3 - 5.3 Bewertung [Seite 185]
6.4 - 5.4 Bezug zu anderen Testverfahren [Seite 187]
6.5 - 5.5 Hinweise für die Praxis [Seite 188]
7 - 6 Erfahrungsbasiertes Testen [Seite 189]
7.1 - 6.1 Exploratives Testen [Seite 196]
7.2 - 6.2 Freies Testen [Seite 201]
8 - 7 Softwareteststandard ISO 29119 [Seite 207]
8.1 - 7.1 Testverfahren nach ISO 29119 [Seite 208]
8.1.1 - 7.1.1 Spezifikationsbasierte Testverfahren [Seite 208]
8.1.2 - 7.1.2 Strukturbasierte Testverfahren [Seite 211]
8.1.3 - 7.1.3 Erfahrungsbasierte Testverfahren [Seite 213]
9 - 8 Ein Leitfaden zum Einsatz der Testverfahren [Seite 215]
10 - 9 Zu berücksichtigende C++-Eigenschaften [Seite 221]
10.1 - 9.1 Automatische Typumwandlung [Seite 221]
10.2 - 9.2 Undefinierte Bitbreite [Seite 221]
10.3 - 9.3 Alignment [Seite 222]
10.4 - 9.4 32- oder 64-Bit-System? [Seite 222]
10.5 - 9.5 static-Missverständnis [Seite 223]
10.6 - 9.6 Memory Leaks [Seite 224]
11 - Glossar [Seite 229]
12 - Literaturverzeichnis [Seite 243]
13 - Stichwortverzeichnis [Seite 245]
14 - www.dpunkt.de [Seite 0]
3 Statische Verfahren
Der Begriff Software umfasst vieles. So gehören sowohl die Design- als auch die Programmdokumentation dazu und natürlich auch der Programmcode. Nur dieser wird im Folgenden betrachtet. Statische Verfahren analysieren den Programmcode, ohne ihn auszuführen - daher der Name. Zu den statischen Verfahren gehören sowohl Reviews zur Bewertung des Programmcodes und zur Aufdeckung von Fehlern als auch die automatisierte Analyse mit Werkzeugen. Es gibt verschiedene Arten von Reviews, auf die unten kurz eingegangen wird. Allen Reviews ist gemeinsam, dass sie Arbeitszeit kosten, nicht nur die des Autors, sondern auch die von Kollegen, die als Gutachter tätig werden. Uns geht es darum, die Arbeitszeit aller Beteiligten zu reduzieren, um mit demselben Aufwand bessere Qualität zu erzielen. Deshalb liegt der Schwerpunkt dieses Kapitels nicht auf Reviews, die nur der Vollständigkeit halber erwähnt werden, sondern auf Verfahren zur statischen Analyse, die automatisiert ablaufen und daher wenig Arbeitszeit kosten. Reviews werden dadurch nicht überflüssig, aber weniger aufwendig, weil ein Teil der Fehler oder Schwächen schon vorher durch die statische Analyse aufgedeckt und anschließend korrigiert werden kann. Je früher ein Fehler gefunden wird, desto leichter (und billiger) ist seine Korrektur.
Bevor es mit dem Testen unserer Software - also der Ausführung des Testobjekts mit Testdaten auf dem Rechner - losgeht, ist es sinnvoll, vorher so viele Fehler wie möglich zu entdecken, um den Aufwand für das Testen gering (»lean«) zu halten. Daher werden hier die statischen Analyseverfahren ausführlich vorgestellt.
Statische Verfahren werden typischerweise von Entwicklern eingesetzt. Diese Verfahren können natürlich nicht alle Fehler finden, insbesondere nicht diejenigen, die von externen Daten herrühren, die erst zur Laufzeit vom Programm eingelesen werden. Dafür gibt es die dynamischen Verfahren1, insbesondere die Unit Tests auf der Ebene des Entwicklers. Umgekehrt können Unit Tests verschiedene statische Eigenschaften nicht prüfen, wie etwa die Einhaltung von Programmierrichtlinien. Statische Verfahren sind besonders geeignet zur Prüfung der folgenden Elemente:
-
Syntax (Grammatik) des Programms. Bei einer nicht der Spezifikation der Programmiersprache entsprechenden Syntax gibt schon der Compiler eine Fehlermeldung aus. Voraussetzung ist natürlich, dass der Compiler die Sprachspezifikation richtig implementiert.
-
Einhaltung anerkannter Prinzipien zur Softwareentwicklung bzw. Programmierung. So kann ein Verfahren das (im Allgemeinen unerwünschte) Vorhandensein globaler Variablen entdecken oder unbeabsichtigte fehlerhafte Typumwandlungen.
-
Einhaltung der Programmierrichtlinien (sofern es welche gibt). Diese schreiben zum Beispiel vor, wie Namen von Klassen und Objekten zu bilden sind, wie Kommentare gestaltet werden sollen und ob Exceptions verwendet werden dürfen.
-
Kontrollfluss. So können nicht erreichbarer Code oder fehlerhafte Ablaufstrukturen entdeckt werden.
-
Datenfluss. Dabei wird zum Beispiel geprüft, ob eine Variable vor der Verwendung mit einem Wert initialisiert wurde oder ob ein zugewiesener Wert überhaupt verwendet wird. Wenn nicht, muss das kein Fehler sein, deutet aber daraufhin, dass der Programmcode nicht der eigentlichen Absicht entspricht.
Konkrete Beispiele finden Sie weiter unten.
Statische Verfahren können nicht nur auf den Quellcode angewendet werden, sondern auch auf Bytecode (wie etwa das Werkzeug FindBugs2 für die Programmiersprache Java) oder auf binäre ausführbare Programme. Wir beschränken uns hier auf den Quellcode.
Beschränkungen in der Praxis
Ein Werkzeug ist ein Werkzeug, nicht mehr und nicht weniger. Insbesondere kann es nicht die Gedanken des Programmierers lesen und daraufhin die korrekte Umsetzung in Programmcode überprüfen. Das bedeutet, dass die Entwickler eines Werkzeugs bestimmte Vorstellungen haben, wie Anweisungen und Programmstrukturen aussehen sollen, und diese Annahmen im Werkzeug implementieren. Diese Annahmen können sich an manchen Stellen als falsch erweisen. Aus diesem Grund kann es sein, dass ein Werkzeug
-
einen »Fehler« meldet, der tatsächlich keiner ist (falsch positive Meldung), oder
-
einen vorhandenen Fehler nicht meldet (falsch negative Meldung).
Ein besonders gründliches Werkzeug erzeugt möglicherweise eine Menge falsch positiver Meldungen, sodass die Gefahr besteht, das wichtige Meldungen in der schieren Menge untergehen. Die Entwickler solcher Werkzeuge bemühen sich, die Anzahl der falsch positiven Ergebnisse zu reduzieren.
Praktischer Einsatz
Um die Menge an Fehlermeldungen und Warnungen zu reduzieren und die Anzahl der Tests zu beschränken, empfiehlt sich die nachstehende Reihenfolge:
-
Das Testobjekt (Programmcode) compilieren und ggf. korrigieren, bis die Compilation fehlerlos durchläuft. Dabei die höchste Warnstufe einschalten und die Warnungen des Compilers berücksichtigen.
-
Statische Verfahren einsetzen und alle gefundenen Fehler korrigieren. Die Anzahl der jetzt noch notwendigen Tests wird durch jeden in dieser Phase gefundenen Fehler reduziert.
-
Erst dann die Unit Tests durchführen.
3.1 Codereview
Review ist der Oberbegriff für verschiedene statische Prüfverfahren, die von Personen durchgeführt werden. Das Prüfobjekt kann eine Designdokumentation sein, ein zu erstellendes Produkt oder ein Teil davon oder auch der Ablauf eines Prozesses. Ein Autor ist oft »betriebsblind« und sieht bestimmte Dinge nicht mehr, deshalb ist es wichtig, dass er den Code einem Kollegen zeigt. Ein großer Vorteil eines Reviews: Andere Personen sehen das Prüfobjekt unter einem ganz anderen Blickwinkel. In diesem Abschnitt geht es aber nur um Codereviews, die hauptsächlich in zwei Arten vorkommen:
Walkthrough
Das Vorgehen ist für kleine Teams von bis zu fünf Personen geeignet und verursacht relativ wenig Aufwand. Dabei stellt der Programmautor den Code einigen Experten vor, zum Beispiel fachlich versierten Kollegen - möglichst aus anderen Projekten - oder Testern. Mit ihnen zusammen werden verschiedene Benutzungsabläufe durchgespielt. Ziel ist das gegenseitige Lernen und Verständnis über das Prüfobjekt und natürlich, Fehler zu finden.
Inspektion
Eine Inspektion folgt einem formalisierten Ablauf, in dem es verschiedene Rollen gibt, wie etwa einen Moderator und verschiedenen Gutachter (ebenfalls fachlich versierte Kollegen). Einer der Gutachter trägt den Inhalt des Prüfobjekts vor, wobei die anderen entsprechend Fragen stellen. Die Gutachter bereiten sich auf die Sitzung vor, was beim Walkthrough entfallen kann. Während der Inspektion werden auch Daten gesammelt, die zur Qualitätsbeurteilung des Entwicklungs- und Inspektionsprozesses herangezogen werden. Ziel der Inspektion ist das Finden von Fehlern und ggf. deren Ursachen.
Codereviews tragen sehr zur Qualität einer Software bei. Deswegen werden sie hier als statisches Verfahren erwähnt, auch wenn sie nicht weiter behandelt werden.
Ausführliche Beschreibungen zu den unterschiedlichen Arten der Reviews sind in [Spillner & Linz 12, Kap. 4] und in [Rösler et al. 13] zu finden.
3.2 Compiler
Ein Compiler muss zwangsläufig ein Programm analysieren, wenn er lauffähigen Code daraus herstellen soll. Typischerweise baut er einen abstrakten Syntaxbaum auf, abgekürzt AST (abstract syntax tree) genannt. Im Prinzip hat ein Compiler alle im Programmcode liegenden Informationen zur Verfügung, sodass er einige Fehler leicht entdecken kann, wie etwa die fehlende Deklaration einer Variablen oder den Aufruf einer Funktion mit einem falschen Parametertyp.
Was ein Compiler aber nicht oder nur zum Teil kennt, sind Empfehlungen für einen defensiven Programmierstil oder die gewünschten Programmierrichtlinien.
Es gibt eine Menge verschiedener Compiler, sowohl Open Source als auch kommerziell. Die hier und im Folgenden beschriebene Problematik ist bei allen Compilern strukturell ähnlich, weswegen wir uns auf die Open-Source-Compiler GNU C++ (G++) und Clang (Aufruf clang++) beschränken.
G++
G++ gibt es für Mac OS und Linux [URL: gcc]. Die Distribution für Mac OS hinkt bezüglich der Versionsnummern gegenüber Linux etwas hinterher. Unsere Empfehlung: Auf dem Mac lieber Clang verwenden (siehe unten). In beiden Fällen wird die mehrere Gigabytes umfassende Entwicklungsumgebung Xcode benötigt.
G++ gibt es auch für Windows, wobei die MinGW- und die Cygwin-Distribution am weitesten verbreitet sind. Aber auch hier hinken die Versionsnummern denen für Linux hinterher.
Clang
Clang [URL: clang] ist ein Frontend für die C-Sprachfamilie (C/C++, Objective C/C++), das für LLVM3, eine modulare Compilerarchitektur, entwickelt wurde. Clang/LLVM ist Open Source. LLVM ist aus einem Projekt der Compilerforschung entstanden. Clang/LLVM ist besser als G++ für die statische Analyse eines...
