|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Ein Praxishandbuch für Entwickler,
Tester und technische Projektleiter
2., aktualisierte Auflage
Stephan Grünfelder
stephan.gruenfelder@aon.at
Lektorat: Sandra Bollenbacher
Copy-Editing: Geesche Kieckbusch, Hamburg
Satz: Frank Heidt
Herstellung: Susanne Bröckelmann
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Print978-3-86490-448-6
PDF978-3-96088-148-3
ePub978-3-96088-149-0
mobi978-3-96088-150-6
2., aktualisierte Auflage 2017
Copyright © 2017 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Wie viele Artikel und Bücher habe ich schon gelesen, in denen im ersten Satz steht, dass Computersysteme immer komplexer werden oder Entwicklungszyklen immer kürzer und dass man deshalb von nun an Dinge besser/schneller machen muss als früher? Ich kann es nicht sagen. Diese Ausrede und Einleitung ist aber schon seit mehreren Jahrzehnten gültig, denn Techniken werden unentwegt weiterentwickelt, Technologien wandeln sich durch neue Einflüsse und die Zeit steht niemals still. Schon gar nicht rund um die Themen der Software-Entwicklung. Dieses Buch wurde nicht geschrieben, weil gerade jetzt alles komplexer wird und ich, als Autor, der Welt sagen will, wie man damit umgeht, sondern weil es im deutschsprachigen Raum noch kein brauchbares Buch zum Thema Test von Software eingebetteter Systeme gab und ich oft genug gesehen habe, wie schwer sich manche Leute damit tun.
Das Buch vermittelt praxisnahes Wissen zum Test von Software eingebetteter Systeme, so wie es jetzt und heute gemacht wird oder gemäß dem industriellen Stand der Technik gemacht werden sollte. Auch wenn der Stand der Wissenschaft und Forschung für das Schreiben des Buchs wichtig war, so nehmen forschungsnahe Themen nur wenig Platz ein, wenn deren industrielle Umsetzung Probleme bereitet. Das Buch präsentiert viele Beispiele, persönliche Erfahrungsberichte und enthält praxisnahe Fragen und Lösungen zum Selbsttest. Die Terminologie des Buchs orientiert sich weitgehend an der des ISTQB-Certified-Tester-Schemas und der Normenreihe ISO 29119. Das Buch ist dabei an vielen Stellen komplementär zum Curriculum des ISTQB, speziell dann, wenn es um Echtzeit, Concurrency und maschinennahe Themen geht, und es ist – unvermeidbar – zum Teil redundant dazu.
Software für eingebettete Systeme unterscheidet sich von anderer Software dadurch, dass die Software Teil des Produkts ist, das der Kunde kauft, und nicht das Produkt selbst. Meist wird das Produkt, in das ein Prozessor mit zugehöriger Software eingebettet ist, wertlos, wenn die Software nicht zuverlässig funktioniert. Im schlimmsten Fall muss es vom Markt genommen werden. Kein Wunder also, dass man sich in dieser Sparte der Software-Entwicklung besonders viele Gedanken zur Korrektheit von Software macht.
Aber durch Testen alleine erhält man kein fehlerfreies Produkt. Wie ein alter Freund von mir zu sagen pflegte: »Man kann Software nicht am Ende der Produktentwicklung ›gesund testen‹, wenn es in so manchen Entwicklungsschritten zuvor krankt.« Das vorliegende Buch beschäftigt sich daher auch mit Praktiken links und rechts vom Test, die die Entwicklung begleiten und dazu beitragen, mit höherer Wahrscheinlichkeit »gesunde« Software zu erhalten.
Das Spektrum eingebetteter Systeme reicht von batteriebetriebenen 16-Bit-Controllern ohne Betriebssystem und mit geringen Anforderungen an die Systemintegrität bis hin zu im Internet Of Things vernetzten Multiprozessor-Systemen mit Echtzeitbetriebssystem, Mensch-Maschine-Schnittstelle und Sicherheitsrelevanz. Entsprechend viele Zielgruppen hat dieses Buch. Daher gibt es vermutlich Kapitel im Buch, die für Ihre speziellen Aufgaben irrelevant sein könnten. Sie dürfen diese Kapitel gerne überspringen, denn ich habe mir größte Mühe gegeben, jedes Kapitel weitgehend unabhängig von den anderen zu schreiben, und das Letzte, was dieses Buch tun sollte, ist, Sie zu langweilen. So können Systemtester zum Beispiel getrost die Kapitel über Reviews und statische Analyse auslassen. Die Unabhängigkeit der Kapitel macht es nötig, dass Inhalte teilweise wiederholt werden müssen.
Fans moderner Programmiersprachen sollten sich nicht daran stoßen, dass fast alle Beispielprogramme im Buch in der Programmiersprache C geschrieben sind. C ist weder komfortabel noch modern, doch hat C noch immer seinen festen Platz in der Entwicklung von Produkten mit höchsten Qualitätsanforderungen, und die meisten Entwickler verstehen die Basissyntax dieser Sprache ohne Probleme.
Ich wünsche Ihnen viel Freude beim Lesen und viel Erfolg bei der Umsetzung der in diesem Buch präsentierten Ideen.
Herzlichst
Stephan Grünfelder, Oktober 2016
Ich persönlich fand es immer ärgerlich ein Buch zu lesen, in dem ein Autor über Themen schrieb, bei denen er – wie ich später herausfand – nicht wirklich sattelfest war oder die er nur aus einem einzigen Projekt kannte. Nun habe ich selbst ein Buch verfasst und noch dazu eines mit dem Anspruch, praxisnah zu sein. Ich kann nicht für alle in diesem Buch beschriebenen Methoden ein Experte mit jahrelanger Erfahrung sein. Um meinen eigenen Ansprüchen an ein Fachbuch gerecht zu werden, war es daher unumgänglich, Partner zur Unterstützung hinzuzuziehen. Diesen Unterstützern gilt mein besonderer Dank. Ich nenne zunächst Personen, die ganze Kapitel (mit)gestaltet haben:
Reinhard Wilhelm, wissenschaftlicher Direktor des Leibniz-Zentrums für Informatik und Professor an der Universität des Saarlandes, hat das Kapitel über Worst Case Execution Timing Analysis verfasst.
Michael González Harbour, Professor des Computer- und Echtzeitteams der Fakultät für Computer und Elektronik der Universität Kantabrien, Spanien, hat das Kapitel über Schedulability-Analyse geschrieben.
Oliver Alt, Autor des Buchs »Modell-basierter Systemtest von Car Multimedia Systemen mit SysML« steuerte den größten Teil von Kapitel 15 bei.
Stoff und Idee für das Kapitel »Trace-Daten im Testumfeld« kamen von Alexander Weiss, Accemic GmbH, und von Martin Leucker, Professor am Institut für Softwaretechnik und Programmiersprachen an der Universität zu Lübeck.
Johannes Bergsmann, gerichtlich vereidigter Sachverständiger und Ziviltechniker für Informatik sowie Geschäftsführer des Unternehmens Software Quality Lab, hat mich durch eine Review des Kapitels 17 unterstützt und den Großteil von Kapitel 18 geschrieben.
Die Inhalte aus Kapitel 19 zum Thema Haftung stammen aus einer Publikation, die ich im Jahr 2009 gemeinsam mit dem Heidelberger Fachrechtsanwalt Tobias Sedlmeier und zuvor genanntem Johannes Bergsmann veröffentlicht habe. Für die unabhängige Durchsicht des auf Basis dieser Publikation neu geschriebenen Kapitels danke ich dem Münchner Rechtsanwalt Christian R. Kast recht herzlich.
Eine ganze Reihe von Personen hat mich durch eine Review oder Ergänzungen des Manuskripts unterstützt. Ich freue mich, dass die folgenden von mir ausgewählten Spezialisten meiner Bitte, Teile des Buchs zu prüfen und zu ergänzen, Folge geleistet haben:
Helmut Pichler, Präsident des Austrian Testing Boards, hat die Buchpassagen mit Bezug zu ISTQB reviewt.
Markus Unterauer, Trainer und Berater für Requirements Engineering, hat das Kapitel »Anforderungen und Test« kritisch gelesen.
Gernot Salzer, Professor am Institut für Computersprachen der Technischen Universität Wien, hat meine Ausführungen zu formalen Methoden korrigiert und ergänzt. Ich gebe unumwunden zu, dass formale Methoden nicht zu meiner Kernkompetenz gehören. Dementsprechend viel Rotstift fand sich in meinem Manuskript und dementsprechend kurz ist der betreffende Abschnitt in meinem Buch. Sein Kollege Georg Weissenbacher hat diese undankbare Aufgabe bei der Überarbeitung für die zweite Auflage übernommen.
Robert Mittermayr, Promovend auf dem Gebiet der Deadlock-Analyse, unterstützte mich durch eine Review der Kapitel zu Deadlocks und Race Conditions.
Daniel Kästner, Mitbegründer der AbsInt Angewandte Informatik GmbH, ergänzte für die zweite Auflage meine Ausführungen zur statischen Data-Race-Analyse um die Technik der abstrakten Interpretation.
Renate Gutjahr, Product Managerin der PLATO AG in Lübeck, sah Kapitel 14 durch und lieferte wertvolle Ergänzungen für die Abschnitte mit Bezug zur FMEA.
Matthias Daigl von der imbus AG hat mich unterstützt, indem er die Teile der zweiten Auflage des Buchs korrigierte, die Bezug zur ISO 29119 nehmen.
Aus dem Kreis der Abonnenten meines Newsletters meldeten sich viele Testleser für einzelne Kapitel dieses Buchs; Einsteiger wie ausgewiesene Experten. Für Hinweise und Kommentare aus diesem Leserkreis danke ich Oliver Bee, Frank Büchner, Christian Fuchs, Ralf Geiger, Alfred Guszmann, Wolfgang Höllmüller, Martin Horauer, Stefan Larndorfer, Sebastian Koopmann, Reinhard Meyer, Anke Mündler, Harald Nistelberger, Rudolf Ramler, Thilo Richard, Gerald Schröder, Christian Siemers, Arnd Strube, Andreas Weigl-Pollack und Bodo Wenzel.
Meiner Frau und meinen Kindern danke ich für ihre Geduld. Viele Monate lang war ich fast jede freie Minute mit dem Schreiben des Buchs beschäftigt.
1Einleitung
1.1Motivation
1.2Abgrenzung des Buchs zu ISTQB-Lehrplänen
1.3Zur Gliederung dieses Buchs
1.4Die wichtigsten Begriffe kurz erklärt
1.4.1Definition von Fachbegriffen
1.4.2Zu Definitionen und TesterInnen
1.5Ein Überblick über das Umfeld des Software-Testing
1.5.1Ursachen von Software-Fehlern
1.5.2Warum Programmfehler nicht entdeckt werden
1.5.3Angebrachter Testaufwand
1.5.4Der Tester und der Testprozess
1.5.5Modellieren der Software-Umgebung
1.5.6Erstellen von Testfällen
1.5.7Ausführen und Evaluieren der Tests
1.5.8Messen des Testfortschritts
1.5.9Testdesign und Testdokumentation im Software-Entwicklungsprozess
1.5.10Verschiedene Teststufen und deren Zusammenspiel
1.5.11Andere Verifikationsmethoden als Ergänzung zum Test
1.5.12Agile Prozessmodelle
1.5.13Der Software-Test in agilen Vorgehensmodellen
1.5.14Wer testet die Tester?
2Anforderungen und Test
2.1Die Bedeutung textueller Anforderungen
2.2Requirements Engineering im Projekt
2.3Arten und Quellen von Anforderungen
2.4Warum Anforderungen dokumentiert werden sollen
2.5Die Review von Anforderungen
2.5.1Testbarkeit von Anforderungen
2.5.2Modifizierbarkeit und Erweiterbarkeit
2.5.3Relevanz von Anforderungen
2.6Der Umgang mit natürlicher Sprache
2.6.1Einfache Sprache gegen Missverständnisse
2.6.2Gelenkte Sprache
2.7Hinweise zur Dokumentenform
2.8Die Spezifikation an der Schnittstelle zum Testteam
2.8.1Konfiguration von Testdesigns
2.8.2Vollständigkeit von Spezifikationen
2.9Werkzeuge zur Review von Anforderungen
2.10Diskussion
2.10.1Verifikation beim Requirements Engineering mit Augenmaß
2.10.2Bewertung der Rolle des Requirements Engineering für den Testprozess
2.11Fragen und Übungsaufgaben
3Review des Designs
3.1Ziele der Review des Architekturdesigns
3.2Ziele der Review des Detaildesigns
3.3Eigenschaften von gutem Software-Design
3.4Hinweise zur Architektur-Design-Review
3.5Embedded Design
3.5.1Sicherheit, Verfügbarkeit & Co
3.5.2Wartbarkeit des Geräts
3.5.3Ressourcenverbrauch
3.5.4Design von Echtzeitsystemen
3.6Diskussion
3.7Fragen und Übungsaufgaben
4Automatische statische Code-Analyse
4.1Motivation zum Einsatz von Analysewerkzeugen
4.2Techniken von Analysewerkzeugen im unteren Preissegment
4.2.1Sprachspezifische Fallstricke
4.2.2Kontrollflussanalyse
4.2.3Datenflussanalyse, Initialisation Tracking
4.2.4Datenflussanalyse, Value Tracking
4.2.5Semantische Analyse
4.2.6Starke Typenprüfung
4.3Techniken von Analysewerkzeugen im oberen Preissegment
4.3.1Größerer Komfort für den Benutzer
4.3.2Concurrency Checks
4.3.3Stack-Analyse und erweiterte Kontrollflussanalyse
4.3.4Erschöpfende Analyse des Zustandsbaums
4.4Statische Security-Analyse (SSA)
4.5Code-Metriken
4.6Werkzeuge für die Automatische Code-Analyse
4.7Diskussion
4.8Fragen und Übungsaufgaben
5Code-Reviews
5.1Review-Arten
5.1.1Code-Inspektionen
5.1.2Walkthrough
5.1.3Peer-Review
5.2Pair Programming
5.3Werkzeuge zur Code-Review
5.4Diskussion
5.5Fragen und Übungsaufgaben
6Unit-Tests
6.1Der Unit-Test im Entwicklungsprozess
6.2Zur Definition von Unit-Test und Modultest
6.3Black-Box-Testfälle beim White-Box-Test
6.3.1Äquivalenzklassenbildung
6.3.2Grenzwertanalyse
6.3.3Andere Methoden
6.4Stubs und Treiber
6.5Verschiedene Typen von Werkzeugen beim White-Box-Test
6.5.1Unit-Test-Frameworks
6.5.2Werkzeuge zur Testerstellung
6.5.3Werkzeuge zur Messung der Testabdeckung
6.6Testabdeckung
6.6.1Statement Coverage
6.6.2Branch Coverage und Decision Coverage
6.6.3Decision/Condition Coverage
6.6.4Modified Condition/Decision Coverage
6.6.5Andere Testabdeckungen
6.6.6Testabdeckung bei modellbasierter Entwicklung
6.6.7Messung der Testabdeckung
6.7Basis Path Testing
6.8Host oder Target Testing?
6.9Den Code immer unverändert testen?
6.10Unit-Tests bei objektorientierten Sprachen
6.11Grenzen des Unit-Tests
6.12Werkzeuge für den Unit-Test
6.12.1Unit-Test-Frameworks
6.12.2Werkzeuge zur Testerstellung
6.12.3Coverage-Analyse
6.13Diskussion
6.13.1Testabdeckung
6.13.2Organisation von Unit-Tests
6.14Fragen und Übungsaufgaben
7Integrationstests
7.1Software/Software-Integrationstest
7.1.1Bottom-up-Unit-Tests als Integrationstest
7.1.2Strukturierter Integrationstest
7.1.3Testabdeckung der Aufrufe von Unterprogrammen
7.1.4Vergleich der Teststrategien
7.1.5Grenzen des Software/Software-Integrationstests
7.1.6Diskussion des Software/Software-Integrationstests
7.2Ressourcentests
7.2.1Statischer Ressourcentest
7.2.2Dynamischer Ressourcentest
7.3Hardware/Software-Integrationstest
7.3.1Bottom-up-Verfahren
7.3.2Regressionsverfahren
7.3.3Black-Box-Verfahren
7.3.4Test und Analysen bei Sicherheitsrelevanz
7.3.5Diskussion des Hardware/Software-Integrationstests
7.4Systemintegrationstest
7.5Werkzeuge für den Integrationstest
7.6Fragen und Übungsaufgaben
8Systemtests
8.1Funktionale Systemtests
8.1.1Zuordnung funktionaler Systemtests zu Anforderungen
8.1.2Äquivalenzklassen und Grenzwerte im Black-Box-Test
8.1.3Zustandsbasierter Test
8.1.4Ursache-Wirkungs-Analyse
8.1.5CECIL-Methode
8.1.6Entscheidungstabellentechnik
8.1.7Paarweises Testen und Klassifikationsbaum-Methode
8.1.8Back To Back Testing
8.1.9Erfahrungsbasierter Test
8.1.10Diskussion des Black-Box-Tests
8.1.11Auswahl eines Black-Box-Testverfahrens für eine Aufgabe
8.1.12Werkzeuge für Funktionstests
8.2Test der Benutzerschnittstelle
8.2.1Grafische Benutzerschnittstelle
8.2.2Werkzeuge für GUI-Tests
8.2.3Eingebettete Benutzerschnittstellen
8.2.4Werkzeuge für den Test von eingebetteten Benutzerschnittstellen
8.3Performanztest und Lasttest
8.4Stresstest
8.5Volumentest
8.6Failover und Recovery Testing
8.7Ressourcentests
8.8Installationstests
8.9Konfigurationstests
8.10Security-Tests
8.11Dokumententests
8.12Testumgebung und Testdaten
8.13Formale Methoden
8.13.1Symbolischer Test
8.13.2Deduktive Verifikation von funktionalen Anforderungen
8.13.3Model Checking
8.14Automation von Systemtests
8.14.1Vor- und Nachteile der Testautomation
8.14.2Tipps zur Automation von Systemtests
8.15Dokumentation des Testdesigns und der Testergebnisse
8.16Grenzen des Systemtests
8.17Fragen und Übungsaufgaben
9Testen von RTOS und Middleware
9.1Definition und Motivation
9.2White-Box-Requirements-Test
9.3Test eines Interrupt-Managers
9.4Test eines Schedulers
9.5Fragen und Übungsaufgaben
10Race Conditions
10.1Definition von Data Races
10.2Dynamische Data-Race-Analyse
10.2.1Eraser
10.2.2Lamports Happens-Before-Relation
10.3Statische Data-Race-Analyse
10.3.1Ansätze zur statischen Data-Race-Analyse
10.3.2Vergleich zur dynamischen Data-Race-Analyse
10.4Werkzeuge für die Data-Race-Analyse
10.5Diskussion
10.6Fragen und Übungsaufgaben
11Deadlocks
11.1Über die Entstehung von Deadlocks
11.2Verschiedene Arten der Deadlock-Analyse
11.3Dynamische Deadlock-Analyse
11.4Statische Deadlock-Analyse
11.5Werkzeuge zur Deadlock-Detektion
11.6Diskussion
11.7Fragen und Übungsaufgaben
12Echtzeit-Verifikation
12.1Antwortzeiten bei funktionalen Tests
12.2WCET-Analyse
12.2.1Problemstellung
12.2.2Laufzeitanalyse
12.3Werkzeuge für die WCET-Analyse
12.4Diskussion
12.5Fragen und Übungsaufgaben
13Schedulability-Analyse
13.1Aufgaben der Schedulability-Analyse
13.2Definitionen
13.3Diskussion der Scheduling-Strategien
13.3.1Statisches Scheduling
13.3.2Dynamisches Scheduling
13.4Analyse bei Fixed-Priority-Single-CPU-Systemen
13.4.1Optimale Prioritätsvergabe
13.4.2Rate Monotonic Analysis
13.4.3Exakte Antwortzeitenanalyse
13.4.4Gegenseitiger Ausschluss
13.4.5Aperiodische Aufgaben
13.4.6Kontextwechsel
13.4.7Cache und Out Of Order Execution
13.4.8Input-Jitter
13.4.9Interrupts
13.5Multi-CPU-Systeme
13.5.1Multicore- und Multiprozessor-Systeme
13.5.2Verteilte Systeme
13.6Scheduling-Analyse für CAN
13.7Werkzeuge
13.8Diskussion
13.9Fragen und Übungsaufgaben
14Hardware/Software-Interaktionsanalyse
14.1Die FMEA als Grundlage der HSIA
14.2Die HSIA als Quelle für Software-Anforderungen
14.3Software-Kritikalitätsanalyse
14.4Software-FMEA
14.5Werkzeuge
14.6Diskussion
14.7Fragen und Übungsaufgaben
15Modellbasierter Test
15.1Begriffsdefinition
15.2MBT und Testautomation
15.3Modelle
15.3.1Statecharts
15.3.2SDL
15.3.3Message Sequence Charts
15.3.4UML Version 2
15.3.5SysML
15.3.6Funktionsmodellierung
15.4Testmodell vs. Implementierungsmodell
15.5Werkzeuge
15.6Diskussion
15.7Fragen und Übungsaufgaben
16Trace-Daten im Testumfeld
16.1Das Dilemma mit instrumentiertem Code
16.2Embedded-Trace-Schnittstellen
16.3Werkzeuge
16.4Diskussion
17Testmanagement
17.1Testplanung
17.2Teststeuerung
17.3Abweichungsmanagement
17.4Bewertung und Anpassung des Testprozesses
17.4.1Formale Reifegradmodelle für den Software-Test
17.4.2Prozessbewertung in agilen Projekten
17.4.3Mit Augenmaß ins Kostenoptimum
17.5Risikobasierter Test
17.6Werkzeuge
17.7Diskussion
17.8Fragen und Übungsaufgaben
18Qualitätsmanagement
18.1Definition
18.2Qualitätsmanagement-Standards
18.3Kosten und Haftungsrelevanz des QM
18.4Umsetzung des Qualitätsmanagements
18.5Die Rolle des Qualitätsmanagers
18.6Mit Metriken die Qualität steuern
18.7Die Wirtschaftlichkeit von QM
18.8Werkzeuge
18.9Diskussion
18.10Fragen und Übungsaufgaben
19Software-Test und Haftungsrisiko
19.1Ein Software-Fehler im Sinne des Gesetzes
19.2Vertragliche Gewährleistung und Haftung
19.3Vertragliche Beschränkung der Haftung
19.4Produzentenhaftung bei Software
19.5Produkthaftung
19.6Sorgfaltspflicht des Software-Herstellers
19.7Technische Normen mit Bezug zum Software-Test
19.7.1DIN IEC 56/575/CD
19.7.2IEEE Std 1012
19.7.3IEEE Std 829
19.7.4IEEE Std 1008-1987
19.7.5ISO/IEC 29119
19.7.6IEC/EN 61508
19.7.7ISO 26262
19.7.8Normenreihe 250XX
19.8Tipps vom Rechtsanwalt und vom Techniker
19.9Fragen und Übungsaufgaben
Nachwort
Anhang
Anhang A – Lösungen zu den Übungsaufgaben
Anhang B – Dokumentation des Testdesigns
Anhang C – Software-Verifikationsplan
Anhang D –Software-Verifikationsreport
Quellenverzeichnis
Index
Fast jeder fortgeschrittene Programmierer hat ein oder mehrere Bücher über Programmiersprachen und Software-Entwicklung gelesen. Bücher über das Testen von Software stehen aber weit weniger oft in den Regalen. Das liegt vermutlich unter anderem am hartnäckigen Gerücht, dass Testen von Software langweilig sei. Um diesem Gerücht entschieden entgegenzutreten, ist dieses Kapitel geschrieben worden. Es soll ein Appetitanreger auf die im Buch behandelten Testthemen sein, beschreibt die Eingliederung des Tests in den Software-Entwicklungsprozess und analysiert zunächst einmal den Feind: den Software-Fehler. Doch zuvor noch ein paar Worte zur Motivation des Software-Tests, zur Eingliederung dieses Buchs in andere Literatur und ein paar Definitionen.
Fehler in der Software eingebetteter Systeme können teure Rückholaktionen zur Folge haben. Selten ist es den Anbietern von eingebetteten Systemen möglich, einfach einen Bugfix per E-Mail zu verschicken und wieder dem Tagesgeschäft nachzugehen. Daher sollte man in Branchen mit hoher Anforderung an die Software-Integrität erstens besonders bedacht sein, Software-Fehler zu vermeiden, und zweitens, gemachte Fehler zu erkennen. Punkt eins zielt auf die Prozesslandschaft, die Qualifikation der Mitarbeiter und die Unternehmensstruktur ab. Er betrachtet also, wie sehr das Talent oder – viel wichtiger – das fehlende Talent eines Mitarbeiters die Qualität des Produkts beeinflussen kann. Punkt zwei heißt, die Software und begleitende Dokumente sorgfältig zu verifizieren. Solche Dokumente können zum Beispiel die Anforderungsdefinition, Analysen der zu erwartenden CPU-Last oder das Design festhalten.
Leider wurde lange Zeit nicht nur im deutschsprachigen Raum das Thema Verifikation von Software, wozu auch Testen gehört, wenig an Hochschulen gelehrt. Eine Konsequenz daraus ist, dass Vertreter der Industrie das International Software Testing Qualifications Board (ISTQB) ins Leben gerufen haben, das eine »Certified Tester«-Ausbildung definiert. Der Inhalt des vorliegenden Buchs deckt sich nicht mit den Lehrplänen des ISTQB. In diesem Buch werden Themen genauer als durch das ISTQB behandelt, wenn sie für Embedded-Software besonders wichtig sind, und es werden Methoden präsentiert, die für eingebettete Software wichtig sein können, sich aber zurzeit nicht in den ISTQB-Lehrplänen befinden. Ebenso werden Themen der ISTQB-Lehrpläne hier nicht behandelt, wenn sie nicht technischer Natur sind oder nur Multisysteme oder reine Business-Anwendungen betreffen.
Das Buch ist für Personen ohne Vorwissen aus dem Bereich Software-Testing geschrieben. Absolventen der ISTQB-Certified-Tester-Lehrgänge werden im vorliegenden Buch daher viel Bekanntes wiederfinden und aus oben beschriebenen Gründen trotzdem ebenso viel Neues erfahren.
Die technischen Grundlagenkapitel dieses Buchs orientieren sich dabei am zeitlichen Verlauf eines Projekts. Das heißt, auch wenn das wichtigste Thema dieses Buchs der Test ist, handeln die ersten der folgenden Kapitel noch nicht vom Test, denn am Anfang eines Projekts gibt es zunächst noch keine Software, die man testen könnte. Wohl aber gibt es schon Dokumente (bei phasenorientierten Projekten) oder Vorgänge (bei agilen Vorgehensweisen), für die ein Tester einen Beitrag zur Software-Qualität leisten kann.
Kapitel 2 beschreibt, wie dieser Beitrag bei der Review von Anforderungstexten aussehen kann. Kapitel 3 beschreibt kurz die möglichen Verifikationsschritte beim Design. In den Kapiteln 4 und 5 wird beschrieben, wie Code-Reviews durchgeführt werden können und wie Werkzeuge funktionieren, die teilweise oder gänzlich automatisch Review-Aufgaben übernehmen können.
Dann erst geht es mit dem Testen los. In Kapitel 6 werden Unit-Tests, in Kapitel 7 Integrationstests und in Kapitel 8 Systemtests beschrieben. Bei Tests von Middleware können diese Teststufen alle stark verschwimmen, wie Kapitel 9 zeigt. Im Anschluss daran beschäftigt sich Kapitel 10 mit einer Art von Fehler, die nur durch Zufall in den zuvor beschriebenen Tests gefunden werden kann: Race Conditions. Das Kapitel zeigt, wie sich Data Races zuverlässig auffinden lassen, gefolgt von einem verwandten Thema: Kapitel 11 zeigt, wie sich Deadlocks automatisch auffinden lassen.
Das darauf folgende Kapitel 12 beschreibt Verfahren zur Bestimmung der maximalen Ausführungszeit von Code. Das Ergebnis kann ein wichtiger Beitrag für die Schedulability-Analyse sein, die in Kapitel 13 behandelt wird.
Spätestens nach diesem Kapitel hält sich die Reihung der weiteren Kapitel nicht mehr an den zeitlichen Verlauf eines Projekts. Die nun folgenden Kapitel sind auch weit weniger umfangreich. In Kapitel 14 wird die Hardware/Software-Interaktionsanalyse vorgestellt, die auf Produkt/System-Ebene stattfindet. Mit einem kurzen Kapitel 15 über modellbasierten Test und einem technischen Ausblick in Kapitel 16 verlässt das Buch das technische Terrain.
In Kapitel 17 werden Hinweise für das Testmanagement gegeben und Kapitel 18 beschreibt die Aufgaben und möglichen Vorgehensweisen des Qualitätsbeauftragten. Auch diese beiden Kapitel sind bewusst kurz gehalten und geben eher nützliche Tipps, als dass man lange Abhandlungen darin findet, denn zu diesen Themen gibt es jede Menge Spezialliteratur. Das Kapitel 19 widmet sich dem Thema Haftung: In welchem Maß ist ein Programmierer oder ein Tester für Fehler haftbar? Dort erfahren Sie es.
Die meisten Kapitel schließen mit einem Fragenkatalog und Übungsaufgaben zur Kontrolle des Lernziels. Am Ende des Buchs finden Sie Lösungen dazu und Quellenverzeichnisse für referenzierte Literatur.
Die ISO 29119-1 und das ISTQB-Glossary of Terms definieren eine ganze Reihe von Fachwörtern rund ums Testen. In Einzelfällen sind sie allerdings nicht übereinstimmend. Dabei ist zu erwarten, dass das ISTQB-Glossar früher oder später an die ISO 29119-1 angepasst wird. Wenn man in einem Unternehmen Dinge rund um das Thema Software-Qualität benennen möchte, ist man gut beraten, sich an diesen Definitionen zu orientieren. Das ISTQB-Glossar kann man im WWW nachschlagen, siehe [URL: ISTQB] für die englische Fassung und [URL: ISTBQ/D] für die deutschsprachige, die ISO-Norm ist kostenpflichtig.
Es ergibt nicht viel Sinn, diese Definitionen hier zu kopieren. Stattdessen enthält die folgende Aufstellung die wichtigsten Begriffe, die im vorliegenden Buch Verwendung finden, unmittelbar gefolgt von der Definition aus dem ISTQB-Glossar und einer kurzen Ergänzung:
Agile Software-Entwicklung ist eine auf iterativer und inkrementeller Entwicklung basierende Gruppe von Software-Entwicklungsmethoden, wobei sich Anforderungen und Lösungen durch die Zusammenarbeit von selbstorganisierenden funktionsübergreifenden Teams entwickeln.
Der mit großem Abstand bedeutendste Vertreter agiler Entwicklungsmodelle ist Scrum, gefolgt von Extreme Programming. Speziell in Projekten mit begrenzter Größe und nur vage definierten Anforderungen haben diese Entwicklungsmodelle ihre Berechtigung. Diese »agilen Methoden« kommen in Reinform ohne Projektleiter aus. Die Teams sind selbstorganisierend.
Audit: Ein unabhängiges Prüfen von Software-Produkten und -prozessen, um die Konformität mit Standards, Richtlinien, Spezifikationen und/oder Prozeduren basierend auf objektiven Kriterien zu bestimmen, einschließlich der Dokumente, die (1) die Gestaltung oder den Inhalt der zu erstellenden Produkte festlegen, (2) den Prozess der Erstellung der Produkte beschreiben (3) und spezifizieren, wie die Übereinstimmung mit den Standards und Richtlinien nachgewiesen beziehungsweise gemessen werden kann.
Ein Audit führt also ein externer Fachmann durch, der sich nicht nur das Produkt ansieht, sondern auch und vor allem den Entstehungsprozess des Produkts. Ein Auditor prüft, ob ein Unternehmen ein Prozessumfeld schafft, das die Wahrscheinlichkeit von guter (beziehungsweise angepasster) Software-Qualität maximiert.
Validierung ist die Bestätigung durch Bereitstellung eines objektiven Nachweises, dass die Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt worden sind.
Wer diese Definition aus der deutschen Version des ISTQB-Software-Testing-Glossars beim ersten Durchlesen versteht, gewinnt einen Preis. Weiter auf Deutsch übersetzt könnte man sagen: Validierung bestätigt, dass das Produkt, so wie es vorliegt, seinen beabsichtigten Verwendungszweck erfüllen kann. Validierung stellt also sicher, dass »das richtige Ding erzeugt wird«. Etwas weniger streng definierte die nun abgelöste IEEE 829-2008 diesen Begriff und verstand Validierung einfach als Nachweis der Erfüllung der Anforderungen.
Verifikation ist die Bestätigung durch Bereitstellung eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt worden sind.
Das IEEE Glossary of Software Engineering Terminology [IEEE 610.12] beschränkt den Begriff nicht auf Anforderungen, sondern bezieht ihn auf Entwicklungsphasen: »Verifikation ist die Prüfung eines Systems oder einer Komponente, mit dem Ziel zu bestimmen, ob die Produkte einer Entwicklungsphase die Vorgaben erfüllen, die zum Start der Phase auferlegt wurden.« Verifikation subsumiert gemäß IEEE also alle Techniken, die sicherstellen, dass man »das Ding richtig erzeugt«. Zu diesen Techniken gehören der Test des Produkts, Reviews, die Sicherstellung eines Zusammenhangs von Design, Anforderungen und Tests (Traceability) sowie Audits [PSS-05-0].
Im allgemeinen Sprachgebrauch kann man ein Ding nicht testen, das es noch nicht gibt. Das ISTQB-Glossar hat eine Definition des Begriffs Testen, der dem allgemeinen Sprachgebrauch widerspricht:
Test: Der Prozess, der aus allen Aktivitäten des Lebenszyklus besteht (sowohl statisch als auch dynamisch), die sich mit der Planung, Vorbereitung und Bewertung eines Software-Produkts und dazugehöriger Arbeitsergebnisse befassen. Ziel des Prozesses ist sicherzustellen, dass diese allen festgelegten Anforderungen genügen, dass sie ihren Zweck erfüllen, und etwaige Fehlerzustände zu finden.
Bei dieser Definition subsumiert der Begriff Test Aktivitäten, die in der älteren Definition von IEEE der Verifikation zugeordnet werden, und enthält auch Planungsschritte für das Software-Produkt. So weit gefasst ist dann fast alle Projektarbeit, außer der Produktentwicklung selbst, ein Test.
In diesem Buch wird, so wie bei der Definition von IEEE, dann vom Testgesprochen, wenn das Produkt Software, zumindest in Teilen, Gegenstand des Tests ist. Alle Schritte zur »Bewertung eines Software-Produkts und dazugehöriger Arbeitsergebnisse« davor werden aber nicht »Test« genannt, damit dem allgemeinen Sprachgebrauch und den IEEE-Standards nicht widersprochen wird.
Ansonsten entspricht die Verwendung von Fachwörtern in diesem Buch den Definitionen des ISTQB-Glossars und der ISO 29119-1. Und Hand aufs Herz: Ob man die Review dem Test (wie ISTQB) oder der Verifikation (wie IEEE) zuordnet, ist wohl weniger wichtig, als dass man sie ordentlich macht.
Mit der Niederschrift der Definition der verwendeten Fachbegriffe zu Beginneines Dokuments sehen Sie eine Praxis, die auch im Umfeld der Software-Entwicklung gut aufgehoben ist und in einschlägigen Standards so empfohlen wird, zum Beispiel [IEEE 829]. Welche Zeitverschwendung, wenn Sie als Leser einen Begriff anders verstehen als der Autor, aber erst im Laufe des Lesens dahinter kommen und deshalb zum besseren Verständnis die ersten Passagen des Buchs noch einmal lesen müssen!
Apropos Missverständnis: Wenn in diesem Buch vom Beruf des Testers oder von anderen Rollen in der Software-Entwicklung gesprochen wird, so wird immer die männliche Form verwendet. Dies soll nur der Leserlichkeit dienen, aber in keiner Weise die Frauen diskriminieren. Ein Trost für alle Leserinnen: Wahre Top-Experten nennt man Koryphäen, auch wenn es Männer sind. Und zum Wort »Koryphäe« gibt es keine männliche Form.
In diesem Teil der Einleitung wird das Umfeld des Software-Tests erörtert und ein Überblick über Möglichkeiten und Grenzen des Testens gegeben. Für das Verstehen der späteren Kapitel ist das Lesen nicht notwendig, weil große Teile von Abschnitt 1.5 redundant zum Inhalt der vertiefenden Kapitel sind. Lesern, die sich schon mit dem Thema Test auseinandergesetzt haben und die wissen, wie sie eine Brücke vom V-Modell zu agilen Methoden schlagen können, wird daher empfohlen, bei Kapitel 2 weiterzulesen.
Ohne Zweifel helfen die folgenden Seiten aber Neueinsteigern, die später vorgestellten Methoden im Software-Entwicklungsprozess besser einzuordnen. Und – wie gesagt – diese Seiten sind ein Appetitanreger auf das, was später noch im Buch behandelt wird.
Der Protagonist schlechthin im Umfeld des Software-Tests ist der Software-Fehler. Als Einstieg in das Thema Testen werden wir daher zunächst seine möglichen Ursachen untersuchen.
Warum hat Software überhaupt Fehler? Die einfachste Antwort auf diese Frage ist, dass Software von Menschen geschrieben wird, und Menschen machen nun einmal Fehler. Wenn die Antwort auf eine komplexe Frage sehr einfach ist, dann übersieht sie meistens viele Facetten des zugrunde liegenden Problems. So auch in diesem Fall. Viele Software-Fehler, die sehr viel Geld kosteten, waren alles andere als einfache Programmierfehler. Die folgende Aufzählung skizziert einige typische, aber sehr unterschiedliche Ursachen für Fehler in Software.
Ein Software-Fehler hat also viele verschiedene Ursachen. Tests sind nur geeignet, klassische Programmier- und Designfehler zu finden und sind bei allen, bis auf die letztgenannte Fehlerursache ein vergleichsweise wirkungsloses Instrument. Wenn zum Beispiel ein Kommunikationsproblem vorliegt und daher gegen eine falsche Anforderungsspezifikation getestet wird, dann nützt der gewissenhafteste Test nichts. Bis auf den Programmierfehler kann man aber allen anderen genannten Fehlerursachen durch Methoden des Managements begegnen.
Mit dem Wissen, dass Testen nur eine von vielen Maßnahmen im Kampf gegen Software-Fehler ist, nehmen wir nun den Programmierfehler, den Software-»Bug«, genauer ins Visier und erörtern, warum es so schwierig ist, alle Bugs zu finden. Die Bezeichnung Bug stammt übrigens laut Gerüchteküche von einer Motte, die auf einer Speicherplatine des Computers eines Zerstörers der US-Navy landete. Der resultierende Kurzschluss grillte nicht nur das unglückliche Insekt, sondern führte auch zu einer Fehlfunktion des Computers. Seitdem werden Software-Fehler nach dem Insekt benannt.
Vielen Software-Entwicklern ist Folgendes nicht unbekannt: Der Kunde meldet einen Programmierfehler, obwohl unzählige Stunden mit gewissenhafter Code-Review verbracht wurden, obwohl tagelang getestet wurde. Wie konnte dieser Fehler unbemerkt das Haus verlassen?
Unter der Annahme, dass sich der Kunde nicht irrt, kann einer der folgenden Punkte diese Frage beantworten:
Software wird fast nie zu 100 % getestet. Das gilt auch für sicherheitskritische Anwendungen. [Hayhurst 01Kapitel 6
