Lean Testing für C++-Programmierer (eBook)

Angemessen statt aufwendig testen

Andreas Spillner, Ulrich Breymann (Autoren)

eBook Download: PDF

2016 | 1. Auflage
248 Seiten
dpunkt (Verlag)
978-3-86491-967-1 (ISBN)

Infos

Sie programmieren - auch in C++. Sie führen regelmäßig Unit Tests durch. Sie sind sich manchmal unsicher, ob Sie ausreichend oder zu viel getestet haben. Werfen Sie einen Blick in dieses Buch, Sie werden viele Anregungen für Ihre tägliche Arbeit finden! 'Lean Testing' steht für einen Ansatz, der auf der einen Seite alle wichtigen Testfälle zur Prüfung der Software berücksichtigt, auf der anderen Seite aber den Testaufwand in einem überschaubaren Rahmen hält. Der angemessene Mittelweg zwischen zu wenig und zu viel Testen wird bei jedem Vorgehen zum Entwerfen der Testfälle diskutiert und erörtert. Die in diesem Buch präsentierten Vorgehensweisen zum Testfallentwurf werden konkret mit den entsprechenden C++-Programmtexten und den jeweiligen Testfällen dargelegt. Sind hierzu unterstützende Werkzeuge erforderlich, beschreiben die Autoren deren Anwendung. Dabei geben sie nützliche Hinweise für die Verwendung der Testverfahren und bieten einen Leitfaden für ihren Einsatz. Alle Testverfahren des aktuellen ISO-Standards 29119, die für den Unit Test relevant sind, werden vorgestellt und ausführlich behandelt. Ulrich Breymann ist ein bekannter Fachautor für die Programmiersprache C++ - Andreas Spillner für den Testbereich. Beide Autoren bringen ihre Fachkompetenz ein und schlagen eine Brücke zwischen Programmierung und Test. Das Buch unterstützt die aktuelle Entwicklung, bei der Softwareerstellung keine strikte (personenbezogene) Trennung zwischen Implementierung und Test auf Unit-Ebene vorzusehen (z.B. TDD & Test-first-Ansatz).

Andreas Spillner ist Professor für Informatik an der Hochschule Bremen. Er war über 10 Jahre Sprecher der Fachgruppe TAV 'Test, Analyse und Verifikation von Software' der Gesellschaft für Informatik e.V. (GI) und bis Ende 2009 Mitglied im German Testing Board e.V. Im Jahr 2007 ist er zum Fellow der GI ernannt worden. Seine Arbeitsschwerpunkte liegen im Bereich Softwaretechnik, Qualitätssicherung und Testen. Ulrich Breymann war als Systemanalytiker und Projektleiter in der Industrie und der Raumfahrttechnik tätig. Danach lehrte er als Professor Informatik an der Hochschule Bremen. Er arbeitete an dem ersten C++-Standard mit und ist ein renommierter Autor zu den Themen Programmierung in C++, C++ Standard Template Library (STL) und Java ME (Micro Edition).

Inhalt

Inhaltsverzeichnis 7
1 Einleitung 11
2 Test gegen die Anforderungen 19
3 Statische Verfahren 23
3.1 Codereview 25
3.2 Compiler 26
3.3 Analysewerkzeuge 29
3.4 Analysebeispiele 31
3.4.1 Clang als Analysewerkzeug 31
3.4.2 Scan-Build 33
4 Testentwurf und Testdurchführung 35
4.1 Das Google-Test-Framework 35
4.1.1 Installation 36
4.1.2 Anwendung 38
4.2 Happy-Path-Test 41
4.3 Äquivalenzklassentest 44
4.3.1 Ein Beispiel mit einem Parameter 45
4.3.2 Das Beispiel in C++ 48
4.3.3 Erweiterung auf andere Datentypen 49
4.3.4 Mehrere Parameter 52
4.4 Grenzwertanalyse 65
4.4.1 Ein Beispiel 68
4.4.2 Mehrere Parameter 69
4.4.3 Ergänzung: Grenzen im Programmtext 70
4.5 Klassifikationsbaummethode 71
4.5.1 Ein Beispiel 72
4.5.2 Das Beispiel in C++ 77
4.6 Kombinatorisches Testen 85
4.6.1 Orthogonale Arrays 87
4.6.2 Covering Arrays 87
4.6.3 n-weises Testen 88
4.6.4 Werkzeugnutzung 93
4.6.5 Das Beispiel in C++ 95
4.6.6 Ein Beispiel ohne Orakel 98
4.7 Entscheidungstabellentest 102
4.7.1 Ein Beispiel 103
4.7.2 Ein Beispiel in C++ 107
4.8 Zustandsbasierter Test 113
4.8.1 Ein Beispiel 116
4.8.2 Der minimale Zustandstest 119
4.8.3 Das Beispiel in C++ 123
4.8.4 Test von Übergangsfolgen 124
4.9 Syntaxtest 134
4.9.1 Das Beispiel in C++ – Variante 1 137
4.9.2 Das Beispiel in C++ – Variante 2 139
4.10 Zufallstest 143
5 Strukturbasierte Testverfahren 151
5.1 Kontrollflussbasierter Test 153
5.1.1 Werkzeugunterstützung 154
5.1.2 Anweisungstest 155
5.1.3 Entscheidungstest 159
5.1.4 Pfadtest 163
5.1.5 Schleifentest 164
5.2 Test komplexer Entscheidungen 168
5.2.1 Einfacher Bedingungstest 169
5.2.2 Mehrfachbedingungs- oder Bedingungskombinationstest 171
5.2.3 Modifizierter Bedingungs-/Entscheidungstest 172
5.3 Bewertung 185
5.4 Bezug zu anderen Testverfahren 187
5.5 Hinweise für die Praxis 188
6 Erfahrungsbasiertes Testen 189
6.1 Exploratives Testen 196
6.2 Freies Testen 201
7 Softwareteststandard ISO 29119 207
7.1 Testverfahren nach ISO 29119 208
7.1.1 Spezifikationsbasierte Testverfahren 208
7.1.2 Strukturbasierte Testverfahren 211
7.1.3 Erfahrungsbasierte Testverfahren 213
8 Ein Leitfaden zum Einsatz der Testverfahren 215
9 Zu berücksichtigende C++-Eigenschaften 221
9.1 Automatische Typumwandlung 221
9.2 Undefinierte Bitbreite 221
9.3 Alignment 222
9.4 32- oder 64-Bit-System? 222
9.5 static-Missverständnis 223
9.6 Memory Leaks 224
Glossar 229
Literaturverzeichnis 243
Stichwortverzeichnis 245
www.dpunkt.de 0

Textauszug

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:

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

2. Statische Verfahren einsetzen und alle gefundenen Fehler korrigieren. Die Anzahl der jetzt noch notwendigen Tests wird durch jeden in dieser Phase gefundenen Fehler reduziert.

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

Produkt-Details

• Erscheint lt. Verlag: 1.6.2016
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Informatik ► Software Entwicklung ► Qualität / Testen
• Schlagworte: Andreas Spillner • C++ • Entwurf von Unit-Testfällen • Googletest-Framework • ISO 29119 • Lean Testing • Softwaretest • TDD • Test driven development • Testen • Testgetriebene Entwicklung • Testverfahren • Ulrich Breymann • Unit Test • Werkzeugunterstützung
• ISBN-10: 3-86491-967-3 / 3864919673
• ISBN-13: 978-3-86491-967-1 / 9783864919671