Software-Qualität: Testen, Analysieren und Verifizieren von Software (2. Auflage German Edition)

Software-Qualität

“This page left intentionally blank.”

Peter Liggesmeyer

Software-Qualität Testen, Analysieren und Verifizieren von Software 2. Auflage

Autor Prof. Dr.-Ing. Peter Liggesmeyer Software Engineering: Dependability Fachbereich Informatik Technische Universität Kaiserslautern [email protected] Weitere Informationen zum Buch unter: www.liggesmeyer.de

Wichtiger Hinweis für den Benutzer Der Verlag und der Autor haben alle Sorgfalt walten lassen, um vollständige und akkurate Informationen in diesem Buch zu publizieren. Der Verlag übernimmt weder Garantie noch die juristische Verantwortung oder irgendeine Haftung für die Nutzung dieser Informationen, für deren Wirtschaftlichkeit oder fehlerfreie Funktion für einen bestimmten Zweck. Der Verlag übernimmt keine Gewähr dafür, dass die beschriebenen Verfahren, Programme usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Der Verlag hat sich bemüht, sämtliche Rechteinhaber von Abbildungen zu ermitteln. Sollte dem Verlag gegenüber dennoch der Nachweis der Rechtsinhaberschaft geführt werden, wird das branchenübliche Honorar gezahlt.

Bibliogra¿sche Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliogra¿e; detaillierte bibliogra¿sche Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Springer ist ein Unternehmen von Springer Science+Business Media springer.de 2. AuÀage 2009 © Spektrum Akademischer Verlag Heidelberg 2009 Spektrum Akademischer Verlag ist ein Imprint von Springer

09 10 11 12 13

5 4 3 2 1

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikrover¿lmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Planung und Lektorat: Dr. Andreas Rüdinger, Dr. Meike Barth Herstellung und Satz: Crest Premedia Solutions (P) Ltd, Pune, Maharashtra, India Umschlaggestaltung: SpieszDesign, Neu-Ulm

ISBN 978-3-8274-2056-5

Vorwort zur zweiten Auflage Für den Autor eines Buches ist es ohne Zweifel ein Erfolgserlebnis, die zweite Auflage eines Werks zu erstellen; zeigt dies doch, dass die Inhalte der ersten Auflage genug Lesern interessant erschienen. Ich bin also hinreichend unbescheiden, das Konzept des Buchs für gelungen zu halten. Ihnen – liebe Leser – mache ich ein Kompliment: Ich habe mich bei den Inhalten dieses Buches bemüht, komplizierte Sachverhalte nicht unnötig kompliziert darzustellen. Ich habe sie aber auch nicht stärker vereinfacht, als möglich. Dass Sie trotzdem dieses Buch nutzen, spricht für Ihre Bereitschaft, sich mit zum Teil schwierigen Inhalten auseinander zu setzen sowie für Ihre Fähigkeit, dies erfolgreich zu bewerkstelligen. Meines Erachtens existieren zwei unerfreuliche Tendenzen bei Veröffentlichungen. Einerseits gibt es Arbeiten, die relativ einfache Sachverhalte oft mit unangemessen komplizierten Mitteln so darstellen, dass diese bei oberflächlicher Betrachtung anspruchsvoll wirken. Bei näherer Untersuchung erweist sich so etwas aber als pseudowissenschaftliche Mogelpackung. Die andere kritische Tendenz ist die Trivialisierung von Sachverhalten. Das zielt wohl meistens auf die Erschließung breiter Leserschichten, aber leider oft auf Kosten der Korrektheit der Inhalte. Ich habe mich in diesem Buch bemüht, die Inhalte so einfach wie möglich darzustellen – aber eben nicht einfacher! Ich habe mich entschieden, Ihnen – liebe Leser – das Ergebnis dieses Prozesses in dieser Form zuzumuten. Das verursacht in einigen Kapiteln dieses Buches mathematische Formeln oder in anderer Weise komplizierte Darstellungen. Meines Erachtens ist das aber notwendig. Es gibt problemimmanente Komplexitäten, die man nicht vermeiden kann – außer man befasst sich mit dem Problem nicht weiter. Und es gibt Komplexitäten aufgrund ungeeigneter Herangehensweisen – z. B. falscher Methoden. Letztere kann man vermeiden und sollte dies auch tun. Das wusste Fred Brooks übrigens bereits 1986 /Brooks 86/. Inhaltlich ist die zweite Auflage aktualisiert worden. Das hat aber mit Ausnahme des neuen Kapitels zum modellbasierten Test keine Konsequenzen für die Kapitelstruktur. Tatsächlich ist erkennbar, dass die Grobstruktur in der Software-Qualitätssicherung recht konstant ist. Natürlich erscheinen viele Fachpublikationen. Der Schluss, dass das Wissen im gleichen Maße wie die Veröffentlichungen zunimmt, ist aber falsch. So sind beispielsweise die meisten Software-Testtechniken vor 1985 publiziert worden. In der Literaturliste besitzen derartige Originalpublikationen einen hohen Stellenwert, was sie bei oberflächlicher Betrachtung einerseits etwas angestaubt erscheinen lassen mag. Andererseits erscheint mir diese Verfahrensweise sinnvoller als die Zitierung von Sekundärli-

V

teratur. Wichtige neuere Publikationen betreffen z. B. Standards, empirische Untersuchungen oder auch die Automatisierung von Prüfungen. Diese Literatur ist dann selbstverständlich beachtet worden. Die vorliegende zweite Auflage dieses Buches ist mit Hilfe von LaTeX gesetzt worden. Den Buchsatz haben Daniel Schneider und Silvia Dierschke durchgeführt. Beide arbeiten als studentische Hilfskräfte an meinem Lehrstuhl für Software Engineering: Dependability an der Technischen Universität Kaiserslautern. Darüber hinaus haben zahlreiche Kollegen vom Fraunhofer-Institut Experimentelles Software Engineering (IESE), Kaiserslautern, bei der Überarbeitung der ersten Auflage unterstützt. Besonders hervorzuheben ist die Mitarbeit von Dr. Robert Eschbach und Thomas Bauer an dem Kapitel über modellbasiertes Testen sowie von Dr. Jürgen Münch, Ove Armbrust, Dr. Jens Heidrich und Andreas Schlichting an den Inhalten zu Software-Prozessen. Allen Beteiligten sei an dieser Stelle herzlich gedankt! Mein Anspruch war und ist es, ein Buch vorzulegen, dass es dem engagierten Leser ermöglicht, die Theorie der Software-Qualitätssicherung zu erlernen, diese kritisch zu hinterfragen und in Bezug auf die Praxis zu bewerten, um eine praktikable, anwendbare Lösung zu erarbeiten. Ganz ohne Mühe und Anstrengungen ist das meiner Erfahrung nach nicht möglich. Ich würde mich freuen, wenn Sie dieses Buch als Orientierungshilfe im „Dschungel“ der Software-Qualitätssicherung nutzen würden. Ich wünsche Ihnen Spaß beim Lesen und natürlich viele neue Erkenntnisse! Kaiserslautern, im März 2009

VI

Vorwort

Vorwort zur ersten Auflage Computer und Software dringen in alle Lebensbereiche ein. Sie führen Überweisungen durch, steuern Automotoren, überwachen Patienten, lassen Flugzeuge fliegen und sorgen für die Bereitstellung der gewünschten Informationen im Internet. Mangelhafte Software-Qualität kann in einigen Anwendungsbereichen Gefährdungen hervorrufen. Software-Qualität ist stets bedeutsam für die Zufriedenheit der Benutzer. Sie ist wichtig für den Erfolg von Produkten. Aber Software-Qualität ist auch ein schwieriges Thema: Es gibt weder „die“ Software-Qualität, noch „das“ Softwareprodukt. Software-Qualität ist facettenreich. Eine Qualitätseigenschaft, die für ein Produkt besonders wichtig ist, mag für ein anderes Produkt bedeutungslos sein. Eine Steuerungssoftware für ein Verkehrsflugzeug muss den sicheren Betrieb gewährleisten und Gefährdungen weitgehend ausschließen. Dies ist für die Buchungssoftware einer Bank völlig unerheblich, da sie keine Gefährdungen verursachen kann. Die Buchungssoftware muss sicherstellen, dass Vorgänge weder verfälscht noch abgehört werden können. Dieses Buch stellt den aktuellen Wissenstand über die Techniken, Methoden, Prinzipien und organisatorischen Aspekte der Software-Qualitätssicherung umfassend dar. Ich habe es geschrieben, um Ihnen, liebe Leserin, lieber Leser, dieses für die Praxis der Softwareentwicklung so wichtige Gebiet nahezubringen. Das Buch eignet sich als Lehr- und Lernunterlage für Dozenten und Studierende sowie als Nachschlagewerk für Praktiker. Jedes Kapitel beginnt jeweils mit einer kurzen Inhaltsangabe zur Orientierung und schließt mit einer Bewertung und einer Checkliste, die insbesondere dem Praktiker Umsetzungshinweise gibt. Die Erstellung dieses Buches hat viel Zeit beansprucht – auch solche, die eigentlich Freizeit hätte sein sollen. Ich entschuldige mich bei meiner Frau Petra und meinem Sohn Alexander und bedanke mich für ihr Verständnis. Ein ganz besonderer Dank gilt meiner Sekretärin Katrin Augustin. Sie hat mit viel Engagement und Sorgfalt die Texte geschrieben, die Grafiken gezeichnet, Korrekturen eingearbeitet und den Buchsatz durchgeführt. Für Anmerkungen und Verbesserungshinweise bedanke ich mich bei Herrn Dr.-Ing. Christof Ebert, Alcatel, Paris, Herrn Dr. Eike Hagen Riedemann, Lehrstuhl Informatik 1, Universität Dortmund, Herrn Dr. Mario Winter, Lehrgebiet Praktische Informatik III, Fernuniversität Hagen, sowie dem Leiter der Abteilung Software Engineering an der Universität Stuttgart, Herrn Prof. Dr. Jochen Ludewig. Für das Korrekturlesen bedanke ich mich bei meinen wissenschaftlichen Mitarbeitern Dipl-Inf. Jörg Gericke, Dipl.-Ing. Lars Grunske, Dipl.-Ing. Bernhard Kaiser, Dipl.-Ing. Roland Neumann und Dipl.-Ing. Christopher Robinson-Mallett. Für die Bereitschaft, meine Idee zu diesem Buch aktiv umzusetzen und für viele inhaltliche und gestalterische Anmerkungen bedanke ich mich

VII

besonders bei dem Verlagsbereichsleiter und Programmplaner Informatik des Spektrum-Verlags, Heidelberg, Herrn Dr. Andreas Rüdinger. Jedes Kapitel dieses Buches ist zum Teil mehrfach von unterschiedlichen Personen gelesen und korrigiert worden. Diese Qualitätssicherung kann jedoch eine grundsätzliche Gemeinsamkeit von Software und Büchern nicht beseitigen: Einige Fehler bleiben trotz aller Bemühungen bis zur Freigabe unerkannt und werden erst im „Feldeinsatz“ bemerkt. Sollten Sie beim Lesen dieses Buches Fehler entdecken, so bitte ich Sie darum, mir eine kurze Mitteilung zu senden. Es ist beabsichtigt, Korrekturen unter http://www.liggesmeyer.de zusammenzustellen. Anregungen, Kritik und Lob sind ebenfalls jederzeit willkommen. Ich wünsche Ihnen, dass Sie beim Lesen dieses Buches neue Erkenntnisse gewinnen und praktischen Nutzen erzielen. Besonders freuen würde ich mich, wenn es mir gelingen sollte, Ihnen das oft als „trocken“ gescholtene Thema „Software-Qualitätssicherung“ als besonders reizvolles, interessantes Gebiet darzustellen, das Theorie und Praxis, Software und Hardware sowie Erfahrungswissen und mathematisch fundierte Kenntnisse verbindet. Ihr

VIII

Vorwort

Inhaltsverzeichnis 1 1.1 1.2 1.3 1.3.1 1.3.1.1 1.3.1.2 1.3.1.3 1.3.2 1.3.3 1.3.4 1.4 1.4.1 1.4.2 1.4.3 1.5

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminologie und Begriffsdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qualitätsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kontinuierliche Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modellbasierte Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unterstützende Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software-Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware-Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qualitätssicherung softwareintensiver Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Einordnung und Klassifikation der Prüftechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamischer Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formale Techniken: Symbolischer Test und formale Beweisverfahren . . . . . . . . . . . . . . . . . . . . Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 5 10 10 13 16 28 30 32 35 37 39 43 44 46 48

2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.3 2.3.1 2.3.2 2.3.3 2.4 2.5 2.5.1 2.5.2 2.5.3 2.6

Funktionsorientierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eigenschaften und Ziele des funktionsorientierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funktionale Äquivalenzklassenbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eigenschaften und Ziele der funktionalen Äquivalenzklassenbildung . . . . . . . . . . . . . . . . . . . . Beschreibung der funktionalen Äquivalenzklassenbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bewertung der funktionalen Äquivalenzklassenbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zustandsbasierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eigenschaften und Ziele des zustandsbasierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beschreibung des zustandsbasierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bewertung des zustandsbasierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ursache-Wirkungs-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Weitere funktionsorientierte Testtechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntaxtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transaktionsflussbasiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test auf Basis von Entscheidungstabellen oder Entscheidungsbäumen . . . . . . . . . . . . . . . . . . . Bewertung des funktionsorientierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 50 51 51 52 57 58 58 58 64 66 73 73 75 79 81 81

3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.3

Kontrollflussorientierter, strukturorientierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eigenschaften und Ziele des kontrollflussorientierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Anweisungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Eigenschaften und Ziele des Anweisungsüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beschreibung des Anweisungsüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bewertung des Anweisungsüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zweigüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83 84 85 85 86 87 88

IX

3.3.1 3.3.2 3.3.3 3.3.4 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8 3.5 3.5.1 3.5.2 3.5.2.1 3.5.2.2 3.5.2.3 3.5.3 3.5.3.1 3.5.3.2 3.5.3.3 3.6 3.6.1 3.6.2 3.7

Eigenschaften und Ziele des Zweigüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Beschreibung des Zweigüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Problematiken des Zweigüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Bewertung des Zweigüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Bedingungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Eigenschaften und Ziele des Bedingungsüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Einfacher Bedingungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Bedingungs-/Entscheidungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Minimaler Mehrfach-Bedingungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Modifizierter Bedingungs-/Entscheidungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Mehrfach-Bedingungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Problematiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Bewertung des Bedingungsüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Techniken für den Test von Schleifen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Eigenschaften und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Strukturierter Pfadtest und boundary interior-Pfadtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Modifizierte boundary interior-Testtechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 LCSAJ-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Eigenschaften und Ziele des LCSAJ-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Bewertung des LCSAJ-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Pfadüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Eigenschaften und Ziele des Pfadüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Bewertung des Pfadüberdeckungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Bewertung des kontrollflussorientierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

4 4.1 4.2 4.3 4.4 4.5

Datenflussorientierter, strukturorientierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Eigenschaften und Ziele des datenflussorientierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Defs/Uses-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Required k-Tuples Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Datenkontext-Überdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Bewertung des datenflussorientierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

5 5.1 5.1.1 5.1.2 5.1.2.1 5.1.2.2 5.1.2.3 5.1.3 5.1.3.1

Spezielle dynamische Testtechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Diversifizierender Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Eigenschaften und Ziele des diversifizierenden Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Back to Back-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Eigenschaften und Ziele des Back to Back-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Beschreibung des Back to Back-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Bewertung des Back to Back-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Mutationen-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Eigenschaften und Ziele des Mutationen-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

X

Inhaltsverzeichnis

5.1.3.2 5.1.3.3 5.1.4 5.1.4.1 5.1.4.2 5.1.4.3 5.1.5 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.3 5.4 5.5 5.6

Beschreibung des Mutationen-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Bewertung des Mutationen-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Regressionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Eigenschaften und Ziele des Regressionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Beschreibung des Regressionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Bewertung des Regressionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Bewertung des diversifizierenden Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Bereichstest (Domain Testing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Eigenschaften und Ziele der Bereichstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Pfadbereichstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Test fehleroffenbarender Unterbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Partition-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Bewertung der Bereichstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Zufallstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Error guessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Verwendung von Zusicherungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

6 6.1 6.2 6.2.1 6.2.1.1 6.2.1.2 6.2.1.3 6.2.1.4 6.2.1.5 6.3

Modellbasiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Eigenschaften und Ziele des modellbasierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Beschreibung des modellbasierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Charakterisierung verschiedener Modelltypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Vor- und Nachbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Temporallogiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Markov-Ketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Prozesskalküle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Bewertung des modellbasierten Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

7 7.1 7.2 7.3 7.4 7.5 7.5.1 7.5.2 7.5.2.1 7.5.2.2 7.5.2.3 7.6 7.7 7.8 7.8.1

Software-Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Eigenschaften und Ziele der Software-Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Maße und Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Maßtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Forderungen an Maße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Maßskalen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Skalendiskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Die Ordinalskala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Die Rationalskala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Die empirische Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Datenerfassung für Maßsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Zielgerichte Definition von Maßen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Auswertung von Messungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Darstellung von Messwerten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Inhaltsverzeichnis

XI

7.8.2 7.8.3 7.9 7.9.1 7.9.2 7.9.3 7.9.4 7.9.5 7.10 7.11

Auswertung mit Erfahrungswissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Auswertung mit statistischen Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Wichtige Maße für Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Die zyklomatische Komplexität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 Die Halstead-Maße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Das Maß Live Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Das Maß „Variablenspanne“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Die MTBF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Fallstudie zur Software-Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Bewertung der Software-Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

8 8.1 8.2 8.2.1 8.2.2 8.2.3 8.3 8.3.1 8.3.2 8.3.2.1 8.3.2.2 8.3.2.3 8.3.2.4 8.3.3 8.3.4 8.4 8.4.1 8.4.2 8.4.3 8.4.4 8.5 8.5.1 8.5.2 8.5.3 8.5.4 8.6

Werkzeugunterstützte statische Codeanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Eigenschaften und Ziele der werkzeugunterstützten statischen Codeanalyse . . . . . . . . . . . . 270 Stilanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Eigenschaften und Ziele der Stilanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Prüfung der Einhaltung von Programmierkonventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Bewertung der Stilanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Diagramme und Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Eigenschaften und Ziele der Nutzung von Diagrammen und Tabellen . . . . . . . . . . . . . . . . . . . . 276 Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Kontrollflussgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Programmablaufplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 Nassi-Shneiderman-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Strukturdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Bewertung der Nutzung von Diagrammen und Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Eigenschaften und Ziele des Slicings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Statisches Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Dynamisches Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 Bewertung des Slicings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Datenflussanomalieanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Eigenschaften und Ziele der Datenflussanomalieanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Durchführung der Datenflussanomalieanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Mögliche Probleme der Datenflussanomalieanalyse und ihre Behebung . . . . . . . . . . . . . . . . . 298 Bewertung der Datenflussanomalieanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Bewertung der werkzeugunterstützten statischen Codeanalyse . . . . . . . . . . . . . . . . . . . . . . . . . 303 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

9 9.1 9.2 9.2.1 9.2.2 9.2.3

Software-Inspektionen und Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Eigenschaften und Ziele von Software-Inspektionen und Reviews . . . . . . . . . . . . . . . . . . . . . . . 306 Formale Inspektionstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Eigenschaften und Ziele der formalen Inspektionstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Beschreibung der formalen Inspektionstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Bewertung der formalen Inspektionstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

XII

Inhaltsverzeichnis

9.3 9.4 9.5

Konventionelles Review in Sitzungstechnik: Structured Walkthrough . . . . . . . . . . . . . . . . . . . . . 317 Review in Kommentartechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Bewertung von Software-Inspektionen und Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

10 10.1 10.2 10.2.1 10.2.2 10.2.3 10.3 10.3.1 10.3.2 10.3.2.1 10.3.2.2 10.3.3 10.3.4 10.3.5 10.3.6 10.4

Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis . . . . . . . . . . . . . . . . 321 Eigenschaften und Ziele der formalen Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Symbolischer Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Eigenschaften und Ziele des symbolischen Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Beschreibung des symbolischen Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Bewertung des symbolischen Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Formaler Korrektheitsbeweis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Eigenschaften und Ziele des formalen Korrektheitsbeweises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Zusicherungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Das Floyd’sche Verifikationsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 Der Hoare-Kalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 Totale Korrektheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Algebraische Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Automatenbasierte Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Bewertung des formalen Korrektheitsbeweises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Bewertung der formalen Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

11 11.1 11.2 11.3 11.3.1 11.3.2 11.3.3 11.4 11.4.1 11.4.2 11.4.3 11.5 11.6 11.7 11.7.1 11.7.2 11.7.2.1 11.7.2.2 11.7.2.3 11.7.3 11.7.4 11.7.4.1 11.7.4.2

Prozesse und Prüfstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Eigenschaften und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Software-Entwicklungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Die Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Die Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Der Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Die Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Die Prüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Die Modulprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 Die Integration und die Integrationsprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Die Systemprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Organisatorische Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 Dokumentation und Auswertung der Prüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Bedeutung von Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 Prozessorientierte Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 DIN EN ISO 9001 und V-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 ISO/IEC 15504: SPICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 AQAP-Century-Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386 Anwendungsbereichsunabhängige technische Standards: Der Standard IEC 61508 . . . . . . . 386 Anwendungsbereichsspezifische technische Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 DIN EN 50128 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 RTCA/DO 178B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

Inhaltsverzeichnis

XIII

11.8

Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

12 12.1 12.2 12.2.1 12.2.2 12.2.3 12.2.4 12.3 12.3.1 12.3.2 12.3.3 12.4 12.5

Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Eigenschaften und Ziele der Nutzung von Werkzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Werkzeugtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Dynamische Testwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Statische Analysewerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Formale Verifikationswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398 Modellierende und analysierende Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Verfügbarkeit von Werkzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Abdeckung von Techniken durch Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Abdeckung von Programmiersprachen durch Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402 Abdeckung von Entwicklungs- und Zielplattformen durch Werkzeuge . . . . . . . . . . . . . . . . . . . 402 Informationsquellen über Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Bewertung der Nutzung von Werkzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

13 13.1 13.2 13.3 13.3.1 13.3.2 13.3.3 13.3.3.1 13.3.3.2 13.3.4 13.3.4.1 13.3.4.2 13.3.5 13.3.6 13.3.7 13.4 13.4.1 13.4.2 13.4.2.1 13.4.2.2 13.4.2.3 13.4.2.4 13.5 13.6

Prüfen von objektorientierter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Eigenschaften und Ziele des Prüfens von objektorientierter Software . . . . . . . . . . . . . . . . . . . . 408 Hinweise für die objektorientierte Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Objektorientierter Modultest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Klassentest als objektorientierter Modultest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412 Ein Ansatz für die Überprüfung von Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Funktionsorientierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Zustandsbasierter Test von Operationssequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Funktionsorientierte Äquivalenzklassenbildung für den Test von Operationen . . . . . . . . . . . 417 Strukturorientierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Kontrollflussorientierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Datenflussorientierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Formale Spezifikationen zur Unterstützung des objektorientierten Prüfens . . . . . . . . . . . . . . 422 Test von parametrisierten Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Test von Unterklassen und Regressionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Objektorientierter Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 Integrationstest von Basisklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 Integrationstest und Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 Integrationstest von Vererbung bei dienstanbietenden Klassen . . . . . . . . . . . . . . . . . . . . . . . . . 431 Integrationstest von Vererbung bei dienstnutzenden Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Integrationstest von Vererbung bei dienstnutzenden und dienstanbietenden Klassen . . . . 433 Integrationstest und Testumgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 Objektorientierter Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Bewertung des Prüfens von objektorientierter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

14 14.1 14.2

Prüfen von eingebetteter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439 Eigenschaften und Ziele des Prüfens von eingebetteter Software . . . . . . . . . . . . . . . . . . . . . . . . 440 Wichtige Eigenschaften von eingebetteter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

XIV

Inhaltsverzeichnis

14.2.1 14.2.2 14.2.3 14.3 14.4 14.4.1 14.4.2 14.4.3 14.4.4 14.4.5 14.5 14.5.1 14.5.2 14.5.3 14.5.4 14.5.4.1 14.5.4.2 14.5.5 14.5.5.1 14.5.5.2 14.5.6 14.6

Sicherheitskritikalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 Zuverlässigkeit und Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Echtzeitfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Dynamisches Testen von sicherheitskritischer Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Sicherheits- und Zuverlässigkeitsmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Eigenschaften und Ziele der Sicherheits- und Zuverlässigkeitsmodellierung . . . . . . . . . . . . . . 445 Software-FMECA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Fehlerbaumanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 Markov-Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Bewertung der Sicherheits- und Zuverlässigkeitsmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . 452 Stochastische Software-Zuverlässigkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Eigenschaften und Ziele der stochastischen Software-Zuverlässigkeitsanalyse . . . . . . . . . . . 453 Grundlagen der stochastischen Zuverlässigkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 Hardware- und Software-Zuverlässigkeitsanalyse im Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . 460 Software-Zuverlässigkeitsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Bestimmung von Modellparametern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Modellauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467 Beispiel eines Modells: Musas elementares Ausführungszeiten-Modell . . . . . . . . . . . . . . . . . . 471 Modellbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 Beispiele für die Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475 Bewertung der stochastischen Software-Zuverlässigkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . 476 Bewertung des Prüfens von eingebetteter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

15 15.1 15.2 15.2.1 15.2.2 15.3

Ein Praxisleitfaden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481 Organisatorische Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 Technische Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Eine einfache praxisgeeignete Prüfstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485 Beachtung spezieller Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Inhaltsverzeichnis

XV

1 Einführung Jedes Unternehmen, das Software entwickelt, bemüht sich, die beste Qualität auszuliefern. Man kann ein Ziel aber nur dann nachweisbar erreichen, wenn es präzise definiert ist, und das gilt für den Begriff „beste Qualität“ nicht. Software-Qualität ist facettenreich. Viele Eigenschaften einer Software ergeben gemeinsam die Software-Qualität. Nicht alle diese Eigenschaften sind gleichermaßen für den Benutzer und den Hersteller einer Software wichtig. Einige Eigenschaften sind für ein bestimmtes Software-Produkt besonders wichtig, andere für das gleiche Produkt vollständig irrelevant. Manche Eigenschaften stehen miteinander in negativer Wechselwirkung. Die Aussage, man wolle die beste Software-Qualität realisieren, zeigt, dass dieser Sachverhalt nicht verstanden ist. Das Ziel ist nicht die Entwicklung einer Software mit der besten, sondern mit der richtigen Qualität. Dies erfordert eine Festlegung der gewünschten Qualität durch eine so genannte Qualitätszielbestimmung. Anschließend können Maßnahmen zur Erreichung der Qualität beschlossen werden. In der Regel wird eine Kombination von konstruktiv vorausschauenden sowie analytisch prüfenden Techniken und organisatorischen Mitteln erforderlich sein. Es ist wichtig, dabei ökonomisch vorzugehen, d. h. insbesondere Zeit- und Kostenaspekte nicht zu vergessen. Dies und die Vielfalt der unterschiedlichen Software-Produkte, die eine entsprechende Vielfalt der Qualitätsanforderungen verursacht, bewirken, dass es keine universell geeignete Lösung gibt. In diesem Kapitel wird eine klassifizierende Übersicht der Vielzahl organisatorischer bzw. technischer Alternativen für das Software-Qualitätsmanagement und die Software-Qualitätssicherung gegeben.

Übersicht 1.1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Terminologie und Begriffsdefinitionen . . . . . . . . . . . . . . . . . . . . .

5

1.3

Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4

Einordnung und Klassifikation der Prüftechniken . . . . . . . . . . . 37

1.5

Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

1

1.1

Motivation

Mit dem zunehmenden Eindringen von Computern in viele Anwendungsbereiche gewinnt die Sicherstellung der korrekten, zuverlässigen Funktion der verwendeten Software an Bedeutung. Die Kostenentwicklung zeigt einen deutlich steigenden Anteil der Software-Kosten im Vergleich zu den Hardware-Kosten bei gleichzeitig erheblich längerer Lebensdauer der Software. Eine Kostenreduktion im Bereich der Software-Entwicklung ist demzufolge besonders ökonomisch. Die Analyse der Kosten von Software-Entwicklungen in Abhängigkeit der Phasen des Softwarelebenszyklus führt zu dem Ergebnis, dass der weitaus größte Anteil der Aufwendungen während der Wartungsphase eines im Markt befindlichen Produkts entsteht. Dies ist eine Folge der unzureichenden Qualität der Software. Die Ursache sind Fehler, die während der Software-Erstellung entstanden sind, und die erst bei der Produktnutzung entdeckt werden. Ist ein Software-Produkt zudem noch schlecht strukturiert, unzureichend dokumentiert und schwer verständlich, so wird die Fehlerkorrektur zu einem zeitaufwendigen Abenteuer. Die zunehmende Komplexität von Software-Produkten steigert diese Tendenz ebenfalls. Die Lokalisierung von Fehlern und ihre Beseitigung sind schwierig. Insbesondere in unzureichend strukturierter Software können vermeintliche Fehlerkorrekturen zu Folgefehlern führen, da Wechselwirkungen mit anderen Teilen der Software existieren. Ist die Ursache eines Fehlers bereits in frühen Phasen der Software-Entwicklung entstanden – z. B. während der Anforderungsdefinition oder des Entwurfs – so sind häufig umfangreiche Änderungen notwendig. Den überproportional hohen Wartungskosten und der damit verbundenen Bindung von Mitarbeitern, die an anderer Stelle fehlen, kann mit geeigneten Mitteln begegnet werden. Es gibt Methoden, die die Erstellung zuverlässiger, verständlicher und leichter änderbarer Software gestatten. Diese Methoden sind konstruktiv oder analytisch. In der Praxis sind insbesondere funktional dekomponierende und objektorientierte Software-Entwicklungsmethoden verbreitet. Beispiele sind Structured Analysis (SA) /DeMarco 85/, Structured Design (SD) und die Unified Modeling Language (UML) /Booch et al. 98/, /Rumbaugh et al. 04/. Eine umfassende Darstellung der Entwicklungsmethoden für Software ist in /Balzert 00/ enthalten.

Prinzip der integrierten Qualitätssicherung

2

Kein konstruktives Verfahren kann garantieren, dass fehlerfreie Produkte entstehen. Aus diesem Grund ist die Qualität mit analytischen Mitteln zu prüfen. Ist der Software-Entwicklungsprozess in Phasen unterteilt, so können während jeder Phase konstruktive Methoden eingesetzt werden und am Ende jeder Phase die Qualität des entstandenen Zwischenprodukts mit analytischen Mitteln beurteilt werden (Abb. 1.1). Man bezeichnet dies als das Prinzip der integrierten Qualitätssicherung. Ein Zwischenprodukt, dessen Qualität unzureichend ist, wird solange nicht in die folgende Phase weitergereicht, bis eine definierte, ausreichende

1 Einführung

Abbildung 1.1 Das Prinzip der integrierten Qualitätssicherung

Qualität erreicht ist. Diese Handlungsweise gestattet die frühzeitige Erkennung von Fehlern und ermöglicht ihre Korrektur zu einem Zeitpunkt, zu dem dies noch mit geringem Aufwand möglich ist. Das Ziel ist, möglichst viele Fehler bereits in der Prüfung zu erkennen, die auf den Konstruktionsschritt folgt, in dem der Fehler entstanden ist. Die Anzahl der Fehler, die sich über mehrere Phasen hinweg in dem Produkt befinden, soll minimiert werden. Die Qualitätssicherung setzt bereits mit dem ersten Zwischenprodukt ein, um frühzeitig Qualitätsabweichungen zu entdecken und Maßnahmen zu ihrer Beseitigung zu ergreifen. Der Test eines „fertigen“ Programms reicht allein nicht aus. Zwischen der konstruktiven und der analytischen Qualitätssicherung besteht demnach eine Wechselwirkung. Im Idealfall sollte einer konstruktiven Tätigkeit eine entsprechende analytische folgen. Die Verzahnung von Konstruktions- und Prüfschritten ist auch in Entwicklungsprozessen möglich, die keine expliziten Phasen vorsehen (z. B. Extreme Programming). Von entscheidender Bedeutung ist die frühzeitige Festlegung der zu erreichenden Qualität. Diese Qualitätszielbestimmung geschieht durch Festlegung der gewünschten Ausprägungen so genannter Qualitätsmerkmale zu einem frühen Zeitpunkt der Entwicklung. Die Software-Prüfung nimmt eine zentrale Stellung in der Software-Entwicklung ein. Jeder Pro-

1.1 Motivation

Eine frühzeitige Qualitätszielbestimmung ist wichtig.

3

grammierer wird ein erstelltes Programm starten und einige Eingaben vornehmen, um sich die erzeugten Ausgaben anzusehen und sie mit seiner Erwartung zu vergleichen. Er wird auch einen Ausdruck des Programmcodes ansehen, um Fehler zu entdecken. Im Grunde ist die erste Vorgehensweise die Anwendung eines unsystematischen dynamischen Testverfahrens und der zweite Ansatz die manuelle Durchführung unsystematischer statischer Analysen. Einerseits besitzen Prüftechniken – in einfacher Form – eine weite Verbreitung. Andererseits existiert eine weitgehende Unkenntnis der unterschiedlichen Verfahren, ihrer Systematik und ihrer Leistungsfähigkeit. Das Ziel der Prüfung muss die Erzeugung reproduzierbarer Ergebnisse unter Zugrundelegung einer klar definierten Vorgehensweise sein. Leider ist dieses Ziel in der Praxis oft noch nicht erreicht. In diesem Buch werden Techniken, Werkzeuge und Verfahrensweisen zur analytischen Software-Qualitätssicherung diskutiert. Den Schwerpunkt bilden die Prüftechniken. Neben dynamischen Tests werden statische Analysen und formale Techniken vorgestellt. Objektorientierte Analyse-, Entwurfs- und Programmiertechniken dringen zunehmend in die Praxis ein. Die Prüfung objektorientierter Software wird aufgrund dieser zunehmenden Bedeutung explizit dargestellt. Bei der Prüfung eingebetteter Software müssen die oft vorhandenen Sicherheits- und Zuverlässigkeitsanforderungen beachtet werden. Techniken für diesen Anwendungsbereich werden in einem Buchkapitel beschrieben. Einerseits verlangen nicht alle Techniken eine Werkzeugunterstützung. Inspektions- und Review-Techniken verzichten bewusst auf die Nutzung von Werkzeugen. Andererseits sind viele Techniken ohne leistungsfähige Werkzeuge nicht praktisch nutzbar. Daher ist den Werkzeugen ein Buchkapitel gewidmet. Die sinnvolle Nutzung von Techniken und Werkzeugen erfordert einen organisatorischen Rahmen, der Verfahrensweisen und Verantwortlichkeiten regelt. Man spricht in diesem Zusammenhang von Prozessen. Die Organisation von Prüfungen wird diskutiert. Software dringt zunehmend in technische Systeme ein. Sowohl für die Hardware wie auch für die Software gibt es systematische Entwicklungsund Qualitätssicherungstechniken. Hardware-Qualitätssicherungstechniken liefern oft quantifizierte Ergebnisse. Für Software gilt das nicht in gleichem Maße. Bei der Entwicklung technischer softwareintensiver Systeme ist die übliche getrennte Qualitätssicherung der Hardware- und der Software-Bestandteile nicht ausreichend, da der Systemhersteller Eigenschaften für das Gesamtsystem angeben und garantieren muss, und die Einzelresultate in der Regel nicht zusammengeführt werden können. Auch hier gilt: Das Ganze ist mehr als die Summe seiner Teile. Die Hardware-Qualitätssicherung und die Qualitätssicherung softwareintensiver Systeme werden kurz diskutiert.

4

1 Einführung

1.2

Terminologie und Begriffsdefinitionen

Im Folgenden werden einige wichtige grundlegende Begriffe definiert. In diesem Buch sind zahlreiche weitere Definitionen enthalten, die in den jeweiligen Kapiteln angegeben werden. Hier werden die folgenden Begriffe definiert: >

Qualität,Qualitätsanforderung, Qualitätsmerkmal, Qualitätsmaß

>

Ausfall, Fehler, Irrtum

>

Korrektheit

>

Vollständigkeit

>

Sicherheit

>

Zuverlässigkeit

>

Verfügbarkeit

>

Robustheit

Qualität Der Begriff der Qualität ist in der DIN EN ISO 9000 /DIN EN ISO 9000 05/ definiert als der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt. (Qualitäts-)Anforderung Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist /DIN EN ISO 9000 05/. Qualitätsmerkmal Die konkrete Festlegung und Beurteilung von Qualität geschieht durch so genannte Qualitätsmerkmale. Nach DIN EN ISO 9000 /DIN EN ISO 9000 05/ ist ein Qualitätsmerkmal ein inhärentes Merkmal eines Produkts, Prozesses oder Systems, das sich auf eine Anforderung bezieht. Qualitätsmerkmale stellen Eigenschaften einer Funktionseinheit dar, anhand derer ihre Qualität beschrieben und beurteilt wird, die jedoch keine Aussage über den Grad der Ausprägung enthalten. Ein Qualitätsmerkmal kann über mehrere Stufen in Teilmerkmale verfeinert werden. Es existieren mehrere Vorschläge für Qualitätsmerkmale, die auf Publikationen unterschiedlicher Autoren basieren (z. B. /Balzert 98/, /Pagel, Six 94/). Beispiele sind die Qualitätseigenschaften Sicherheit, Zuverlässigkeit, Verfügbarkeit, Robustheit, Speicher- und Laufzeiteffizienz, Änderbarkeit, Portierbarkeit, Prüfbarkeit und Benutzbarkeit. Während z. B. die

1.2 Terminologie und Begriffsdefinitionen

5

Qualitätseigenschaften können Wechselwirkungen besitzen.

Qualitätsmerkmale Änderbarkeit, Portierbarkeit und Prüfbarkeit für den Hersteller eines Produkts wichtig sein können, sind Merkmale wie Sicherheit, Zuverlässigkeit, Verfügbarkeit, Speicher- und Laufzeiteffizienz sowie Benutzbarkeit für den Benutzer wichtig. Sie sind daher auch für Hersteller als Mittel zur Kundenzufriedenheit relevant. Der Teil 1 der ISO/IEC-Normenreihe 9126 /ISO/IEC 9126 04/ beschreibt einige Qualitätsmerkmale. Es ist vorgesehen, die Normenreihen ISO/IEC 9126 sowie ISO/IEC 14598 durch die Normenreihe ISO/IEC 25000 (SQuaRE) zu ersetzen. In der Regel werden Techniken, die zur Kontrolle des Qualitätsmerkmals Korrektheit dienen, von jenen unterschieden, die zur Überprüfung von Qualitätsmerkmalen wie z. B. Sicherheit oder Zuverlässigkeit verwendet werden. In einigen Publikationen findet man in diesem Zusammenhang eine Unterscheidung von funktionalen Eigenschaften und nicht-funktionalen Eigenschaften. Zwischen Qualitätseigenschaften können Wechselwirkungen und Zusammenhänge existieren. Sicherheit und Verfügbarkeit sind häufig gegenläufige Optimierungsziele. Sichere Systeme sind so beschaffen, dass z. B. durch Redundanz Komponentenausfälle erkannt werden können und das System in einen sicheren Zustand übergehen kann. In diesem Zustand wird die normale Funktion des Systems nicht erbracht, was die Verfügbarkeit reduziert. Sichere (z. B. zweikanalige, so genannte 2-aus-2-Systeme) besitzen daher im Allgemeinen eine geringere Verfügbarkeit, als die konventionelle einkanalige Struktur. Software kann entweder im Hinblick auf Speichereffizienz – d. h. möglichst geringer Speicherbedarf – oder auf Laufzeiteffizienz – d. h. geringstmögliche Laufzeit – optimiert werden. Oft bewirkt eine Verbesserung eines Qualitätsmerkmals eine Verschlechterung des anderen Qualitätsmerkmals. Die Forderung nach der insgesamt in jeder Hinsicht bestmöglichen Qualität ist daher unsinnig. Dies ist aufgrund der Wechselwirkungen der Qualitätsmerkmale prinzipiell unmöglich. Die Festlegung der zu erreichenden Ausprägungen der einzelnen Qualitätsmerkmale muss zu einem frühen Zeitpunkt der Entwicklung geschehen. Man führt eine so genannte Qualitätszielbestimmung durch. Qualitätsmaß Die konkrete Feststellung der Ausprägung eines Qualitätsmerkmales geschieht durch so genannte Qualitätsmaße. Dies sind Maße, die Rückschlüsse auf die Ausprägung bestimmter Qualitätsmerkmale gestatten. Als Qualitätsmaß für das Qualitätsmerkmal Zuverlässigkeit kann z. B. die MTTF (Mean Time to Failure) verwendet werden. Fehlverhalten

ACHTUNG: Die Begriffe Fehlverhalten, Fehler und Irrtum werden in einigen Publikationen abweichend definiert.

6

Ein Fehlverhalten oder Ausfall (failure) zeigt sich dynamisch bei der Benutzung eines Produkts. Beim dynamischen Test einer Software erkennt man keine Fehler sondern Fehlverhalten bzw. Ausfälle. Diese sind

1 Einführung

Wirkungen von Fehlern im Programm. Bei Hardware sind z. B. Ausfälle durch Verschleiß möglich. Fehler Ein Fehler oder Defekt (fault, defect) ist bei Software die statisch im Programmcode vorhandene Ursache eines Fehlverhaltens oder Ausfalls. Bei Hardware sind ebenfalls Konstruktionsfehler möglich (z. B. eine zu schwache Dimensionierung der Kühlung eines Leistungshalbleiters). Irrtum Die Ursache eines Fehlers kann ein Irrtum (error) des Programmierers oder ein einfacher Tippfehler sein. Ein Irrtum kann z. B. ein falsches Verständnis der Wirkung eines bestimmten Konstrukts der verwendeten Programmiersprache sein. Irrtümer, Fehler und Fehlverhalten stehen oft in einer Beziehung zueinander. So kann z. B. ein Irrtum – das falsche Verständnis eines bestimmten Konstrukts der Programmiersprache – dazu führen, dass eine Anweisung des Programms fehlerhaft ist und bei ihrer Ausführung ein anderes Verhalten als gewünscht – ein Fehlverhalten – zeigt. Korrektheit /Endres 77/ definiert das Qualitätsmerkmal Korrektheit als Synonym für Fehlerfreiheit als Übereinstimmung zwischen dem beobachteten und dem gewünschten Verhalten: „...ein Programm ist korrekt,wenn es frei ist von logischen Fehlern, d. h. wenn seine Implementierung übereinstimmt mit einer mehr oder weniger expliziten Spezifikation dessen,was das Programm tun soll.“ Derartige Definitionen sind an der Praxis orientiert. Sie eignen sich aber nicht optimal zur Festlegung eines Kriteriums zur Prüfung von Korrektheit, da sie bereits in der Definition eine erhebliche Unschärfe enthalten. So wird z. B. Der Grad der Erfüllung der Benutzererwartung durch ein Programm in erheblichem Maße von der konkret befragten Benutzergruppe beeinflusst. Ein gelegentlicher Benutzer eines Systems wird im Allgemeinen andere Anforderungen stellen und Erwartungen haben als ein professioneller, häufiger Benutzer eines Systems. In der Fachwelt ist der folgende Korrektheitsbegriff etabliert: >

Korrektheit besitzt keinen graduellen Charakter, d. h. eine Software ist entweder korrekt oder nicht korrekt.

>

Eine fehlerfreie Software ist korrekt.

>

Eine Software ist korrekt, wenn sie konsistent zu ihrer Spezifikation ist.

1.2 Terminologie und Begriffsdefinitionen

Korrektheit ist eine binäre Eigenschaft.

7

>

Existiert zu einer Software keine Spezifikation, so ist keine Überprüfung der Korrektheit möglich.

Da aufgrund dieser Definition ein Programm bereits bei der kleinsten Abweichung von der Spezifikation als nicht korrekt gilt, kann man einerseits davon ausgehen, dass kaum ein korrektes Programm oberhalb einer gewissen Komplexität existiert. Andererseits ist es in der Praxis durchaus üblich, Fehlerprioritäten als Kriterien zur Unterscheidung tolerierbarer und nicht tolerierbarer Fehler zu verwenden. Dies gestattet die Anwendung des Korrektheitsbegriffs auf unterschiedliche Fehlerprioritäten, z. B.: Das Programm gilt als korrekt, wenn es keine Fehler der höchsten Priorität mehr enthält. Vollständigkeit Eine Software ist funktional vollständig, wenn alle in der Spezifikation geforderten Funktionen realisiert sind. Das betrifft sowohl die Behandlung von Normalfällen als auch das Abfangen von Fehlersituationen. Sicherheit Sicherheit = Abwesenheit von Risiken

Der Standard IEC 61508 /IEC 61508 98/ definiert Sicherheit als die Abwesenheit unakzeptabler Risiken. /Birolini 97/ definiert Sicherheit als Maß für die Fähigkeit einer Betrachtungseinheit, weder Menschen, Sachen noch die Umwelt zu gefährden. Man unterscheidet die Sicherheit eines ausfallfreien Systems (Unfallverhütung) von der technischen Sicherheit des ausfallbehafteten Systems. Für die hinreichende Abwesenheit von Gefährdungen durch Systeme wird im englischen Sprachraum der Begriff safety verwendet. Darüber hinaus existiert die Eigenschaft security, die mit Datensicherheit übersetzt werden kann. Sie erfasst die Eigenschaft eines Systems, Informationsverluste und unbefugten Datenzugriff zu verhindern. Zuverlässigkeit

Dependability = Reliability

8

Für Zuverlässigkeit existieren mehrere genormte Definitionen und zahlreiche Definitionen in der Fachliteratur. Die Norm DIN 40041 /DIN 40041 90/ definiert Zuverlässigkeit als Teil der Qualität im Hinblick auf das Verhalten der Einheit während oder nach vorgegebenen Zeitspannen bei vorgegebenen Anwendungsbedingungen. Die DIN EN ISO 9000 /DIN EN ISO 9000 05/ definiert Zuverlässigkeit als Sammelbegriff zur Beschreibung der Verfügbarkeit und ihrer Einflussfaktoren Funktionsfähigkeit, Instandhaltbarkeit und Instandhaltungsbereitschaft. Der entsprechende Begriff im englischen Sprachraum für Zuverlässigkeit in diesem umfassenden Sinne ist Dependability. /Birolini 97/ verwendet eine eingeschränktere Definition des Zuverlässigkeitsbegriffs. Diese Zuverlässig-

1 Einführung

keit im engeren Sinne wird mit dem Begriff Reliability übersetzt. Sie ist ein Maß für die Fähigkeit einer Betrachtungseinheit, funktionstüchtig zu bleiben, ausgedrückt durch die Wahrscheinlichkeit, dass die geforderte Funktion unter vorgegebenen Arbeitsbedingungen während einer festgelegten Zeitdauer ausfallfrei ausgeführt wird. Diese Definition gestattet eine Beschreibung der Zuverlässigkeit mit Hilfe stochastischer Techniken. So kann der Erwartungswert für die Zeitspanne bis zum Ausfall eines Systems – die so genannte Mean Time to Failure (MTTF) – angegeben und als Zuverlässigkeitsmaß verwendet werden. Bei reparierbaren Systemen verwendet man den Erwartungswert zwischen zwei aufeinander folgenden Ausfällen – die so genannte Mean Time between Failure (MTBF). Alternativ kann die Überlebenswahrscheinlichkeit R(t) verwendet werden. Sie gibt die Wahrscheinlichkeit an, ein System, das zum Zeitpunkt Null in Betrieb genommen wurde, am Zeitpunkt t noch intakt anzutreffen. Im Folgenden wird Zuverlässigkeit im letztgenannten, engeren Sinne verwendet. Zuverlässigkeit bezeichnet die Wahrscheinlichkeit des ausfallfreien Funktionierens einer betrachteten Einheit über eine bestimmte Zeitspanne bei einer bestimmten Betriebsweise. Sie ist eine mit Mitteln der Stochastik beschreibbare Eigenschaft. Zuverlässigkeit ist im Allgemeinen nicht konstant, sondern wird bei Software im Zuge der mit Fehlerkorrekturen einhergehenden Zunahme der Stabilität größer sowie durch neue Fehler im Rahmen von Funktionalitätserweiterungen kleiner. Bei Hardware-Komponenten sind Einflüsse des Verschleißes zu beachten. Die beobachtete Zuverlässigkeit wird ferner durch die Art der Benutzung eines Systems bestimmt. Es ist oft möglich, Zuverlässigkeitsprognosen mit statistischen Verfahren zu erzeugen.

Dependability wird im Deutschen auch als Verlässlichkeit bezeichnet.

Verfügbarkeit Verfügbarkeit ist ein Maß für die Fähigkeit einer Betrachtungseinheit, zu einem gegebenen Zeitpunkt funktionstüchtig zu sein. Sie wird ausgedrückt durch die Wahrscheinlichkeit, dass die Betrachtungseinheit zu einem gegebenen Zeitpunkt die geforderte Funktion unter vorgegebenen Arbeitsbedingungen ausführt. Als Maß für Verfügbarkeit kann der Quotient MT BF MT BF + MT T R verwendet werden. Der Wert dieses Quotienten kann auf zwei Arten gesteigert werden. Man kann die MTBF vergrößern, also die Zuverlässigkeit erhöhen, oder die MTTR (Mean Time to Repair) verringern, also die Stillstandszeitintervalle nach Ausfällen verkürzen. Während die Steigerung der MTBF auch auf die Zuverlässigkeit wirkt, beeinflusst die Verringerung der MTTR nur die Verfügbarkeit.

1.2 Terminologie und Begriffsdefinitionen

Zwei Möglichkeiten zur Steigerung der Verfügbarkeit

9

Robustheit

Robustheit ist graduell.

Unter Robustheit wird die Eigenschaft einer Betrachtungseinheit verstanden, auch in ungewöhnlichen Situationen definiert zu arbeiten und sinnvolle Reaktionen durchzuführen /Liggesmeyer, Rothfelder 98/. Eine – gemessen an der Spezifikation – korrekte Betrachtungseinheit kann demnach durchaus eine geringe Robustheit besitzen. Ein System ist nach der angegebenen Definition korrekt, falls es alle in der Spezifikation beschriebenen Funktionen korrekt erbringt. Falls Fälle möglich sind, die die Spezifikation nicht erfasst, so darf das System in diesen Fällen z. B. ausfallen. Es ist dennoch korrekt. Typischerweise sind derartige Fälle ungewöhnliche Betriebssituationen, z. B. fehlerhafte oder widersprüchliche Eingabedaten. Robustheit ist eher eine Eigenschaft der Spezifikation als der Realisierung. Ein robustes System ist die Folge der korrekten Umsetzung einer Spezifikation, die auch für ungewöhnliche Betriebssituationen ein bestimmtes Verhalten fordert. Da man aber im Allgemeinen nicht jeden denkbaren Fall beim Erstellen einer Spezifikation berücksichtigen kann, besitzt Robustheit einen graduellen Charakter. Es ist wichtig zu erkennen, dass eine Erhöhung der Robustheit Entwicklungsaufwand kostet, da zusätzlicher Aufwand beim Erstellen von Spezifikationen und beim Realisieren sowie Prüfen entsteht. Auch aus diesem Grund ist es sinnvoll, die erforderliche Robustheit bereits zu einem frühen Zeitpunkt der Entwicklung durch die Erstellung entsprechender Spezifikationen festzulegen. Geschieht dies z. B. in der Software-Entwicklung nicht, so werden die Programmierer entsprechenden Programmcode zur Fehlerbehandlung vorsehen. Diese Vorgehensweise, die gelegentlich als guter, defensiver Programmierstil dargestellt wird, ist keineswegs zu begrüßen. Einerseits erzeugt diese Arbeitsweise erfahrungsgemäß einen erheblichen Anteil redundanten Programmcodes, da Fehlerabfragen mehrfach implementiert werden. Andererseits kann nicht garantiert werden, dass die wirklich wichtigen abzufangenden Fälle tatsächlich abgefangen werden.

1.3 1.3.1

Stand der Technik Qualitätsmanagement

Qualitätsmanagement befasst sich insbesondere mit organisatorischen Maßnahmen zur Erreichung und zum Nachweis einer hohen Produktqualität. Hierzu gehören die Festlegung von Qualitätszielen, die Qualitätsplanung, die Qualitätssteuerung, die Qualitätssicherung und die Qualitätsverbesserung. Das Erreichen einer hohen Produktqualität ist in der Regel das primäre Ziel des Qualitätsmanagements. Da die Produktqualität im Software-Entwicklungsprozess festgelegt wird und qualitativ hochwertige Entwicklungsprozesse in der Regel eine hohe Produktqualität zur Folge haben, ist eine hohe Prozessqualität üblicherweise das sekun-

10

1 Einführung

däre Ziel des Qualitätsmanagements. Hierbei ist entscheidend, die Wirkzusammenhänge zwischen Entwicklungsschritten und der Qualität der entwickelten Produkte zu verstehen. In der Praxis haben sich im Wesentlichen zwei Arten von Ansätzen zur Erreichung und weiteren Verbesserung einer hohen Produkt- bzw. Prozessqualität durchgesetzt: a) kontinuierliche Ansätze (auch problemorientierte Ansätze genannt) und b) modellbasierte Ansätze (auch lösungsorientierte Ansätze genannt). Daneben gibt es Mischformen bzw. Ansätze, die auf besondere Anwendungsdomänen (z. B. Medizintechnik), spezifische Qualitätsaspekte (z. B. Safety) oder Einzelprozesse (z. B. Testen) spezialisiert sind. Kontinuierliche Ansätze (wie Plan-Do-Check-Act, Quality Improvement Paradigm, Six Sigma) fokussieren auf individuelle Probleme im Entwicklungsprozess einer Organisation. Üblicherweise bestehen kontinuierliche Ansätze aus sich wiederholenden Verbesserungszyklen. Ein solcher Zyklus enthält in der Regel eine Problem- bzw. Potenzialanalyse, eine darauf aufbauende Definition von quantifizierbaren Qualitätszielen, eine Bestandsaufnahme der derzeitigen Situation (dem sogenannten Baselining), die Auswahl, Anpassung und Anwendung von Verbesserungsmaßnahmen sowie die Messung des Grades der resultierenden Verbesserung. Die Interpretation der Messdaten kann dann weitere Verbesserungszyklen anstoßen. Zusätzlich werden bei der Lösung eines Problems häufig neue Verbesserungspotenziale in benachbarten Bereichen erkannt. Kontinuierliche Verbesserungsansätze sind fokussiert und priorisieren die Wichtigkeit von Verbesserungsmaßnahmen individuell für eine Organisation. Sie lassen sich genau an die Bedürfnisse der Organisation anpassen und sind selbstgesteuert. Kontinuierliche Ansätze sind allerdings in der Umsetzung oftmals schwierig und langwierig.

Kontinuierliche Verbesserungsansätze

Modellbasierte Ansätze wie ISO/IEC 15504 (SPICE) /ISO/IEC 15504 08/, CMMI /Capability Maturity Model Integration/ oder BOOTSTRAP /Koch 93/ basieren auf einem Vergleich gängiger Prozesse, Praktiken oder Produkte einer Organisation mit einem Referenzmodell, das bewährte Prozesse, Praktiken oder Produkte enthält. Genauer gesagt enthält ein Referenzmodell oftmals nur Anforderungen an Prozesse, Praktiken oder Produkte, die aus Erfahrungen erfolgreicher Organisationen resultieren. In einigen Fällen sind die Elemente eines Referenzmodells unterschiedlichen Stufen zugeordnet, die verschiedene Reifegrade einer Organisation widerspiegeln sollen. Man spricht in diesem Fall von Reifegradmodellen (engl.: Maturity Models). Eine Begutachtung (ein sogenanntes „Assessment“ bzw. „Appraisal“) erfolgt in der Regel durch den Vergleich der tatsächlich eingesetzten oder geplanten Prozesse, Praktiken und Produkte mit dem Referenzmodell. Solche Begutachtungen können einerseits der Bewertung dienen (z. B. von Anbietern bei der Auftragsvergabe), zum anderen können Referenzmodelle Orientierung geben und Wege für Verbesserungen aufzeigen.

Modellbasierte Verbesserungansätze

1.3 Stand der Technik

11

Modellbasierte Ansätze sind weit verbreitet und haben eine Reihe von Vorteilen: Verbesserungsziele wie das Erreichen einer Reifegradstufe lassen sich unabhängig von technischem Detailwissen verstehen und sind für Manager einfach kommunizierbar. Die unabhängige Begutachtung von Organisationen wird ermöglicht. Die Auswahl von Verbesserungsmaßnahmen und deren Priorisierung wird von den Modellen unterstützt. Außerdem eignen sich modellbasierte Ansätze gut, um wichtige Grundpraktiken in großen Unternehmen einzuführen und ein Qualitätsbewusstsein bei Mitarbeitern zu erzeugen. Letztlich helfen sie, die durch vielerlei Faktoren (wie z. B. die Globalisierung oder rasche technologische Änderungen) bedingte zunehmende Komplexität der Produkte und Prozesse in den Griff zu bekommen. Modellbasierten Ansätzen liegt die Hypothese zugrunde, dass die Elemente des Referenzmodells für diejenige Organisation geeignet sind, die den Ansatz anwendet. Dies ist jedoch fraglich: Da die Software-Entwicklung sehr stark von dem Entwicklungskontext abhängt und in weiten Teilen ein mensch-basierter und somit nicht-deterministischer Prozess ist, haben einzelne Prozesse oder Praktiken in verschiedenen Entwicklungskontexten sehr verschiedene Effekte. Die Elemente des Referenzmodells sind daher nicht immer geeignet oder müssen systematisch angepasst und empirisch erprobt werden, bevor sie erfolgreich eingesetzt werden können. Besonders geeignet erscheinen modellbasierte Ansätze nur für die Einführung und Verbesserung grundlegender Praktiken, die weitgehend kontextunabhängig sind (wie z. B. Projektmanagement). Erheblich schwieriger und fragwürdiger ist die Anwendung von Referenzmodellen für die Verbesserung kontextabhängiger Praktiken (wie z. B. Software-Entwurf). Hier fordern modell-basierte Ansätze üblicherweise nur die Einhaltung einfacher Grundsätze. Die Ausgestaltung bleibt dem Anwender überlassen und somit auch die Wahl des geeigneten Weges zur Erzielung hoher Qualität. Der große Erfolg von Modellen wie CMMI lässt sich unter anderem dadurch erklären, dass diese Modelle vor allem auf den unteren Reifegradstufen angewendet werden, auf denen weitgehend kontextunabhängige Basispraktiken wie das Projektmanagement beschrieben werden. Die Durchführung von Assessments und Appraisals hat sich für Beratungsfirmen als erfolgreiches Geschäftsmodell entwickelt. Solche Unternehmen engagieren sich daher verstärkt in Gremien zur Erstellung und Weiterentwicklung von modellbasierten Ansätzen. Kritisch sei angemerkt, dass hieraus auch Nachteile resultieren können, beispielsweise besteht die Gefahr, dass eine Verschiebung vom Primärziel der Erreichung hoher Qualität hin zum Ziel der Generierung von Beratungsgeschäft stattfindet. Ein weiterer Kritikpunkt bei modellbasierten Ansätzen ist, dass der Bezug zwischen Elementen des Referenzmodells und den Zielen einer Organisation meist fehlt. Das bedeutet beispielsweise, dass die Erreichung eines bestimmten Reifegrades nicht automatisch die Erfüllung von Geschäftszielen impliziert. Auf höheren Reifegradstufen for-

12

1 Einführung

dern einige Modelle explizit den Bezug zu Unternehmenszielen. Sie bieten für die Herstellung dieses Bezugs jedoch nur wenig Unterstützung oder (wie z. B. im Falle von CoBIT) verhältnismäßig starre Vorgaben. Der Beitrag der umgesetzten Maßnahmen zur Wertschöpfung der Organisation bleibt daher in der Praxis häufig unklar. Kontinuierliche und modellbasierte Verbesserungsansätze können als komplementär angesehen werden: Modellbasierte Ansätze eignen sich zur groben Identifikation von Verbesserungsbereichen und zur Erzeugung von Qualitätsbewusstsein in großen Organisationen. Kontinuierliche Ansätze eignen sich zur genauen Identifikation von Problemen und Verbesserungsoptionen sowie zur Implementierung und Optimierung von Lösungen. Kontinuierliche Verbesserungsansätze können schon bei geringer Prozessreife erfolgreich angewendet werden. Auf den hohen Reifegradstufen verlangen modellbasierte Ansätze in der Regel auch die Anwendung von kontinuierlichen Verbesserungsansätzen. Im Folgenden werden ausgewählte kontinuierliche und modellbasierte Ansätze sowie unterstützende Techniken kurz vorgestellt. 1.3.1.1

Kombination unterschiedlicher Ansätze

Kontinuierliche Ansätze

QIP und Experience Factory Das Quality Improvement Paradigm (QIP) /Basili et al. 94b/ stellt einen kontinuierlichen Verbesserungsansatz dar. Es definiert einen allgemeinen Verbesserungszyklus, der aus sechs Phasen besteht (siehe Abb. 1.2): (1) Charakterisieren und Verstehen der Umgebung und der Organisation, (2) Definition quantifizierbarer Verbesserungsziele, (3) Auswahl geeigneter Prozesse, Methoden, Techniken und Werkzeuge zur Umsetzung der Verbesserungsziele, (4) Durchführung des definierten Projekts, (5) Analyse der Resultate, Aufzeigen von Schwächen und Verbesserungsempfehlungen und (6) Konsolidierung und Sicherung der gemachten Erfahrungen in Form von Modellen und anderen Formen der strukturierten Erfahrungsablage in einer Erfahrungsdatenbank.

Quality Improvement Paradigm (QIP)

Die Experience Factory (EF) /Basili et al. 94b/ definiert eine logische und organisatorische Infrastruktur für das QIP, die auf Wiederverwendung von gemachten Erfahrungen basiert. Eine Entwicklungsorganisation legt systematisch Erfahrungen (Prozesse, Produkte, Qualitätsmodelle, Lessons Learned, Techniken, Methoden, Werkzeuge, etc.) in einer so genannten Erfahrungsdatenbank ab. Diese untergliedert sich in einen projektspezifischen und einen organisationsweiten Teil, in welche konkrete Erfahrungen in Bezug auf ein aktuell durchgeführtes Projekt (etwa Messdaten) bzw. verallgemeinerte generalisierte Erfahrungen (etwa Aufwandsbaselines) abgelegt werden. Diese Informationen werden dann bei der Planung und Durchführung eines neuen Projektes verwendet.

Experience Factory (EF)

1.3 Stand der Technik

13

Abbildung 1.2 Die Phasen des Quality Improvement Paradigms

GQM und GQM+ Strategies® Zielgerichtetes Messen

Der Goal-Question-Metric-Ansatz (GQM) /Basili et al. 94a/ wurde ursprünglich von Victor R. Basili und Dave Weiss entwickelt und hat sich über die vergangenen Jahre zum Quasi-Standard im Bereich des Aufsetzens zielgerichteter Messprogramme weiterentwickelt. Zielorientiert bedeutet in diesem Zusammenhang, dass das Messen nicht Selbstzweck ist, sondern der Erreichung eines übergeordneten Zieles dient. In der Praxis werden häufig Messdaten erhoben, ohne dass klar ist, zu welchem Zweck diese benötigt werden. Auf der anderen Seite fehlen häufig Daten, um Aussagen in Bezug auf die Erreichung von Geschäfts- oder Projektzielen einer Organisation zu machen. GQM stellt die Basistechnologie unter anderem für QIP und einen Großteil der messbasierten Qualitätsansätze dar.

GQM-Methode

Die GQM-Methode stellt sicher, dass Messziele explizit definiert werden. Für jedes Messziel werden Fragen entlang von Richtlinien abgeleitet. Schließlich werden aus den jeweiligen Fragen Metriken (d. h. eine operationale Definition von Attributen eines betrachteten Objektes, beispielsweise in Form von Kennzahlen) abgeleitet, welche die Basis für den Messplan bilden. Entlang dieses Planes können dann Messdaten im Unternehmen erhoben werden. Dieses Vorgehen stellt sicher, dass einerseits keine unnötigen Messdaten erhoben werden und andererseits alle Messdaten vorhanden sind, um Aussagen zur Beantwortung der Fragen und schließlich zur Erreichung des Messziels treffen zu können.

GQM und GQM+ Strategies®

Die GQM-Methode unterstützt zwar die zielgerichtete Spezifikation von Messprogrammen, bietet aber keine explizite Unterstützung, die Messaktivitäten auf den unterschiedlichen Ebenen einer Organisation zu integrieren und mit dort verfolgten Zielen und Strategien zu verknüpfen. Bei der GQM-Erweiterung GQM+ Strategies® /Basili et al. 07/ handelt es sich

14

1 Einführung

um einen Ansatz zur Steuerung von Geschäftszielen und Strategien mittels quantitativer Messverfahren. Der Ansatz garantiert eine durchgängig konsistente Umsetzung von Messprogrammen über verschiedene Ebenen einer Organisation, die im Einklang mit den verfolgten Geschäftszielen und Strategien und den klassischen – aus GQM bewährten – Messzielen steht. Am Ende eines Spezifikationsprozesses steht ein umfassendes Modell, welches alle Zusammenhänge zwischen Zielen, Strategien und Messaktivitäten enthält. Dies erlaubt die frühzeitige Identifikation von Zielkonflikten und verbessert die Kommunikation zwischen allen organisatorischen Einheiten. TQM Die durch die DIN EN ISO 9000 /DIN EN ISO 9000 05/ ersetzte Norm DIN EN ISO 8402 /DIN EN ISO 8402 95/ definiert den Begriff Totales Qualitätsmanagement (TQM) als „...auf der Mitwirkung aller ihrer Mitglieder basierende Führungsmethode einer Organisation, die Qualität in den Mittelpunkt stellt und durch Zufriedenheit der Kunden auf langfristigen Geschäftserfolg sowie auf Nutzen für die Mitglieder der Organisation und für die Gesellschaft zielt“.

Definition: TQM

TQM beruht auf einigen wesentlichen Grundsätzen. Zentraler Gesichtspunkt ist die Kundenorientierung in allen Vorgängen im Unternehmen. Dazu kommt die Auffassung, dass Qualität quer durch alle Bereiche und Ebenen der Organisation erzeugt wird und damit aktives Handeln aller Beteiligten erfordert. Wesentlich ist weiterhin die Ansicht, dass Qualität nicht ein zu erreichendes Ziel ist, sondern ein kontinuierlich laufender Prozess, der kein Ende hat. TQM basiert unter anderem auf den folgenden Ansätzen: Das Null-Fehler-Programm (Zero Defects Concept) ist ein von P. B. Crosby /Crosby 79/ entwickeltes Programm, das davon ausgeht, dass nur fehlerfreie Produkte wirklich akzeptabel sind. Das Ziel ist ein fehlerfreies Produkt ohne Ausschuss und Nacharbeit: „Nicht die Erzeugung von Qualität verursacht Kosten, sondern die Nichterfüllung von Anforderungen.“

Null-Fehler-Programm

Der Continuous Improvement Process (CIP), Kaizen ist ein von W. E. Deming /Deming 86/ in den 50er-Jahren in die japanische Industrie eingeführtes Programm, das die Produktivität und Qualität revolutioniert hat. Es umfasst das Prinzip der ständigen Veränderung zum Besseren (Kaizen) und ein 14-Punkte-Programm (Management-Prinzipien). Kaizen wird mit Hilfe des Deming-Zyklus realisiert (Plan-Do-Check-Act).

Kaizen

Total Quality Control (Feigenbaum, 1961) stellt ein System zur Entwicklung, Aufrechterhaltung und Verbesserung der Qualität im Marketing, in der Entwicklung, in der Produktion und im Kundendienst dar /Feigenbaum 83/.

Total Quality Control

1.3 Stand der Technik

15

Company-Wide Quality Control

Company-Wide Quality Control (Ishikawa) ist ein Konzept, das Total Quality Control (TQC) wesentlich um die Komponente der Mitarbeiterorientierung erweitert. Ishikawa ist der Erfinder der Qualitätszirkel und der Fishbone Charts (Ishikawa-Diagramme). Six Sigma

Methodik aus der Fertigung

Six Sigma (6σ ) /Pyzdek 03/ ist eine Methode zur kontinuierlichen Qualitätsverbesserung und stammt ursprünglich aus der klassischen Produktionsdomäne. Die Grundannahme ist, dass ein stabiler und vorhersagbarer Prozess maßgeblich zum Geschäftserfolg beiträgt. Die Zielsetzung von Six Sigma liegt daher in der Kontrolle von Prozess- und Produkt-Beziehungen, wobei der Schwerpunkt auf Fehlermaße gelegt wird. Six Sigma definiert eine Reihe von Praktiken zur Verbesserung von Produktionsund Geschäftsprozessen, indem die Ursachen möglicher Fehlerquellen identifiziert werden. Der Ansatz wurde durch Bill Smith bei Motorola im Jahre 1986 zum ersten Mal vorgestellt. Six Sigma definiert zwei Verbesserungszyklen basierend auf dem Deming-Zyklus (Plan-Do-Check-Act), um einerseits existierende Geschäftsprozesse zu verbessern und anderseits neue Prozesse zu entwerfen. Der Fokus liegt dabei auf Kundenzufriedenheit. In der so genannten Six Sigma-Toolbox ist eine Reihe von Werkzeugen zur Umsetzung von Six Sigma enthalten, unter anderem die QualityFunction-Deployment-Methodik (QFD) /Cohen 95/, Pareto-Analysen und Ursache-Wirkungs-Diagramme. 1.3.1.2

Modellbasierte Ansätze

ISO/IEC 9126

16

Definition: Softwarequalität

Der Standard ISO/IEC 9126 /ISO/IEC 9126 04/ ist ein umfassender Standard zur Softwarequalität und definiert Qualitätsmodelle für Software. Softwarequalität beschreibt den Grad der Erfüllung aller an die Software gestellten Anforderungen. Dabei wird die Sicht des Anwenders, des Entwicklers und des Managers unterschieden. Anwender beurteilen die Software ohne deren interne Aspekte zu kennen, Entwickler sind für die Herstellung der Software verantwortlich und an der internen Softwarequalität (der Qualität der Zwischenprodukte) interessiert, der Manager nimmt eine übergeordnete Sichtweise ein und ist am Gesamteindruck der Softwarequalität interessiert.

Definition: Qualitätsmodell

Ein Qualitätsmodell beschreibt die kausalen Beziehungen zwischen nicht greifbaren Sichten auf Qualität und greifbaren Softwaremaßen. Es setzt sich aus verbundenen und hierarchisch geordneten Qualitätsaspekten zusammen, die schlussendlich auf Softwaremaße führen.

Interne, externe und Benutzungsqualität

Die ISO/IEC 9126 unterscheidet zwischen interner Qualität, externer Qualität und Benutzungsqualität („Quality in Use“) und definiert Qualitätsmodelle für jeden der drei Bereiche (siehe Abb. 1.3). Interne Quali-

1 Einführung

External and Internal Quality

Functionality

• • • • •

Suitability Accuracy Interoperability Security Functionality compliance

Reliability

• • • •

Maturity Fault tolerance Recoverability Reliability compliance

Usability

• • • • •

Efficiency

Understandability Learnability Operability Attractiveness Usability compliance

• Time behavior • Resource behavior • Efficiency compliance

Maintainability

• • • • •

Analyzability Changeability Stability Testability Maintainability compliance

Portability

• • • • •

Adaptability Installability Co -existence Replaceability Portability compliance

Quality in use

Effectiveness

Productivity

Safety

Satisfaction

Abbildung 1.3 Übersicht der ISO/IEC 9126-Qualitätsmodelle

tät bezeichnet Software-Charakteristiken aus interner Sicht und spezifiziert Eigenschaften von Interimsprodukten. Externe Qualität bezeichnet Software-Charakteristiken aus externer Sicht und leitet sich von Qualitätsanforderungen des Benutzers ab. Benutzungsqualität stellt die Benutzersicht auf Softwarequalität in einer spezifischer Umgebung und einem spezifischen Benutzungskontext dar. Für jede der drei Qualitäten werden in einem eigens dafür bereitgestellten Teil der ISO/IEC 9126 Softwaremaße definiert, um die beschriebenen Qualitätsaspekte zu vermessen. Während die ISO/IEC 14598 den Qualitätsbewertungsprozess beschreibt, beschreibt die ISO/IEC 9126 konkrete Qualitätskriterien. Die neuere Norm ISO/IEC 25000 stellt Anleitungen zum Einsatz einer Reihe neuer Standards im Bereich der Qualitätsanforderungen eines Softwareproduktes und deren Evaluierung (Software Product Quality Requirements and Evaluation, SQuaRE) zur Verfügung. Diese so genannten SQuaRE-Standards unterteilen sich in die Bereiche Quality Management, Quality Model, Quality Measurement, Quality Requirements und Quality Evaluation. Die ISO/IEC 25000 beschreibt darüber hinaus auch den Übergangsprozess zwischen den alten Normen ISO/IEC 9126 und ISO/IEC 14598 zu den neueren SQuaRE-Standards, die sich teilweise zurzeit (2009) noch in der Entwicklung befinden.

Bezug zu verwandten Normen

ISO/IEC 12207:2008 Der internationale Standard ISO/IEC 12207:2008 /ISO/IEC 12207 08/ ist ein Prozessstandard mit dem Ziel, im Umfeld der Software-Entwicklung weltweit für eine Vereinheitlichung von Begriffen und ein gemeinsames Verständnis von Konzepten zu sorgen. Er adressiert damit das Problem,

1.3 Stand der Technik

Basis für viele Prozessstandards

17

dass vielfach die gleichen oder ähnliche Dinge mit unterschiedlichen Begriffen bezeichnet werden, oder ein- und derselbe Begriff unterschiedliche Bedeutungen hat. Der Standard deckt den Software-Lebenszyklus von der ersten Ideensammlung und Konzeption über die Erstellung bis hin zur Außerbetriebnahme ab. Viele andere Standards wie beispielsweise CMMI /Capability Maturity Model Integration/ oder ISO/IEC 15504 (SPICE) /ISO/IEC 15504 08/ leiten sich direkt oder indirekt aus ISO/IEC 12207 ab.

18

Enges Verhältnis zu ISO/IEC 15288:2008

Der Standard gruppiert die Aktivitäten, die während des Software-Lebenszyklus’ durchgeführt werden können, in sieben Prozessgruppen (Process Groups). Jeder der 44 darin beschriebenen Prozesse enthält eine Aussage zu seinem Zweck (Purpose) und erwarteten Ergebnissen (Outcomes). Weiterhin werden Aktivitäten (Activities and Tasks) aufgeführt, die zur Erzeugung der erwarteten Ergebnisse nötig sind. Die ISO/IEC 12207:2008 wurde gemeinsam mit der ISO/IEC 15288:2008 (System Life Cycle Processes) /ISO/IEC 15288 08/ entwickelt und bildet an vielen Stellen eine auf Software angepasste Variante davon. Weiterhin ist die ISO/IEC 12207:2008 explizit zur Nutzung als Prozess-Referenzmodell (PRM) in der ISO/IEC 15504 (SPICE) /ISO/IEC 15504 08/ vorgesehen.

Standalone-Systeme und Teilsysteme

Abb. 1.4 zeigt den Standard im Überblick. Im Gegensatz zur Vorgängerversion des Standards (ISO/IEC 12207:1995) /ISO/IEC 12207 95/ unterscheidet die ISO/IEC 12207:2008 zwischen Software-Systemen, die für sich alleine stehen (System Context Processes, linker Teil von Abb. 1.4) und Software-Systemen, die Teil eines übergeordneten Systems sind (Software Specific Processes, rechter Teil).

System Context Processes

Bei den System Context Processes beinhaltet die Prozessgruppe der Agreement Processes die zum Erreichen einer Übereinkunft zwischen zwei Organisationen nötigen Prozesse. Die Gruppe der Organizational Project-Enabling Processes bezeichnet Prozesse, die auf einer strategischen Ebene die Projektdurchführung unterstützen bzw. erst ermöglichen. Project Processes beschäftigen sich mit den „klassischen“ Aufgaben des Projektmanagements, d. h. Planung und Kontrolle, Entscheidungsfindung, Risikomanagement, Konfigurations- und Informationsmanagement sowie Messungen. Die eigentliche Produkterstellung von der (System-)Anforderungsfestlegung über Systemarchitektur, Implementierung, Integration, Testing, Installation, Betrieb, Wartung und Außerbetriebnahme ist in den Technical Processes beschrieben.

Software Specific Processes

Bei den Software Specific Processes beschreiben die Software Implementation Processes die Aktivitäten zur Erzeugung eines spezifischen, in Software implementierten Systemelements. Dies umfasst die Software-Anforderungsanalyse, Software-Architektur und -Design, Implementierung, Integration und Testen. Die Software Support Processes enthalten Software-spezifische Prozesse zu Dokumentation, Konfigurationsmanagement, Qualitätssicherung, Verifikation und Validation, Reviews und Audits und

1 Einführung

Abbildung 1.4 Prozesse in ISO/IEC 12207:2008

zur Problemlösung. Die Software Reuse Processes schließlich definieren Prozesse zur systematischen Wiederverwendung von Komponenten. EN ISO 9000-Reihe Mit den Standards der EN ISO 9000-Reihe werden Grundsätze für Maßnahmen im Qualitätsmanagement beschrieben. Angestrebt wird ein gegenseitiges Verständnis zwischen Auftraggebern und Auftragnehmern für Qualitätsmanagementsysteme auf nationaler und internationaler Ebene. Ermöglicht wird dieses Verständnis durch eine zusammenhängende, aufeinander aufbauende Reihe von Standards. Die Reihe ist allgemein gehalten und kann für alle Branchen angewendet werden. Es gibt allerdings zahlreiche Derivate mit einer branchenspezifischen Ausprägung. Im Zusammenhang mit der Erstellung von Software ist hierbei der Standard ISO/IEC 90003:2004 maßgebend. Bestandteile der EN ISO 9000-Reihe sind: >

Normenreihe für Qualitätsmanagement

EN ISO 9000:2005 /DIN EN ISO 9000 05/: Qualitätsmanagementsysteme – Grundlagen und Begriffe. Dieser Standard regelt allgemeine Begriffe und Grundlagen für ein umfassendes Qualitätsmanagementsystem. In diesem Standard wird auch der prozessorientierte

1.3 Stand der Technik

19

Ansatz für ein Qualitätsmanagementsystem nach den Prinzipien des Deming-Zyklus’ (Plan-Do-Check-Act) beschrieben. >

EN ISO 9001:2008 /DIN EN ISO 9001 08/: Qualitätsmanagementsysteme – Anforderungen. Mit diesem Standard wird es einer Organisation ermöglicht darzulegen, ob sie die nötigen Fähigkeiten zur Erfüllung der Anforderungen von Kunden und Behörden besitzt. Der Fokus liegt hier auf der Kundenzufriedenheit.

>

EN ISO 9004:2000 /DIN EN ISO 9004 00/: Qualitätsmanagementsysteme – Leitfaden zur Leistungsverbesserung. Dieser Standard ermöglicht die Ausrichtung der Organisation nach den Prinzipien des Total Quality Mangement (TQM). Mit der Effizienzbewertung des Qualitätsmanagementsystem werden Verbesserungsmaßnahmen angestrebt.

>

EN ISO 19011:2002 /DIN EN ISO 19011 02/: Leitfaden für Audits von Qualitätsmanagement- und/oder Umweltmanagementsystemen. In diesem Standard werden die allgemeingültigen Vorgehensweisen zur Prüfung von Qualitäts- und Umweltmanagementsystemen beschrieben.

>

ISO/IEC 90003:2004 /ISO/IEC 90003 04/: Richtlinien für die Anwendung der ISO 9001:2000 auf Computersoftware. Mit diesem Standard wird für Organisationen eine Hilfestellung gegeben, wie die EN ISO 9001 auf die Besonderheiten der Softwareerstellung angepasst werden sollte.

CMMI

20

CMMI als Nachfolger von CMM

Im Jahre 1991 hat das Software Engineering Institute (SEI) an der Carnegie Mellon University (CMU) mit dem Capability Maturity Model (CMM) ein Verfahren veröffentlicht, mit dem anhand eines Best-Practice-Modells die Prozesse eines Unternehmens bewertet und verbessert werden können. Das Modell wurde kontinuierlich weiter entwickelt und verfeinert und liegt im Jahre 2008 als Capability Maturity Model Integration (CMMI) 1.2 /Capability Maturity Model Integration/ vor. Es beschreibt Prozesse für die Entwicklung (CMMI-DEV) und Akquise (CMMI-ACQ). Für die überarbeitete Version 1.3, welche im Jahr 2010 erscheinen soll, ist die Ausdehnung auf Services (CMMI-SVC) geplant.

Bewertung und Prozessverbesserung

CMMI kann sowohl zur Bewertung von Prozessen mittels Appraisals als auch zur Prozessverbesserung genutzt werden. Im Folgenden werden die Kernkonzepte Prozessgebiete, spezifische und generische Ziele, Fähigkeits- und Reifegrade von CMMI für Entwicklungsprojekte (CMMI-DEV) 1.2 erläutert.

Prozessgebiete

CMMI-DEV 1.2 unterscheidet 22 Prozessgebiete (Process Areas) in vier Gruppen: Project Management, Engineering, Process Management und

1 Einführung

Support. Project Management beschäftigt sich mit Prozessen zum Management und der Kontrolle von Entwicklungsprojekten, inklusive Risikomanagement und (eingeschränkt) dem Management von zugekauften Komponenten. Engineering beschreibt Prozesse im Bereich der Software-Entwicklung sowie Verifikations- und Validationsprozesse. Process Management behandelt die Definition, Etablierung und Kontrolle der Prozesse der Organisation, inklusive Trainingsmaßnahmen für Mitarbeiter und (eingeschränkt) Innovationsmanagement. Support schließlich beschreibt Querschnittsprozesse wie Konfigurationsmanagement, Messen und Analysieren, Prozess- und Produkt-Qualitätssicherung und andere. Jedes Prozessgebiet beschreibt in seinem Purpose Statement das Ziel, das durch die beschriebenen Prozesse erreicht werden soll. Hauptelemente sind spezifische Ziele (Specific Goals, SG) und generische Ziele (Generic Goals, GG). Spezifische Ziele sind Ziele, die durch die Ausführung der Prozesse des jeweiligen Prozessgebiets erreicht werden sollen. Im Prozessgebiet Technical Solution (TS) sind dies beispielsweise die Ziele (SG 1) Select Product Component Solutions, (SG 2) Develop the Design und (SG 3) Implement the Product Design. Sind diese Ziele erreicht, so werden Produktalternativen geprüft, eine davon ausgewählt und über ein Design schließlich implementiert. Auf diese Weise geben die spezifischen Ziele eine Hilfestellung, was durch das jeweilige Prozessgebiet erreicht werden soll.

Spezifische und generische Ziele

Die generischen Ziele sind universell definiert und werden für jedes Prozessgebiet instanziiert. So fordert beispielsweise das generische Ziel 1 (GG 1) für jedes Prozessgebiet, die jeweiligen spezifischen Ziele zu erreichen („Achieve Specific Goals“). Das bedeutet, dass das GG 1 für das Prozessgebiet Technical Solution fordert, die oben angeführten spezifischen Ziele (SG 1) bis (SG 3) zu erreichen. Für ein anderes Prozessgebiet fordert GG 1 analog, dessen spezifische Ziele zu erreichen. Höhere generische Ziele stellen über die reinen Tätigkeiten hinaus gehende Anforderungen. Während GG 1 im Wesentlichen fordert, verschiedene Dinge zu tun (unabhängig davon, auf welche Weise oder mit welchem Aufwand dies geschieht), fordert GG 2 ein Management der entsprechenden Prozesse. Das bedeutet, das innerhalb eines Projektes die Durchführung des jeweiligen Prozesses geplant und kontrolliert werden muss, Ressourcen und Verantwortlichkeiten geklärt sein müssen, Stakeholder ermittelt und einbezogen werden müssen usw. Dies gilt für jedes Prozessgebiet. GG 2 fordert also, dass bestimmte Dinge getan werden und dies gemanagt wird. Es bleibt jedoch jedem Projekt überlassen, wie es die geforderten Dinge umsetzt. Das generische Ziel 3 (GG 3) adressiert dies indem es fordert, dass die in den Projekten verwendeten Prozesse aus einem organisationsweit gültigen Standardprozess abgeleitet werden und systematisch Verbesserungsinformationen gesammelt werden. Das generische Ziel 4 (GG 4) fordert darüber hinaus ein quantitatives Management

1.3 Stand der Technik

21

der Prozesse, und das generische Ziel 5 (GG 5) fordert schließlich die kontinuierliche, aktive Verbesserung von zur Erreichung der Geschäftsziele relevanten Prozessen. Zwei Repräsentationen

Continuous Representation

Staged Representation

22

Während eines Appraisals werden (abgeschlossene) Projekte einer Organisation darauf hin untersucht, welche der generischen Ziele erfüllt werden. CMMI unterstützt diesbezüglich zwei Repräsentationen. In der Continuous Representation können beliebige Prozessgebiete untersucht werden. Für jedes Prozessgebiet wird ein Fähigkeitsgrad (Capability Level, CL) bestimmt, der angibt, wie die Organisation bezüglich des jeweiligen Prozessgebiets abschneidet. Es gibt sechs Fähigkeitsgrade: >

CL 0: Incomplete: Keine Anforderungen (jede Organisation ist automatisch auf CL 0)

>

CL 1: Performed: Der Prozess erreicht seine spezifischen Ziele (GG 1)

>

CL 2: Managed: CL 1 und der Prozess wird gemanagt (GG 2)

>

CL 3: Defined: CL 2 und der Prozess basiert auf einem angepassten Standardprozess (GG 3)

>

CL 4: Quantitatively Managed: CL 3 und der Prozess ist unter statistischer/quantitativer Prozesskontrolle (GG 4)

>

CL 5: Optimizing: CL 4 und der Prozess wird kontinuierlich verbessert mit Hilfe der Daten aus der statistischen/quantitativen Prozesskontrolle (GG 5)

Die Bewertung einer Organisation mittels der Continuous Representation ergibt typischerweise ein kammartiges Profil der Prozesse (siehe Abb. 1.5). Diese Darstellung ist an Assessments nach ISO/IEC 15504 (SPICE) /ISO/IEC 15504 08/ angelehnt. Aus dem ursprünglichen CMM stammt die zweite Darstellungsart der Staged Representation. Hierbei wird der gesamten Organisation ein Reifegrad (Maturity Level, ML) zugewiesen. Es gibt fünf Reifegrade: >

ML 1: Initial: Keine Anforderungen (jede Organisation ist automatisch auf ML 1)

>

ML 2: Managed: Projekte werden gemanagt, ein gleichartiges Projekt kann erfolgreich wiederholt werden

>

ML 3: Defined: ML 2 und Projekte folgen einem angepassten Standardprozess, es gibt eine kontinuierliche Prozessverbesserung

>

ML 4: Quantitatively Managed: ML 3 und statistische (quantitative) Prozesskontrolle

>

ML 5: Optimizing: ML 4 und Prozesse werden systematisch und zielorientiert verbessert mit Hilfe der Daten aus der statistischen/quantitativen Prozesskontrolle

1 Einführung

Abbildung 1.5 CMMI-Prozessprofil in Continuous Representation

Da der Reifegrad Organisationen vergleichbar machen soll, ist genau definiert, welche Prozessgebiete welchen Fähigkeitsgrad aufweisen müssen zur Erreichung eines bestimmten Reifegrads: Für den Reifegrad zwei (ML 2) müssen die Prozessgebiete REQM, PP, PMC, SAM, MA, PPQA und CM jeweils mindestens den Fähigkeitsgrad zwei (CL 2) erreichen, für den Reifegrad drei (ML 3) die genannten sowie RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RM und DAR jeweils den Fähigkeitsgrad drei (CL 3). Für die Reifegrade 4 und 5 müssen darüber hinaus geschäftszielrelevante Prozessgebiete den Fähigkeitsgrad 4 bzw. 5 vorweisen. Damit würde ein Unternehmen mit einem Prozessprofil wie in Abb. 1.5 dargestellt den Reifegrad 2 (ML 2) erreichen, nicht jedoch den Reifegrad 3 (ML 3), da beispielsweise das Prozessgebiet TS nur den Fähigkeitsgrad 0 (CL 0) hat.

Reifegrad und Fähigkeitsgrad

Das Vorgehen bei der Staged Representation macht Organisationen damit (bedingt) vergleichbar, birgt jedoch auch Gefahren: erreicht eine Organisation den Reifegrad 2 (ML 2), so heißt dies ausschließlich, dass die Prozessgebiete REQM, PP, PMC, SAM, MA, PPQA und CM den Fähigkeitsgrad zwei erreichen. Es wird keine Aussage über den Zustand anderer Prozessgebiete (etwa wie im Beispiel die eigentliche Erstellung der Software durch TS) gemacht. ISO/IEC 15504 (SPICE) Der Standard ISO/IEC 15504 /ISO/IEC 15504 08/, oft auch einfach als SPICE bezeichnet, ist ein fünfteiliger internationaler Standard zur Bewertung und Verbesserung der Softwareprozesse einer Organisation. Teil 1 (ISO/IEC 15504-1:2004) definiert dabei Konzepte und Vokabular, Teil 2 (ISO/IEC 15504-2:2003) Anforderungen zur Durchführung von Prozess-Assessments als Basis von Prozessverbesserung und Fähigkeitsgrad-

1.3 Stand der Technik

Fünfteiliger Standard

23

bestimmung. Teil 3 (ISO/IEC 15504-3:2004) unterstützt die Anwender des Standards dabei, die in Teil 2 gestellten Anforderungen an Assessments zu erfüllen. Teil 4 (ISO/IEC 15504-4:2004) gibt Hilfestellung bei der Nutzung eines SPICE-konformen Assessments zur Prozessverbesserung oder Fähigkeitsgradbestimmung. ISO/IEC 12207:1995 als Basis

Drei Prozesskategorien

Der in den meisten Fällen wichtigste Teil ist Teil 5 (ISO/IEC 15504-5:2006), der ein exemplarisches Prozess-Assessment-Modell (Process Assessment Model, PAM), welches die Anforderungen aus Teil 2 erfüllt, bereitstellt. Dieses PAM nutzt ISO/IEC 12207:1995 /ISO/IEC 12207 95/ als Prozess-Referenzmodell (PRM). Anhand dieses Assessment-Modells werden die meisten SPICE-Assessments durchgeführt. Weitere PAMs existieren für bestimmte Domänen, beispielsweise im Automotive-Bereich als Automotive SPICE /Automotive SPICE/. Im Folgenden bezieht sich SPICE immer auf ISO/IEC 15504-5:2006. Analog zu ISO/IEC 12207:1995 definiert SPICE drei Prozesskategorien, die in neun Prozessgruppen 49 Prozesse zur Erstellung und zur Akquise von Softwareprodukten und -services behandeln. Er gliedert sich in drei Hauptgruppen (Abb. 1.6): 1. Primäre Lebenszyklusprozesse 2. Organisations-Lebenszyklusprozesse 3. Unterstützende Lebenszyklusprozesse

Primäre Lebenszyklusprozesse

Innerhalb der primären Lebenszyklusprozesse bildet die Acquisition-Gruppe ACQ die Prozesse des Softwarekäufers und die Supply-Gruppe SUP die des -lieferanten ab. Engineering (ENG) beschreibt die klassischen Engineering-Prozesse zur Entwicklung von Software, Operation (OPE) diejenigen für den Betrieb der erstellten Software.

OrganisationsLebenszyklusprozesse

Die Organisations-Lebenszyklusprozesse beschreiben Prozesse, die die gesamte Organisation betreffen. Management (MAN) beschreibt das Management von Projekten und einzelnen Aktivitäten. Process Improvement (PIM) beschäftigt sich mit der Verbesserung aller anderen Prozesse, Resource and Infrastructure (RIN) stellt die benötigte Infrastruktur für alle anderen Prozesse bereit. Reuse (REU) schließlich sorgt für ein systematisches Vorgehen bei der Wiederverwendung bereits entwickelter Komponenten.

Unterstützende Lebenszyklusprozesse

Die unterstützenden Lebenszyklusprozesse Support (SUP) schließlich bilden Querschnittsprozesse zur ersten Gruppe. Hierzu gehören insbesondere Prozesse zur Qualitätssicherung, Verifikation und Validation sowie Reviews und Audits. Weiterhin werden Themen wie Dokumentation, Konfigurations-, Problem- und Änderungsmanagement behandelt.

Assessments

Bei der Durchführung eines SPICE-Assessments wird eine ausgewählte Untermenge der 49 Prozesse bewertet. Die Überprüfung erfolgt dabei

24

1 Einführung

Abbildung 1.6 ISO/IEC 15504 – Übersicht

anhand vorgegebener Prozessattribute (PA). Für Level 1 gibt es nur ein solches Attribut, höhere Levels besitzen derer zwei. SPICE definiert für jeden Prozess seinen Zweck (Purpose), erwartete Ergebnisse des Prozesses (Outcomes) und typische Aktivitäten (Base Practices), die als Indikator für die Erzielung der Outcomes herangezogen werden können. Weiterhin sind typische Inputs und Outputs definiert. Für Level 1 ist die Erzielung der Outcomes entscheidend (PA 1.1 Process Performance). Für Level 2 müssen die beiden Attribute PA 2.1 Performance Management und PA 2.2 Work Product Management erfüllt sein, d. h. der Prozess und seine Arbeitsergebnisse gemanagt werden. Level 3 fordert PA 3.1 Process Definition und PA 3.2 Process Deployment, d. h. die Befolgung eines angepassten Standardprozesses. Für Level 4 sind die Attribute PA 4.1 Process Measurement und PA 4.2 Process Control Pflicht, d. h. quantitative Prozesskontrolle. Level 5 schließlich erfordert den Nachweis von PA 5.1 Process Innovation und PA 5.2 Continuous Optimization, d. h. kontinuierliche Prozessverbesserung. Abhängig von der Erfüllung der Prozessattribute wird bei einem solchen Assessment für jeden Prozess der individuelle Fähigkeitsgrad der Organisation festgelegt. SPICE definiert sechs Fähigkeitsgrade: >

Level 0: Incomplete: Keine Anforderungen (jede Organisation ist automatisch auf Level 0)

>

Level 1: Performed: Der Prozess existiert und erreicht seine spezifischen Ziele

>

Level 2: Managed: Level 1 und der Prozess wird geplant, kontrolliert und angepasst

>

Level 3: Established: Level 2 und der Prozess ist beschrieben und wird gemäß seiner Beschreibung durchgeführt

1.3 Stand der Technik

25

>

Level 4: Predictable: Level 3 und der Prozess wird innerhalb definierter Parameter durchgeführt

>

Level 5: Optimizing: Level 4 und der Prozess wird kontinuierlich verbessert, um relevante Geschäftsziele zu erreichen

Das Ergebnis eines SPICE-Assessments ist im Wesentlichen ein kammartiges Prozessprofil, ähnlich dem von CMMI in der Continuous Representation (siehe Abb. 1.5). Die Darstellung der Reife eines Unternehmens wie CMMI in der Staged Representation unterstützt SPICE nicht. BOOTSTRAP Europäische Antwort auf CMM

BOOTSTRAP /Koch 93/ ist ein im Rahmen eines ESPRIT-Projektes entwickeltes Verfahren. BOOTSTRAP wurde entwickelt, um einen Gegenpol zum Appraisal-Verfahren nach CMM (nicht CMMI) zu bilden, welches zum damaligen Zeitpunkt nur die Ermittlung eines globalen Reifegrads pro Organisation unterstützte. Mittlerweile ist BOOTSTRAP im Wesentlichen in ISO/IEC 15504 (SPICE) /ISO/IEC 15504 08/ aufgegangen. ITIL

Ein „königlicher Standard“

ITIL (IT Infrastructure Library) ist ein Quasi-Standard im Bereich der ITServices. ITIL wurde von der Central Computing and Telecommunications Agency (CCTA), mittlerweile umbenannt in Office of Government Commerce (OGC), einer Regierungsbehörde in Großbritannien, seit 1989 entwickelt. Seit 2007 existiert die dritte Version von ITIL (ITIL V3).

IT-Servicemanagement

ITIL V3 beschreibt in mehreren Büchern ein umfassendes IT-Servicemanagement, welches die Bereiche Planung, Erbringung und Unterstützung von IT-Serviceleistungen abdeckt. Im Kern beschreibt ITIL die Service Strategy (strategische Planung von Services) /OGC 08/, Service Design (Design und Entwicklung von Services und Service-Management-Prozessen) /OGC 07a/, Service Transition (Überführung neuer oder geänderter Services in den Betrieb) /OGC 07b/, Service Operation (Betrieb der Services) /OGC 07c/ und Continual Service Improvement (kontinuierliche Verbesserungen im Design, der Einführung und dem Betrieb von Services) /OGC 07d/.

Fokus auf Service-Erbringung, nicht Entwicklung

ITIL V3 unterscheidet sich dadurch von Ansätzen wie CMMI oder SPICE, die auf die Entwicklung von Systemen fokussiert sind. In ITIL V3 sind solche Systeme nur ein Baustein zur Erbringung von Services. CoBIT

IT-Governance

26

CoBIT (Control Objectives for Information and related Technology) stellt einen weit verbreiteten Controlling-Ansatz im Bereich IT-Governance dar. IT-Governance stellt sicher, dass die IT-Strukturen und -Prozesse ei-

1 Einführung

nes Unternehmens entsprechend der organisationsweiten Strategien und Zielsetzungen ausgerichtet sind (Business Alignment). CoBIT wurde ursprünglich durch die Information Systems Audit and Control Association (ISACA) entwickelt. Seit 2000 erfolgt die Weiterentwicklung durch das IT Governance Institute. Im Bereich der IT-Governance- und IT-Service-Domänen wurden spezielle Regelungen und Gesetze, wie der Sarbanes-Oxley Act (SOC) /Sarbanes-Oxley 02/ entwickelt. Die diesbezüglich vorgeschlagenen Lösungen (wie CoBIT) umfassen Modelle, die vordefinierte Ziele auf Messgrößen der IT-Infrastruktur abbilden. Diese Lösungen sind allerdings sehr spezifisch und lassen sich nur bedingt auf andere Domänen übertragen.

Sarbanes-Oxley Act (SOC)

Personal Software Process (PSP) Die Erreichung hoher Qualität in einer Organisation hängt entscheidend von der Leistung der Entwicklungsteams ab. Deren Leistung wiederum hängt von der Leistungsfähigkeit einzelner Teammitglieder ab. Schließlich hängt die Leistung einzelner Teammitglieder zu einem großen Teil von den einzelnen Praktiken ab, die diese anwenden. Es ist unbestreitbar, dass persönliche Eigenschaften wie Kommunikationsfähigkeiten, Erfahrung oder Intelligenz einen Einfluss auf die individuelle Leistung von Entwicklern haben. Allerdings konnte in Studien gezeigt werden, dass darüber hinaus die Qualität der Resultate einzelner Software-Entwickler durch die disziplinierte Anwendung persönlicher Praktiken messbar gesteigert werden kann und dass diese Verbesserungen sich in Verbesserungen der Teamleistung und letztlich in Verbesserungen der Projektergebnisse niederschlagen /Rombach et al. 08/. Der Personal Software Process (PSP) /Humphrey 08/ ist ein Verbesserungsansatz, der speziell auf die Verbesserung der Leistung einzelner Entwickler abzielt. Er ist organisiert als Prozess der Selbstoptimierung und in einzelne Übungen aufgeteilt. Der PSP unterstützt die Erhebung historischer Daten, um Entwickler in die Lage zu versetzen, Entwicklungsziele präziser zu definieren und besser einzuhalten. Die einzelnen Übungen des PSP sind ähnlich wie bei CMMI in Reifegradstufen eingeteilt, entlang derer sich das Trainingsprogramm aufbaut. Die Stufe PSP0 („Baseline Process“) umfasst insbesondere die Erfassung von Zeit- und Fehlerdaten sowie die Modellierung des angewandten Ist-Prozesses. In der Stufe PSP1 („Personal Planning Process“) werden Planungsaspekte wie Größenschätzung behandelt. Die Stufe PSP2 („Personal Quality Management“) umfasst Fehlererkennungstechniken. Die Stufe PSP3 („Cyclic Personal Process“) führt schließlich in die inkrementelle und zyklische Entwicklung ein. Die einzelnen Trainingseinheiten können durch weitere Übungen auf den Stufen PSP0.1, PSP1.1 und PSP2.1 ergänzt werden. Aufbauend auf dem PSP wurde ein sogenannter „Team Software Process“ (TSP) definiert, der die Selbstoptimierung von Entwicklungsteams unterstützt.

1.3 Stand der Technik

27

Abbildung 1.7 Ishikawa-Diagramm

1.3.1.3

Unterstützende Techniken

Ursache-Wirkungs-Diagramm (Fishbone Chart, Ishikawa-Diagramm) Ishikawa-Diagramme dienen zur Problemanalyse

Ursache-Wirkungs-Diagramme nach Ishikawa sind eine grafische Technik zur Analyse von Ursache-Wirkungs-Zusammenhängen (Abb. 1.7). Zu einem betrachteten Problem (Wirkung) werden die Hauptursachen identifiziert, die weiter in Nebenursachen usw. verfeinert werden. Das Verfahren ist von Ishikawa zur Anwendung in Qualitätszirkeln entwickelt worden (Ishikawa-Diagramm). Die Wirkung wird am Kopf der Fischgräte angetragen. An den Seitengräten werden die Hauptursachen notiert. Hilfreich ist die Verwendung der so genannten 6M-Methode. Es wird geprüft, ob Ursachen zu einer der folgenden Kategorien existieren: Mensch, Maschine, Methode, Material, Milieu, Messung. Ursachen höherer Ordnung werden an den Verzweigungen der Seitengräten angetragen. Hier hat sich die 6W-Methode bewährt: Was, Warum, Wie, Wer, Wann, Wo. Im Anschluss an die Sammlung möglicher Ursachen muss die tatsächliche Ursache identifiziert werden. Lösungsalternativen müssen bewertet werden, und die optimale Lösung muss gewählt und eingeführt werden. Pareto-Analyse

Durch die ParetoAnalyse bildet man Prioritäten

28

Das Pareto-Prinzip sagt aus, dass 20 % der Fehlerursachen 80 % der Fehlerwirkungen erzeugen. Die Pareto-Analyse wird mit einem Histogramm (Balkendiagramm) durchgeführt, das Teilmengen der Fehlerwirkungen nach fallender Bedeutung (z. B. Kosten, Schwere der Folgen) von links nach rechts geordnet darstellt. Zusätzlich kann eine Summenkurve der Balkenhöhen aufgetragen werden. In dem Beispiel nach Abb. 1.8 stellt

1 Einführung

Abbildung 1.8 Pareto-Diagramm

jeder Balken eine Fehlerart dar. Die Höhe des Balkens symbolisiert den zur Behebung der Fehler insgesamt erforderlichen Kostenaufwand. Das Pareto-Prinzip heißt hier „20 % der Fehler verursachen 80 % der Kosten“. Diese 20 % der Fehler wird man priorisiert vermeiden wollen. Sie sind das Ziel von Qualitätsverbesserungen. Korrelationsdiagramm Korrelationsdiagramme sind ein einfaches Instrument zur Analyse der Abhängigkeit zwischen zwei Merkmalen auf Basis einer Menge von Merkmalspaaren. Die statistische Basis bildet der Korrelationskoeffizient. Abb. 1.9 stellt als Beispiele mögliche Korrelationen zwischen der Anzahl der Software-Module und dem Entwicklungsaufwand sowie der Anzahl der Testfälle und der Anzahl der gemeldeten Fehler im ersten Jahr der Produktnutzung dar. Statistische Prozesskontrolle (Statistical Process Control, SPC) Statistische Prozesskontrolle (SPC) stammt aus dem Bereich der (mechanischen) Fertigung und gestattet die Unterscheidung zwischen zufälligen Streuungen von Prozesskennzahlen eines an sich stabilen Prozesses und systematischen Veränderungen des Prozesses /Braverman 81/, /Wheeler, Chambers 92/. Ein Beispiel für eine zufällige Streuung sind die Fertigungstoleranzen eines Frästeiles, während eine systematische Veränderung die langsame Drift des Maßes durch Werkzeugabnutzung sein kann und eine sprunghafte Veränderung durch Einspannen eines falschen Fräskopfes hervorgerufen wird.

SPC unterscheidet systematische und zufällige Effekte

SPC nutzt statistische Hilfsmittel und wird mit Hilfe so genannter Qualitätsregelkarten durchgeführt. Aus den Messwerten werden obere und

1.3 Stand der Technik

29

Abbildung 1.9 Korrelationsdiagramme

untere Schranken ermittelt, die zur Bewertung der in der Qualitätsregelkarte erfassten Messwerte dienen. Bei Messwerten oberhalb der oberen bzw. unterhalb der unteren Schranken wird ein systematischer Störeinfluss vermutet. Während sich der Ansatz im Produktionsbereich gut anwenden lässt, sind die Anwendungsmöglichkeiten in der Entwicklung beschränkt. Dies hängt mit den Spezifika der Software- und Systementwicklung zusammen (u.a. kreative, menschbasierte Prozesse). Quality Function Deployment (QFD) Quality Function Deployment dient zur Priorisierung der Anforderungen

Quality Function Deployment /Cohen 95/ ist eine Technik zur Erfassung und Gewichtung von Kundenanforderungen. Sie dient zur vollständigen Erhebung der Kundenanforderungen und zu ihrer Gewichtung entsprechend ihrer Bedeutung für den Kundennutzen und den Geschäftserfolg. Ferner können die Anforderungen durch den Entwicklungsprozess verfolgt werden. Daher ist transparent, welche Aktivitäten mit welchen Kundenanforderungen in Beziehung stehen. Dies ermöglicht es, Ressourcen im Falle von Engpässen zur Realisierung wichtiger Anforderungen zu verwenden. QFD realisiert damit eine starke Kundenorientierung, da im Grunde alle Entscheidungen bei der Entwicklung auf Kundenanforderungen zurückgeführt werden können.

1.3.2

Software-Qualitätssicherung

Software-Qualitätssicherung stellt Techniken zur Erreichung der gewünschten Ausprägungsgrade der Qualitätsmerkmale von Software-Systemen zur Verfügung. Software-Qualitätssicherung und Hardware-Qualitätssicherung besitzen zum Teil Gemeinsamkeiten. Sie entwickeln sich aber seit mehreren Jahrzehnten relativ getrennt voneinander. Software-Qualität und Qualität generell werden – wie bereits erläutert – in mehrere Qualitätsmerkmale verfeinert (z. B. Zuverlässigkeit, Speicher- und Laufzeiteffizienz, Änderbarkeit, ...). Software dringt zunehmend in kritische Anwendungsbereiche ein, z. B. Medizintechnik und Verkehrstechnik. Gleichzeitig steigen der Umfang und die Komplexität von SoftwareSystemen erheblich an, was ein Gefahrenpotential aufgrund der Schwie-

30

1 Einführung

rigkeit erzeugt, diese Systeme zu beherrschen. Es gibt bereits Berichte über zahlreiche Fehlverhalten von Systemen unter Software-Beteiligung (siehe auch /Leveson 95/). In den USA und Kanada hat ein softwarebedingtes Fehlverhalten des Bestrahlungsgeräts THERAC 25 mehrere Todesopfer gefordert /CACM 90/, /Leveson, Turner 93/. Von einer frühen Version des Verkehrsflugzeuges B737 wird berichtet, dass der Vortriebsregler manchmal während des Starts bei genau 60 Knoten ausfiel /Hohlfeld 88/. Die Ursache des Fehlverhaltens war ein Programmierfehler, da keine steuernden Anweisungen für eine Geschwindigkeit von exakt 60 Knoten vorhanden waren. Auch heute können Fehler nicht sicher ausgeschlossen werden. Der Absturz der europäischen Trägerrakete Ariane 5 auf ihrem ersten Erprobungsflug ist durch Software-Komponenten verursacht worden, die für die Ariane 4 realisiert wurden und deren Zusammenwirkung mit der neuen Umgebung der Ariane 5 nicht ausreichend geprüft worden ist /Lions 96/. Der Jungfernflug der neuen europäischen Trägerrakete Ariane 5 der ESA fand am 4. Juni 1996 in Kourou statt. Die Rakete war mit vier Cluster-Satelliten bestückt. Etwa 37 Sekunden nach Zünden der Rakete erreichte die Ariane 5 eine Horizontalgeschwindigkeit von mehr als 32768 internen Einheiten. Die in ADA realisierte Konvertierung dieses Wertes in eine vorzeichenbehaftete Integer-Variable führte daher zu einem Überlauf, der nicht abgefangen wurde. Es war Hardware-Redundanz vorhanden. Da es sich hier um ein Software-Problem handelte, blieb diese jedoch wirkungslos. Als Konsequenz wurden Diagnosedaten zum Hauptrechner geschickt, die dieser als Flugbahndaten interpretierte. Es wurden unsinnige Steuerbefehle gegeben. Die Rakete drohte auseinander zu brechen und sprengte sich selbst. Die Software war von der Ariane 4 wiederverwendet worden und hatte dort problemlos funktioniert. Diese Beispiele belegen, dass die Ursachen von Fehlverhalten in Systemen sehr vielfältig sein können. Die Beobachtung, dass Software-Systeme in der täglichen Benutzung meistens zufriedenstellend funktionieren, könnte Anlass zu der Vermutung geben, dass es sich bei den angeführten Ausfällen um Ausnahmen handelt. Einerseits ist dies ist in Bezug auf die Schwere der Auswirkungen glücklicherweise korrekt. Andererseits zeigen empirische Daten, dass Software-Fehler nicht die Ausnahme sondern der Regelfall sind. Eine amerikanische Untersuchung /Musa et al. 87, S. 118/, die sich auf etwa 130 Projekte stützt, kommt zu dem Ergebnis, dass die durchschnittliche Software zu Beginn des Modultests rund 19,7 Fehler pro Tausend Quellcodezeilen des Programmtextes enthält. Zu Beginn des Systemtests verbleiben etwa sechs Fehler pro Tausend Quellcodezeilen in dem Produkt. Freigegeben werden Software-Produkte nach dieser Untersuchung mit rund 1,5 Fehlern pro Tausend Quellcodezeilen. Auf den ersten Blick scheint das ein niedriger Wert zu sein. Verdeutlicht man sich aber, dass umfangreiche Software heute oft einige Millionen Quellcodezeile Umfang besitzt, so bedeutet das, dass derartige Produkte unter Umständen Tausende von Fehlern enthalten können. Von Jones /Jones 91, S.

1.3 Stand der Technik

Fehlverhalten unter Software-Beteiligung

Empirische Daten zu Software-Fehlern und ihrer Abhängigkeit von Software-Maßen sind in /Fenton, Ohlsson 00/ enthalten.

31

142 - 143/ veröffentlichte Daten zeigen einen deutlichen relativen Anstieg des Aufwands für die analytische Qualitätssicherung in Abhängigkeit des Gesamtentwicklungsaufwands eines Projektes (Abb. 1.10). Die Codierung von Software stellt nach diesen Daten bei sehr kleinen Projekten den größten Aufwandsanteil dar. Bei dem größten in /Jones 91/ aufgeführten Projekt erfordert die analytische Qualitätssicherung 37 % des gesamten Entwicklungsaufwands, während die Codierung nur noch 12 % benötigt. Eine bekannte Untersuchung von Boehm /Boehm 81, S. 534/ kommt zu dem Ergebnis, dass das Verhältnis zwischen dem Wartungsaufwand und dem Entwicklungsaufwand bei Software-Projekten zwischen 2 : 1 und 1 : 1 liegt. Da Wartung im Wesentlichen auf die Beseitigung jener Fehler zielt, die bis zur Freigabe eines Produktes nicht gefunden wurden, ist es durchaus sinnvoll, den Wartungsaufwand der analytischen Qualitätssicherung zuzurechnen. Betrachtet man all diese Daten gemeinsam, so ist klar zu erkennen, dass in vielen Fällen Qualitätssicherung den größten Teil des Entwicklungsaufwands verschlingt. Andererseits werden aber oft keine befriedigenden Ergebnisse erzielt. In der Praxis führt das zu der unbefriedigenden Situation eines erheblichen Fehlleistungsaufwands. Es ist erkennbar, dass einzelne Techniken keine umfassende Lösung der existierenden Probleme bieten können. Eine gleichzeitige Befriedigung technischer und wirtschaftlicher Ziele in einem industriellen Kontext ist nur durch eine sinnvolle Kombination mehrerer Techniken und Methoden erreichbar. Eine frühzeitige Qualitätssicherung ist insbesondere unter Kostengesichtspunkten wichtig. In einer Untersuchung von Möller /Möller 96/ sind Daten zu Fehlerkosten publiziert, die für Fehlerkorrekturen in den Phasen Analyse, Entwurf und Codierung Korrekturkosten in Höhe von 250 e ausweisen (Abb. 1.11). Beim Entwicklertest (Modultest) ist mit Korrekturkosten von 1000 e zu rechnen. Die Korrektur eines Fehlers, der beim Systemtest gefunden wird, kostet rund 3000 e. Fehler, die während der Produktnutzung erkannt werden, verursachen im Mittel Korrekturkosten von 12500 e. Dieser nahezu exponentielle Anstieg der Korrekturkosten erfordert aus wirtschaftlichen Gründen eine frühzeitige Qualitätssicherung. Spillner und Liggesmeyer /Spillner, Liggesmeyer 94/ haben Daten zur Nutzung von Software-Qualitätssicherungstechniken in der Praxis publiziert, die zeigen, dass die Techniken Reviews und dynamisches Testen in der Praxis eine starke Verbreitung besitzen, während formale Techniken nur in geringem Umfang genutzt werden (Abb. 1.12). Insgesamt existiert zwischen dem Wissen über Software-Qualität in der Theorie und der Nutzung einschlägiger Techniken in der Praxis eine erhebliche Diskrepanz.

1.3.3

Hardware-Qualitätssicherung

Qualitätssicherungstechniken für Hardware-Komponenten und -Systeme sind seit längerem bekannt und besitzen eine große Verbreitung in der

32

1 Einführung

100

Management

11

18

5 Dokumente

33 68 50

Codierung

12

% 37

81920

30118

8192

2994

405

55

149

20

1099

Aufwand (MM)

8,1

4,4

1,5

0,9

0

1,6

Analytische Qualitätssicherung

16

Abbildung 1.10 Relative Anteile am Entwicklungsaufwand

Abbildung 1.11 Fehleranzahlen und Fehlerkorrekturkosten

Praxis. Sie werden auf Komponenten, Systeme und Fertigungsprozesse angewandt. Die Techniken basieren häufig auf statistischen Verfahren. Wichtige Teilgebiete sind die statistische Prozesskontrolle, die Lebensdauerversuche und die Prüfplanung. Die Techniken Failure Mode and Effects Analysis (FMEA) bzw. Failure Mode, Effects and Criticality Analysis (FMECA), Zuverlässigkeitsblockdiagramm , Fehlerbaumanalyse und Markov-Analyse sind ursprünglich für die Analyse von Hardware konzipiert worden. Sie erfassen Ursache-Wirkungs-Zusammenhänge und sind daher in der Lage, die Auswirkungen von Komponenteneigenschaften auf Qualitätseigenschaften des Systems zu beschreiben. So unterscheidet man z. B. bei der FMECA die Komponenten-, System- und Prozess-FMECA. Insbesondere die Analyse von Systemen mit Zuverlässigkeitsblockdiagrammen, Fehlerbäumen und Markov-Analysen profitiert von statis-

1.3 Stand der Technik

33

Abbildung 1.12 Nutzung von QS-Techniken in der Praxis

Literatur zu SPC

tischen Analysen der beteiligten Komponenten, da z. B. für eine quantitative Auswertung auf dem Systemniveau eine Quantifizierung von Eigenschaften der Komponenten erforderlich ist. Grundsätzlich gehören auch Techniken zur Materialprüfung zu den Qualitätssicherungstechniken. Beispiele sind Zerreißproben, Ultraschall- und Röntgenprüfverfahren. Sie werden hier jedoch nicht weiter betrachtet. Zur statistischen Prozesskontrolle existiert umfangreiche Literatur (z. B. /Braverman 81/, /Roetzel 90/, /Wheeler, Chambers 92/). Die Auswertung von Lebensdauerversuchen wird in Kapitel 14 diskutiert. Lebensdauerversuche dienen zur Ermittlung von statistisch abgesicherten Zuverlässigkeitskennwerten. Da die Durchführung von Lebensdauerversuchen bei Komponenten oder Systemen mit langen Lebensdauern zu viel Zeit beanspruchen würde, beschleunigt man Lebensdauerversuche in der Praxis /Tobias, Trindade 95/. Bei Halbleitern ist das z. B. durch Betreiben bei erhöhten Umgebungstemperaturen möglich. Die so erzielten Ergebnisse müssen auf die normalen Umgebungsbedingungen umgerechnet werden. Die Techniken FMECA, Zuverlässigkeitsblockdiagramm, Fehlerbaumanalyse und Markov-Analyse werden in Abschnitt 14.4 erläutert.

Ziel: Stichprobenprüfung anstelle der Prüfung jeden Exemplars

34

Die Prüfplangenerierung ist ein mit der statistischen Prozesskontrolle verwandtes Gebiet, das insbesondere im Bereich der Eingangsprüfung Anwendung findet. Die statistischen Grundlagen der Prüfplanung und der Prüfplangenerierung sind seit langem bekannt. Zielsetzung ist, bei der Überwachung eines Fertigungsprozesses oder der Eingangskontrolle von zugelieferten Komponenten die aufwendige Prüfung jedes einzelnen Exemplars zu vermeiden. Dieses so genannte Sortieren soll so durch ein Stichprobenverfahren ersetzt werden, dass die folgenden Forderungen erfüllt werden: Eine festgelegte Wahrscheinlichkeit darf nicht überschritten werden, ein Los zu akzeptieren, das mehr als eine bestimmte Anzahl

1 Einführung

fehlerhafter Teile enthält. Außerdem soll eine vorgegebene Wahrscheinlichkeit nicht überschritten werden, ein Los abzulehnen, das weniger als eine vorgegebene Anzahl defekter Teile enthält. Ein Prüfplan definiert eine Regel dafür, welche Stichprobe (Umfang, Art des Ziehens) aus einem Los einer bestimmten Größe gezogen werden muss und bei welchen Versuchsausgängen das Los abzulehnen oder zu akzeptieren ist. Es gibt einfache und mehrstufige Prüfpläne. Bei mehrstufigen Prüfplänen können z. B. Regeln existieren, die abhängig vom Ausgang der Stichprobenauswertung zusätzliche Stichproben vorsehen. Darüber hinaus ist es auch möglich, in Abhängigkeit der Auswertung einer oder mehrerer Stichproben den Prüfplan zu wechseln. Das bedeutet, dass z. B. bei einer Häufung schlechter Lose ein verschärfter Prüfplan in Kraft treten kann, der bei Auftreten einer Serie guter Lose wieder außer Kraft gesetzt wird. Ebenso ist es möglich, einen Prüfplan bei einer Serie guter Lose abzuschwächen, um bei einer Serie schlechter Lose wieder in den normalen Prüfplan überzuwechseln. Ziel dieser Vorgehensweise ist die Reduzierung des Prüfaufwands unter Beibehaltung der Ergebnisqualität.

1.3.4

Qualitätssicherung softwareintensiver Systeme

Es existieren nur wenige Techniken, die auf hybride Systeme aus mechanischen und elektronischen Komponenten mit Software-Beteiligung anwendbar sind. Dies gilt insbesondere bei Systemen, die sicherheitskritisch sind, für die quantifizierte Zuverlässigkeitsaussagen gefordert sind oder die Echtzeiteigenschaften besitzen. Die FMECA /IEC 60812 06/ ist eine Technik, die für mechanische und elektronische Komponenten und Systeme eine hohe Verbreitung in der Praxis besitzt. Sie kann eingeschränkt zur Sicherheitsanalyse und für Zuverlässigkeitsbetrachtungen verwendet werden, liefert aber z. B. keine echten quantifizierten Zuverlässigkeitskennwerte. Analysen von Echtzeiteigenschaften sind nicht direkt Gegenstand der FMECA. Die FMECA setzt voraus, dass die Ausfallmodi der betrachteten Komponenten bekannt sind oder mindestens begründete Annahmen gemacht werden können. Bei der Analyse von Hardware ist das möglich. Bei mechanischen Systemen kann das z. B. der Bruch einer Achse sein. Bei elektronischen Komponenten ist der Kurzschluss eines Bauteils ein Beispiel. Es ist schwierig, für Software ähnlich sinnvolle Annahmen zu machen, da die Art der Ausfälle anders beschaffen ist. Die FMECA ist daher für die Software-Bestandteile von Systemen anzupassen (siehe z. B. /Mäckel 01/). Die Analyse von Ausfallmechanismen innerhalb eines Software-Moduls ist kaum möglich. Die Untersuchung der Ausfallfortpflanzung in einer Software-Architektur ist möglich, da aufgrund des SystemEntwurfs die Schnittstellen der Software-Komponenten bekannt sind. Die Fehlermodi einer Komponente sind durch die unterschiedlichen ausgangsseitigen Fehlermöglichkeiten gegeben. Das Ziel der FMECA ist die Untersuchung, welche Wirkungen diese Fehlverhalten auslösen. Das entspricht einer System-FMECA eines Software-Sub-

1.3 Stand der Technik

Für die Prüfung von Hardware-/SoftwareSystemen existieren nur wenige Techniken. FMECA = Failure Mode, Effects and Criticality Analysis

35

systems, die als Bestandteil der System-FMECA des hybriden Systems genutzt werden kann. Zuverlässigkeitsblockdiagramme /IEC 61078 06/ gestatten die Berechnung von Zuverlässigkeitskennwerten eines Systems aus den Zuverlässigkeiten der Komponenten und ihren Wirkzusammenhängen, die bei Hardware oft aus der Systemarchitektur abgeleitet werden können. Da die Wirkzusammenhänge bei Software oft kompliziert sind, ist die Anwendbarkeit auf Software gering. Außerdem verfügt Software im Allgemeinen über vielfältige Ausfallmechanismen, die unterschiedliche Wirkungen besitzen. Derartige Eigenschaften können in Zuverlässigkeitsblockdiagrammen nicht berücksichtigt werden. Zuverlässigkeitsblockdiagramme können zur Analyse der Zuverlässigkeit eines Systems aus Hardware- und Software-Komponenten verwendet werden, falls die Software bei der Analyse nicht in ihre Komponenten aufgelöst wird. Über Sicherheits- und Echtzeiteigenschaften machen Zuverlässigkeitsblockdiagramme keine Aussage. Fehlerbäume /IEC 61025 06/ sind eine zur Sicherheits- und Zuverlässigkeitsanalyse von Hardware-Systemen verbreitete Technik. Es gibt Vorschläge, diese Technik zur Analyse von Software zu verwenden /Leveson, Shimeall 91/. Fehlerbäume sind gleichzeitig formal und anschaulich. Sie gestatten die Ermittlung quantifizierter Zuverlässigkeitskennwerte. Markov-Modelle /IEC 61165 06/ sind eine zur Zuverlässigkeits- und Leistungsanalyse von Systemen verbreitete Technik. Ihre Anwendung auf umfangreiche Systeme ist kritisch, da Zustandsautomaten bei einer großen Anzahl von Zustandsvariablen oft aufgrund ihres Umfangs nicht mehr handhabbar sind. Es gibt Ansätze, Markov-Modelle auch für Software zu verwenden. Dynamisches Testen ist auf hybride Systeme anwendbar

36

In der Software-Entwicklung werden verbreitet dynamische Testtechniken eingesetzt. Diese sind auch auf hybride Systeme anwendbar. Sie können Einflüsse der Betriebsumgebung berücksichtigen. Das ist insbesondere bei harten Echtzeitanforderungen wichtig. Man verwendet z. B. spezielle Testsysteme; so genannte Hardware-in-the-Loop-Systeme. Aussagen zur Zuverlässigkeit sind durch dynamisches Testen nur mit Hilfe von stochastischen Verfahren möglich. Zuverlässigkeitsanalysen mit Hilfe dynamischer Tests sind bei hochzuverlässigen Systemen nicht möglich, falls Ausfallereignisse für eine statistische Auswertung zu selten auftreten. Sicherheitsanalysen können durch dynamisches Testen kaum erbracht werden. Statistische Analysen des Ausfallverhaltens sind bei Hardware-Systemen verbreitet /Tobias, Trindade 95/. Auch für Software existieren zahlreiche Ansätze (siehe z. B. /Lyu 95/). Offene Fragen existieren im Bereich der Analyse von hybriden Systemen sowie in Bezug auf die praktische Anwendung der umfangreichen Theorie. Formale Techniken zur Spezifikation und Verifikation sind für Hardware und Software bekannt. Eine breite Anwendung in der Praxis finden diese Ansätze jedoch noch nicht. Es gibt auch formale Techniken für die Verifikation hybrider Systeme. Es wird oft angenommen, dass die Hardware-Komponenten des betrachteten Systems ausfallfrei funktionieren. Diese Annahme ist für Sicherheits- und Zuverlässigkeitsanalysen nicht akzeptabel.

1 Einführung

1.4

Einordnung und Klassifikation der Prüftechniken

In /Liggesmeyer 90/ wird ein Klassifikationsschema für Software-Prüftechniken vorgeschlagen. In Abb. 1.13 ist eine aktualisierte Fassung dieses Vorschlags dargestellt. Das aktuelle Klassifikationschema sieht zwei Klassen – die statischen und die dynamischen Techniken – vor. Symbolische Testtechniken und formale Beweisverfahren, die in /Liggesmeyer 90/ eigene Klassen bilden, sind nun zu verifizierenden Techniken als Unterklasse der statischen Techniken zusammengefasst. Tatsächlich sind alle verifizierenden Techniken, mit Ausnahme des so genannten erschöpfenden Tests, statische Ansätze. Der erschöpfende Test bezeichnet die Prüfung einer Software mit allen möglichen Eingaben in allen denkbaren Betriebssituationen. Er besitzt keine praktische Bedeutung und ist aus diesem Grunde in Abb. 1.13 nicht aufgeführt. Außerdem sind im Vergleich zu dem Klassifikationsschema aus /Liggesmeyer 90/ einige Techniken hinzugefügt worden. Die dynamischen Testtechniken besitzen eine hohe praktische Bedeutung. Dies gilt jedoch nicht gleichermaßen für jede der in Abb. 1.13 aufgeführten Testtechniken. Besonders wichtig sind die funktionsorientierten und einige kontrollflussorientierte Testtechniken. In der Klasse der diversifizierenden Techniken besitzt insbesondere der Regressionstest eine hohe praktische Relevanz. Einige der in diesem Buch vorgestellten Techniken sind in Abb. 1.13 nicht aufgeführt. Es handelt sich insbesondere Techniken zur Modellierung von Sicherheit und Zuverlässigkeit sowie um stochastische Analyseverfahren. Bei diesen Techniken handelt es sich nicht um Prüftechniken im engeren Sinne. Sie dienen zur Modellierung von Eigenschaften bzw. zur stochastischen Auswertung von Beobachtungen. Ein Beispiel für eine Technik zur Sicherheits- bzw. Zuverlässigkeits-Modellierung ist die Fehlerbaumanalyse. Eine Fehlerbaumanalyse modelliert ein definiertes Fehlverhalten einer Betrachtungseinheit. Dieses Modell kann anschließend ausgewertet werden. Modellierungstechniken können Probleme identifizieren, bevor ein System realisiert wird. Die Techniken können präventiv eingesetzt werden. Die Qualität der Ergebnisse wird entscheidend von der Qualität des Modells beeinflusst. Die Erstellung eines präzisen Modells ist gegebenenfalls aufwendig. Stochastische Zuverlässigkeitsanalysetechniken können z. B. zur statistisch seriösen Auswertung eines statistischen Tests dienen. Es können z. B. Ausfallraten ermittelt und prognostiziert werden. Stochastische Analysen erfordern keine aufwändige Modellerstellung. Darüber hinaus liefern sie verlässliche Ergebnisse, da sie auf echten Messungen basieren. Nachteilig ist, dass das System soweit aufgebaut sein muss, dass Messungen möglich sind. Werden hier gravierende Probleme erkannt, so sind gegebenenfalls nennenswerte Modifikationen des Systems erforderlich. Die Techniken zur Modellierung von Sicherheit und Zuverlässigkeit und die stochastischen Analyseverfahren

1.4 Einordnung und Klassifikation der Prüftechniken

Grobe Klassifikation der Prüftechniken

Vorteile und Nachteile modellierender bzw. messender Techniken

37

Mein Klassifikationsschema für Prüftechniken

Abbildung 1.13 Klassifikation der Software-Prüftechniken

38

1 Einführung

sind insbesondere für die Qualitätssicherung eingebetteter Software bzw. softwareintensiver Systeme wichtig.

1.4.1

Dynamischer Test

Die einfachste Form des dynamischen Tests ist die Ausführung der zu testenden Software mit Eingaben, die eine testende Person unmittelbar und üblicherweise nicht reproduzierbar erzeugt. Das ist – im Gegensatz zu den im Folgenden dargestellten Techniken – ein unsystematischer ad hoc-Ansatz. Die dynamischen Testtechniken liefern leider aufgrund ihres Stichprobencharakters nur unvollständige Aussagen über die getestete Software. Dijkstra hat diesen Sachverhalt in der Aussage zusammengefasst, dass Testen die Anwesenheit von Fehlern demonstrieren könne, nicht jedoch deren Abwesenheit. Aufgrund seiner universellen Anwendbarkeit besitzt der dynamische Test allerdings eine enorme praktische Bedeutung.

Merkmale der dynamischen Testtechniken

Alle dynamischen Testtechniken besitzen die folgenden gemeinsamen Merkmale: >

Die übersetzte, ausführbare Software wird mit konkreten Eingabewerten versehen und ausgeführt.

>

Es kann in der realen Betriebsumgebung getestet werden.

>

Dynamische Testtechniken sind Stichprobenverfahren.

>

Dynamische Testtechniken können die Korrektheit der getesteten Software nicht beweisen.

Allein die dynamischen Testverfahren verlangen die Ausführung einer Software mit konkreten Eingaben – den Testdaten. Da nicht alle möglichen Situationen getestet werden können, sind alle praktisch relevanten dynamischen Testtechniken Stichprobenverfahren. Der Wunsch mit einem Stichprobenverfahren möglichst sinnvoll zu prüfen, hat zur Entstehung einer Vielzahl von dynamischen Testtechniken geführt. Eine Aussage über die korrekte oder unkorrekte Funktion der Software ist im Grunde ausschließlich für die gewählten Testdaten sicher möglich. Es ist eine akzeptable Stellvertreterregelung notwendig, um aus der korrekten Verarbeitung eines Testfalls die korrekte Verarbeitung weiterer nicht getesteter Fälle schließen zu können. Die korrekte Funktion der Software für alle Eingaben kann nur durch Test aller möglichen Eingaben sichergestellt werden. Dieser vollständige Test aller Eingaben wird als erschöpfend bezeichnet. Die Durchführung eines erschöpfenden Tests ist für reale Programme in der Regel nicht möglich. Das Ziel der dynamischen Testtechniken ist die Erzeugung von Testfällen, die >

Dynamisches Testen kann Restfehler nicht ausschließen.

repräsentativ,

1.4 Einordnung und Klassifikation der Prüftechniken

39

White Box-Tests vs. Black Box-Tests

Einordnung nach der verwendeten Testreferenz

Funktionsorientierter Test = Black Box-Test

>

fehlersensitiv,

>

redundanzarm und

>

ökonomisch sind.

Dynamische Testtechniken definieren unterschiedliche Regeln für die Bildung und Beurteilung der Testfälle. Testtechniken können nach unterschiedlichen Kriterien klassifiziert, beurteilt und miteinander verglichen werden. Weit verbreitet ist die Unterscheidung von White Box-Tests und Black Box-Tests. White Box-Techniken nutzen im Gegensatz zu Black Box-Techniken die Struktur des Programmcodes. Die Unterteilung der Testtechniken in White Box- und Black Box-Techniken muss als zu grob nach dem heutigen Stand des Wissens betrachtet werden. Testtechniken, die im Grunde stark unterschiedlich sind, werden nach diesem Kriterium einer Klasse zugeordnet. Eine andere Klassifikationsmöglichkeit ist die Einordnung nach der verwendeten Testreferenz. Testtechniken werden einer Klasse zugeordnet, wenn sie identische Testreferenzen verwenden. Ein Testtechniken testet gegen die Testreferenz. Die Testreferenz wird verwendet, um die Testvollständigkeit und bzw. oder die Korrektheit der Testergebnisse zu beurteilen. Die strukturorientierten Testtechniken bewerten die Testvollständigkeit anhand der Abdeckung der Strukturelemente des Programmcode. Es können z. B. Anweisungen, Zweige oder Datenzugriffe verwendet werden. Alle strukturorientierten Testtechniken sind folglich White Box-Tests. Die Korrektheit der Ergebnisse wird anhand der Spezifikation beurteilt. Abb. 1.14 stellt das Prinzip der strukturorientierten Testtechniken dar. Die funktionsorientierten Testtechniken bewerten die Testvollständigkeit und die Korrektheit der Testergebnisse anhand der Spezifikation. Das Prinzip ist in Abb. 1.15 dargestellt. Funktionsorientierte Testtechniken sind Black Box-Techniken, aber nicht alle Black Box-Testtechniken sind funktionsorientiert. Funktionsorientiertes Testen und Black Box-Testen sind keine Synonyme. Der Back to Back-Test ist z. B. eine Black Box-Technik, die nicht funktionsorientiert testet.

Diversifizierender Test

Die diversifizierenden Testtechniken bewerten die Korrektheit der Testergebnisse durch Vergleich der Ergebnisse mehrere Versionen der zu testenden Software. Die Bewertung der Testvollständigkeit geschieht je nach Technik anhand unterschiedlicher Kriterien.

Basis-Testtechniken vs. höhere Testtechniken

Schließlich können die Testtechniken in die Klassen Basis-Testtechniken und höhere Testtechniken aufgeteilt werden. Basistesttechniken können nicht sinnvoll in eigenständige untergeordnete Testtechniken zerlegt werden. Höhere Testtechniken bestehen aus mehreren Basistesttechniken. Sie tragen eine eigene Bezeichnung und wirken bei oberflächlicher Betrachtung häufig wie eine eigenständige Basis-Testtechnik. Der Pfadbereichstest ist ein Beispiel für eine höhere Testtechnik. Der Zweigüberdeckungstest ist eine Basis-Testtechnik. Die Einordnung der dynamischen Tests nach Abb. 1.13 basiert im Wesentlichen auf dem Kriterium der Testreferenz. Innerhalb der strukturorien-

40

1 Einführung

Abbildung 1.14 Prinzip des strukturorientierten Tests

Spezifikation Testfälle

Vollständigkeit

Bild der Spezifikation

Software

Reaktionen beurteilen Tester

Abbildung 1.15 Prinzip des funktionsorientierten Tests

tierten Testtechniken werden die Unterklassen kontrollflussorientierter Test und datenflussorientierter Test gebildet. Die kontrollflussorientierten Testtechniken zielen auf die Abdeckung von Kontrollstrukturelementen der zu testenden Software. Zu dieser Klasse gehören so bekannte Testtechniken wie der Anweisungsüberdeckungstest, der Zweigüberdeckungstest und der Pfadüberdeckungstest. Die datenflussorientierten Testtechniken definieren Regeln für die vollständige Abdeckung der Datenzugriffe in der zu testenden Software. Schreibende und lesende Datenzugriffe müssen je nach verwendeter Technik auf bestimmte Weise ge-

1.4 Einordnung und Klassifikation der Prüftechniken

Strukturorientierter Test: Vollständige Abdeckung der Struktur, aber keine garantierte Abdeckung der Spezifikation. Das Fehlen von Programmcode wird nur zufällig erkannt.

41

Funktionsorientierter Test: Vollständige Abdeckung der Spezifikation und aussagefähige Testfälle, aber keine garantierte Vollständigkeit der Abdeckung der Programmstruktur.

testet werden. Die funktionsorientierten Testtechniken legen Regeln für die Umsetzung der Spezifikation in Testfälle fest. Diversifizierende Testtechniken testen mehrere Versionen der zu testenden Software gegeneinander. Diese diversitären Versionen können durch eine Mehrfachrealisierung entstanden sein, sie können aus einer Ursprungsversion auf definierte Weise erzeugt worden oder in einer Versionsentwicklung zeitlich nacheinander entstanden sein. Bei den dynamischen Techniken sind in Abb. 1.13 im Vergleich zu dem Klassifikationsschema aus /Liggesmeyer 90/ nur geringfügige Ergänzungen vorgenommen worden. Es sind insbesondere einige Techniken hinzugefügt worden. Die im Klassifikationsschema aufgeführten funktionsorientierten Techniken stellen nur eine Auswahl dar. Die Beschränkung auf die hier vorgestellten Techniken erfolgt, weil diese Techniken einen zufriedenstellenden funktionsorientierten Test fast jeder Software ermöglichen. Sie stellen einen minimalen Technikenvorrat für funktionsorientiertes Testen dar. Die funktionale Äquivalenzklassenbildung ist geeignet, falls gedächtnislose Software zu prüfen ist und für die Eingaben und Ausgaben eine Fallunterscheidung durchgeführt werden kann. Ist diese Fallunterscheidung nicht möglich, weil die zu unterscheidenden Fälle nicht unabhängig sind, so bietet sich die Ursache-Wirkungs-Analyse an. Bei gedächtnisbehafteter Software – also Software, deren Reaktionen nicht allein von den Eingaben sondern auch vom Zustand bestimmt wird – ist in der Regel der zustandsbasierte Test sinnvoll. Voraussetzung ist eine zustandsorientiert verfasste Spezifikation (z. B. als Zustandsautomat oder als Zustandsübergangstabelle). Der Syntaxtest ist ein spezialisiertes Verfahren, das für den funktionsorientierten Test von Software verwendet werden kann, die eine lexikalische oder syntaktische Analyse durchführt (z. B. Kommandointerpreter, Scanner, Parser). Es muss eine Syntaxbeschreibung in Backus-Naur-Form oder als Syntaxgraph vorliegen. In Tab. 1.1 sind für einige ausgewählte funktionsorientierte Testtechniken die Anwendungsbereiche und Voraussetzungen dargestellt. Die diversifizierenden, dynamischen Techniken sind um den Regressionstest erweitert worden. Diese Technik ist diversifizierend, weil sie zeitlich aufeinanderfolgende Versionen eines Systems oder von System-

Tabelle 1.1 Funktionsorientierte Testtechniken

42

1 Einführung

komponenten gegeneinander testet. Die aktuelle Version wird mit den während des Tests der Vorgängerversion aufgezeichneten Testfällen versorgt. Die durch die aktuelle Version erzeugten Reaktionen werden mit den durch die Vorgängerversion erzeugten und ebenfalls aufgezeichneten Ausgaben verglichen. Jede nicht gewünschte Abweichung ist ein Fehlverhalten, das auf einen Software-Fehler hinweist. Von besonderer praktischer Bedeutung ist die Identifikation von Minimalanforderungen an dynamisches Testen. Gerade im Hinblick auf die Vielzahl der Testtechniken soll dem Praktiker eine Hilfe zur Identifikation von Minimalanforderungen gegeben werden. Von zahlreichen Standards wird eine systematische funktionsorientierte Testplanung in allen Testphasen gefordert. Darüber hinaus besteht ein breiter Konsens bezüglich der Einordnung des Zweigüberdeckungstests als minimale Testtechnik für den strukturorientierten Modultest. Andererseits existieren erhebliche Zweifel an der Leistungsfähigkeit. Der Zweigüberdeckungstest ist notwendig, nicht jedoch hinreichend.

Minimalanforderungen an dynamische Tests

„It is generally agreed that, at a minimum, this subset (of paths) should require that every branch, and thus every statement, in a program be executed at least once.“ /Clarke et al. 85/ „Branch testing asks that each transfer of control (branch) in the program is exercised by at least one test case and is usually considered to be a minimal testing requirement.“ /Ntafos 88/ „The minimum criteria are: (1) test every branch ... of the program, and test every statement at least once.“ /Sorkowitz 79/ Insbesondere in Versionsentwicklungen muss auf die Wiederholbarkeit von Testfällen geachtet werden. Ein systematischer Regressionstest gilt in diesem Fall als notwendig.

1.4.2

Statische Analyse

Alle statischen Analysen besitzen die folgenden gemeinsamen Merkmale: >

Es erfolgt keine Ausführung der zu prüfenden Software.

>

Alle statischen Analysen können prinzipiell ohne Computerunterstützung durchgeführt werden.

>

Es werden keine Testfälle gewählt.

>

Vollständige Aussagen über die Korrektheit oder Zuverlässigkeit können nicht erzeugt werden.

Merkmale der statischen Analyse

Ungeachtet der manuellen Durchführbarkeit statischer Analysen ist eine Werkzeugunterstützung sinnvoll und sollte mit Ausnahme der Inspektions- und Review-Techniken in jedem Fall genutzt werden. Bei den sta-

1.4 Einordnung und Klassifikation der Prüftechniken

43

tisch analysierenden Techniken werden in Abb. 1.13 die Software-Messung, Stilanalyse, Grafiken und Tabellen, Slicing, Datenflussanomalieanalyse und die manuellen Prüfungen Inspektions- und Review-Techniken unterschieden. Die Verwendung von Maßen ermöglicht eine quantitative Steuerung der Software-Entwicklung und ermöglicht präzise Aussagen über Produkteigenschaften. Mit Stilanalysen kann insbesondere bei Verwendung von Programmiersprachen mit einer liberalen Syntax die Verwendung qualitätsmindernder Konstrukte ausgeschlossen werden. Die Verwendung von Stilanalysatoren wird von einigen Standards für die Entwicklung von sicherheitskritischer Software mit bestimmten Programmiersprachen – z. B. C – gefordert. Grafiken und Tabellen sind ein seit langer Zeit übliches Hilfsmittel zur Darstellung von Software und zur Bereitstellung von Information über Software. Sie können statisch aus dem Programmcode erzeugt werden. Slicing gestattet die Identifikation von Wirkzusammenhänge zwischen Anweisungen einer Software. Es kann insbesondere zur Unterstützung des Debuggings dienen. Es gibt statisches und dynamisches Slicing. Slicing wird in der Regel der statischen Analyse zugeordnet, obwohl das – streng genommen – nur für das statische Slicing korrekt ist. Die Datenflussanomalieanalyse gestattet die automatische, sichere Identifikation bestimmter Fehler – der so genannten Datenflussanomalien. Diese können mit anderen Techniken nicht sicher erkannt werden. Daher besitzt die Datenflussanomalieanalyse eine hohe praktische Bedeutung. Inspektions- und Review-Techniken unterscheiden sich von den anderen statischen Analysen, weil sie nicht werkzeugunterstützt durchgeführt werden können. Empirischen Untersuchungen zufolge besitzen die manuellen Prüftechniken eine hohe Bedeutung in der Praxis /Spillner, Liggesmeyer 94/. Die seit langem bekannten informalen Reviews in Sitzungs- oder Kommentartechnik sind durch formale Review-Techniken ergänzt worden. Empirische Untersuchungen zeigen, dass formale Inspektions-Techniken, z. B. die so genannte Fagan-Inspektion /Fagan 76/, /Fagan 86/, /Gilb, Graham 93/, sehr leistungsfähig, aber aufwändig sind. Daher werden in der Praxis für die Prüfung unkritischer Systemkomponenten alternativ auch konventionelle, informale Review-Techniken verwendet, z. B. Structured Walkthroughs /Yourdon 89/.

1.4.3 Symbolischer Test

44

Formale Techniken: Symbolischer Test und formale Beweisverfahren

Der symbolische Test bietet – falls bestimmte Voraussetzungen erfüllt sind – die Möglichkeit, vollständige Aussagen zu erhalten. Er vermeidet so den Stichprobencharakter des dynamischen Tests. Zu den testenden Verfahren kann er – als Erweiterung des dynamischen Tests – aufgrund seiner allgemeineren Form der Programmausführung mit symbolischen Werten gerechnet werden. Andererseits kann er ebenso als analytisches Verfahren und Bindeglied zwischen dem dynamischen Test und der Verifikation gesehen werden, da die Korrektheit bestimmter Programme

1 Einführung

durch symbolischen Test gezeigt werden kann. Symbolisches Testen besitzt die folgenden Eigenschaften: >

Der Quellcode des symbolisch zu testenden Software-Moduls wird mit allgemeinen symbolischen Werten durch einen Interpreter ausgeführt.

>

Der symbolische Test testet in einer künstlichen Umgebung.

>

Der symbolische Test gewinnt allgemeine Aussagen über die Korrektheit für ganze Eingabebereiche.

>

Der symbolische Test ist im Allgemeinen kein Stichprobenverfahren.

>

Er kann für bestimmte Software-Module die Korrektheit beweisen.

>

Der symbolische Test nimmt eine Stellung zwischen dem dynamischen Test, der statischen Analyse und der Verifikation ein.

Mermale des symbolischen Tests

Der symbolische Test wird selten als einzelnes Verfahren angewendet. Er wird im Wesentlichen ergänzend zu anderen Verfahren, z. B. ergänzend zum dynamischen Test zur Testdatengenerierung oder als Hilfsmittel zur Beurteilung der Ausführbarkeit bestimmter Pfade benutzt (siehe auch /Zelkowitz 90/, /Coen-Porisini et al. 91/). Die formalen Beweisverfahren versuchen, einen Beweis der Konsistenz zwischen einer Software und ihrer Spezifikation mit formalen Mitteln zu erbringen. Daher ist eine formale Spezifikation zwingend erforderlich. Bei den formal verifizierenden Techniken werden Zusicherungsverfahren, algebraische und automatenbasierte Techniken unterschieden. Die klassischen Beweisverfahren aus den 60er-Jahren sind Zusicherungsverfahren. Besonders in steuerungstechnischen Anwendungen werden Verfahren auf Basis zustandsendlicher Beschreibungen häufig verwendet. Algebraische Verfahren sind seit langem bekannt. Sie bieten sich insbesondere für die Verifikation von Klassen und Objekten bei objektorientiert realisierten Systemen an. Die Struktur einer objektorientierten Klasse bietet im Allgemeinen gute Voraussetzungen zur Anwendung algebraischer Techniken.

Formaler Korrektheitsbeweis

Automatenbasierte Techniken bilden die Basis für den formalen Nachweis von Eigenschaften durch das so genannte Symbolic Model Checking. Die Akzeptanz formaler Techniken in der Praxis ist gering. Eine Ursache ist sicherlich die in vielen Fällen unzureichende Anwendbarkeit dieser Techniken auf reale Software. Häufig werden mangelhafte Rahmenbedingungen die Anwendung formaler Techniken verhindern. Dies kann die Nichtverfügbarkeit einer hinreichend formalen Spezifikation im Rahmen der Verifikation sein oder das Fehlen eines geeigneten Werkzeugs.

1.4 Einordnung und Klassifikation der Prüftechniken

45

1.5

Organisation

Software wird heute arbeitsteilig mit verteilten Aufgaben entwickelt und geprüft. Für die Software-Prüfung sind einige organisatorische Aspekte zu beachten. Es sind insbesondere die folgenden Fragen zu beantworten:

Eine geeignete Modularisierung ist eine wichtige Voraussetzung für die Prüfung.

Phasen der Prüfung

Wer führt die Prüfung durch?

46

>

In welchen Phasen wird die Prüfung durchgeführt?

>

Welche Methoden, Techniken und Werkzeuge werden in den Phasen jeweils eingesetzt?

>

Wer führt die Prüfung durch?

>

Wer ist verantwortlich für die Qualität der Prüfung?

Software besteht heute in der Regel aus einer Vielzahl von Modulen, die entkoppelt voneinander sein sollten. In einer funktional dekomponierenden Entwicklung werden oft einzelne Funktionen als Module verstanden. Bei objektorientierter Software bilden im Regelfall die Klassen die Module. Die Bildung abgeschlossener Module muss von der verwendeten Programmiersprache unterstützt werden und sollte vom Programmierer nicht durchbrochen werden. Eine Java-Klasse ist ein Modul, das seine Interna geeignet vor der Außenwelt schützt. Dies gilt aber nur, wenn der Kapselungsmechanismus nicht explizit durchbrochen wird. So sollte z. B. darauf verzichtet werden, öffentliche Attribute (public) zu vereinbaren. Einige ältere Programmiersprachen bieten lediglich weniger strikte Modularisierungsmechanismen. Modularisierung ist eine wichtige Voraussetzung für die Durchführung der Prüfung in Phasen. Man unterscheidet den Modultest, verschiedene Integrationstests (z. B. Subsystem-Integrationstest, System-Integrationstest, Software-/Hardware-Integrationstest) und den Systemtest. Ohne Modularisierung, ist die Prüfung in Phasen nicht durchführbar. Der Vorteil des Prüfens in Phasen ist die einfachere Fehlererkennung und -lokalisierung. Bei der Auswahl von Techniken sind eine Vielzahl von Aspekten zu beachten. Die Verwendung einer beliebigen systematischen Prüftechnik kann mehr Schaden als Nutzen bringen. Die Beantwortung der Frage „Welche Methoden, Techniken und Werkzeuge werden in den Phasen jeweils eingesetzt?“ ist schwierig. Für die Zuordnung von Prüfpersonal gibt es alternative Lösungen. In umfangreichen Entwicklungen wird der Integrationstest oft von Mitarbeitern einer speziell dafür eingerichteten Organisationseinheit durchgeführt. Die Programmierer sind in der Regel nicht mit Integrationstests und Systemtests befasst. Die Organisationseinheit, die den Systemtest durchführt, hat oft aufgrund ihrer Eigenschaft als „letzte Kontrollinstanz“ vor der Freigabe besondere Befugnisse. Sie ist z. B. oft nicht dem Projektmanagement unterstellt. Der Modultest wird häufig noch ausschließlich vom Programmierer durchgeführt. Es fehlt in der Regel der Nachweis

1 Einführung

einer ordnungsgemäßen Testabdeckung und eine Aufzeichnung der gefundenen Fehler. Es gibt einige Gründe, die den Programmierer als Modultester geeignet erscheinen lassen. Dazu gehört die detaillierte Kenntnis des Programmcodes. Es gibt aber auch Gründe, die gegen den Programmierer als Modultester angeführt werden können. So ist z. B. zu bezweifeln, dass ein Programmierer, der einen Fehler beim Programmieren nicht bemerkt hat, diesen Fehler beim Prüfen erkennen wird. Gegen den Programmierer spricht also seine „Betriebsblindheit“. Im Zusammenhang mit der Nutzung systematischer Techniken kann eine elegante Antwort auf die Frage „Wird der Modultest durch den Programmierer oder eine unabhängige Person durchgeführt?“ gefunden werden. Dies wird in Kapitel 11 diskutiert. Die Antwort auf die Frage „Wer ist verantwortlich für die Qualität der Prüfung?“ scheint einfach. Als Gesamtverantwortlicher für alle Belange des Projekts ist der Projektleiter auch für die Qualität der Prüfung verantwortlich. Es gibt aber viele Firmen, die der Projektleitung eine organisatorisch unabhängige Qualitätssicherung zur Seite stellen. In der Regel ist es dem Projektleiter möglich, vermutete Qualitätsmängel z. B. im Falle von Termindruck zu ignorieren. Wenn diese Mängel aufgrund systematischer Prüfungen – z. B. Messungen – offen zutage treten, ist das schon schwieriger, aber grundsätzlich immer noch möglich. Wenn derartige Probleme ignoriert werden und in der Folge massive Wartungsaufwände und verärgerte Kunden zu verzeichnen sind, so mag das für zukünftige Entscheidungen Konsequenzen haben. Nach meiner Erfahrung profitieren gute Projektleiter von verlässlichen Qualitätsindikatoren. Neben den Zielgrößen, die bisher schon quantitativ verfügbar waren (Kosten, Aufwand und Zeit) ist nun auch die Qualität nachprüfbar. Ein guter Projektleiter sollte eine Verantwortung für vier bekannte Größen einer Verantwortung für drei bekannte und eine unbekannte Größe vorziehen. Dies ermöglicht es, den besten Kompromiss aus allen Zielgrößen zu wählen.

1.5 Organisation

Wer trägt die Qualitätsverantwortung?

47

CHECKLISTE

48

>

Die „beste Software-Qualität“ ist ein inhaltsleerer Begriff. Das Ziel ist nicht die beste, sondern die richtige Software-Qualität. Führen Sie zu Beginn der Entwicklung eine Qualitätszielbestimmung durch.

>

Es gibt keinen universell geeigneten, optimalen Weg zur richtigen Software-Qualität. Sie müssen aus einer Menge unterschiedlicher Lösungen auswählen. Dabei soll dieses Buch Ihnen helfen.

>

Die alleinige Einführung eines Werkzeugs ist niemals eine geeignete Lösung. Diese umfasst stets passende organisatorische und technische Maßnahmen, die durch Werkzeuge ergänzt werden sollten. Konzipieren Sie zuerst eine fachlich geeignete Lösung und wählen Sie anschließend die dazu passenden Werkzeuge aus. Dabei sollten Sie allerdings beachten, dass zu einigen Techniken kaum Werkzeuge angeboten werden. Informationen zu Werkzeugen finden Sie in Kapitel 12.

1 Einführung

2 Funktionsorientierter Test Im Folgenden werden dynamische Testtechniken dargestellt, welche die Vollständigkeit des Tests anhand der Abdeckung einer Spezifikation mit Testfällen beurteilen. Da Spezifikationen die Soll-Funktionalität einer Software festlegen, werden die Testtechniken, die gegen Spezifikationen testen, als funktionsorientierte Testtechniken bezeichnet. Funktionsorientierte Testtechniken sind unverzichtbar. Standards verlangen stets eine sorgfältige funktionsorientierte Testplanung. Dies ist eine direkte Forderung zur Nutzung systematischer funktionsorientierter Testtechniken. Funktionsorientiertes Testen findet in allen Testphasen statt. Im Modultest werden Modulspezifikationen als Basis für den Test herangezogen. Im Integrationstest bilden Schnittstellenspezifikationen die Testreferenz. Im Systemtest wird gegen Anforderungsdefinitionen getestet. Ein Test ohne systematische funktionsorientierte Testplanung ist als ungenügend zu betrachten.

Übersicht 2.1

Eigenschaften und Ziele des funktionsorientierten Tests . . . . 50

2.2

Funktionale Äquivalenzklassenbildung . . . . . . . . . . . . . . . . . . . . . 51

2.3

Zustandsbasierter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.4

Ursache-Wirkungs-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.5

Weitere funktionsorientierte Testtechniken . . . . . . . . . . . . . . . . 73

2.6

Bewertung des funktionsorientierten Tests . . . . . . . . . . . . . . . . . 81 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

49

2.1 Testgrundlage: Spezifikation

Funktionsorientierte Testtechniken definieren Regeln für die Testdatenerzeugung

PROBLEM: Ungetesteter Code

Eigenschaften und Ziele des funktionsorientierten Tests

Die funktionsorientierten Testtechniken stellen die Software-Spezifikation in den Mittelpunkt des Testgeschehens. Es ist daher insbesondere darauf zu achten, dass eine zum jeweiligen Test passende Spezifikation zur Verfügung steht und auch verwendet wird. Abb. 2.1 zeigt das Prinzip des funktionsorientierten Tests. Der Tester liest die Spezifikation und gewinnt so ein Bild ihrer Inhalte. Dieses wird nach festen Regeln in Testfälle übersetzt. Bei der Durchführung der Testfälle entstehen Reaktionen der Software. Die Korrektheit dieser Reaktionen ist anhand des Bildes der Spezifikation zu beurteilen. Das Testende ist erreicht, wenn das Bild der Spezifikation mit Testfällen vollständig abgedeckt ist. Der Spezifikation kommt beim funktionsorientierten Testen eine zentrale Bedeutung zu. Sie dient zur Beurteilung der Vollständigkeit des Tests sowie zur Herleitung der Testfälle und der Beurteilung der Reaktionen der Software. Aufgrund ihrer Herleitung aus der Spezifikation sind die Testfälle eines funktionsorientierten Tests systematisch an der Überprüfung der SollFunktionalität ausgerichtet. Daher kann insbesondere geprüft werden, ob die Spezifikation vollständig in Software umgesetzt wurde. Ein erfolgreich durchgeführter funktionsorientierter Test vermittelt daher ein gesteigertes Vertrauen in die Software-Qualität. Neben den genannten Vorteilen existieren einige Nachteile. So kann ein funktionsorientierter Test z. B. nicht gewährleisten, dass der Programmcode vollständig getestet wird. Bei einem reinen funktionsorientierten Test ist daher davon auszugehen, dass in der Software noch ungetesteter Code existiert.

Spezifikation Testfälle

Vollständigkeit

Bild der Spezifikation

Software

Reaktionen beurteilen Tester

Abbildung 2.1 Prinzip des funktionsorientierten Tests

Da die Abläufe innerhalb der getesteten Software beim funktionsorientierten Testen irrelevant sind, gehören die funktionsorientierten Test-

50

2 Funktionsorientierter Test

techniken zu den so genannten Black Box-Tests. Black Box-Testen und funktionsorientiertes Testen sind jedoch keine Synonyme. Alle funktionsorientierten Testtechniken sind Black Box-Techniken, aber nicht alle Black Box-Techniken sind funktionsorientiert. Funktionsorientiertes Testen erzwingt die Erzeugung von Testfällen aus Spezifikationen. Black Box-Testen bedeutet, dass auf eine Betrachtung der Programmstruktur verzichtet wird. Weil funktionsorientierte Testtechniken die Testfälle anhand der Spezifikation erzeugen und die Spezifikation verwenden, um Vollständigkeit zu bewerten, können sie auf eine Betrachtung der Programmstruktur verzichten. Sie sind daher Black Box-Techniken. Andere Black Box-Techniken verzichten aus anderen Gründen auf die Betrachtung der Programmstruktur. Es handelt sich dann um Black Box-Techniken, die nicht funktionsorientiert testen.

2.2 2.2.1

Funktionsorientierter Test = Black Box-Test

Der Zufallstest (Abschnitt 5.3) ist ein Beispiel für eine Black Box-Technik, die nicht funktionsorientiert testet.

Funktionale Äquivalenzklassenbildung Eigenschaften und Ziele der funktionalen Äquivalenzklassenbildung

Ein Hauptproblem beim dynamischen Software-Test ist die Auswahl einiger weniger Testfälle aus einer oft umfangreichen Menge von möglichen Betriebssituationen. Es ist schwierig, aus einer großen Menge potentieller Testfälle einige wenige auszuwählen, die durchgeführt werden sollen. Die Auswahl einiger Testfälle bedeutet, dass sich der Tester implizit entscheidet, eine große Menge von Betriebssituationen nicht zu testen. Daher muss die Auswahl der Testfälle sehr sorgfältig geschehen. Es ist darauf zu achten, dass die gewählten Testfälle gute Stellvertreter der Grundgesamtheit darstellen. Darüber hinaus sollen sie so beschaffen sein, dass potentiell enthaltene Fehler möglichst zuverlässig erkannt werden. Des Weiteren sollen die Testfälle frei von Redundanzen sein. Die Funktionale Äquivalenzklassenbildung nutzt ein Prinzip, das sich als Verfahren zur Beherrschung von Komplexität an vielen Stellen als nützlich erwiesen hat: das Prinzip „Teile und Herrsche“. Die funktionale Äquivalenzklassenbildung versucht die Komplexität eines Testproblems durch fortgesetztes Zerlegen so weit zu reduzieren, dass schließlich eine sehr einfache Wahl von Testfällen möglich wird. Am Ende der Zerlegung steht eine Menge von so genannten Äquivalenzklassen. Alle Werte einer Äquivalenzklasse sollen durch die zu testende Software gleichartig bearbeitet werden. Daher ist davon auszugehen, dass jeder Wert einer Äquivalenzklasse ein geeigneter repräsentativer Stellvertreter für alle Werte der Äquivalenzklasse ist. Da die Äquivalenzklassen anhand der Spezifikation identifiziert werden, heißt das Verfahren funktionale Äquivalenzklassenbildung.

2.2 Funktionale Äquivalenzklassenbildung

Englisch: Divide and conquer

51

2.2.2 Ansatz: Fallunterscheidung

Gültige vs. ungültige Äquivalenzklassen

Grenzwertanalyse

BEISPIEL

Beschreibung der funktionalen Äquivalenzklassenbildung

Der grundsätzliche Ansatz bei der funktionalen Äquivalenzklassenbildung ist die Durchführung einer fortgesetzten Fallunterscheidung. Dies geschieht sowohl für Eingabe- als auch für Ausgabebedingungen der zu testenden Software. Werte aus einer Äquivalenzklasse sollen ein identisches funktionales Verhalten verursachen. Sie testen insbesondere dieselbe spezifizierte Programmfunktion. Einerseits stellt die Bildung von Äquivalenzklassen anhand der Spezifikation sicher, dass alle spezifizierten Programmfunktionen mit Werten ihrer Äquivalenzklasse getestet werden. Andererseits wird eine Beschränkung der Testfallanzahl erreicht. Eingabeäquivalenzklassen werden direkt für Eingabebedingungen gebildet. Falls die Spezifikation z. B. ausschließlich positive Werte für eine bestimmte Eingabe gestattet, so können anhand dieser Forderung zwei Fälle unterschieden werden: positive Eingabewerte und nichtpositive Eingabewerte. Die positiven Eingabewerte stellen den Normalfall dar. Man spricht von so genannten gültigen Äquivalenzklassen. Nicht-positive Eingaben dürfen nicht auftreten. Treten sie dennoch auf, so liegt ein Fehlerfall vor, der einer Fehlerbehandlung bedarf. Man spricht von so genannten ungültigen Äquivalenzklassen. Die Äquivalenzklassenbildung für Ausgabebedingungen erfolgt ebenfalls anhand einer Fallunterscheidung auf Basis der Spezifikation. Nachdem die Ausgabeäquivalenzklassen vorliegen müssen zusätzlich Eingabewerte ermittelt werden, die Ausgaben in den jeweils betrachteten Ausgabeäquivalenzklassen verursachen. Die Auswahl der konkreten Testdaten aus einer Äquivalenzklasse kann nach unterschiedlichen Kriterien erfolgen. Eine oft verwendete Vorgehensweise ist der Test der Äquivalenzklassengrenzen. Dieses heuristische Verfahren wird als Grenzwertanalyse bezeichnet. Es basiert auf der Erfahrung, dass Fehler besonders häufig an den Grenzen von Äquivalenzklassen auftreten. Andere mögliche Ansätze sind der Test besonderer Werte, beispielsweise der Wert 0, oder auch eine zufallsorientierte stochastische Vorgehensweise. Bereits in /Myers 79/ ist die Bildung von ungültigen und gültigen Äquivalenzklassen vorgesehen. Ist für eine Eingabe z. B. ein Wertebereich vorgesehen, so stellt dieser Bereich eine gültige Äquivalenzklasse dar, die gegebenenfalls weiter aufzutrennen ist, und die an ihrer unteren und oberen Grenze durch jeweils eine eigene ungültige Äquivalenzklasse begrenzt wird.

Eingabebereich: 1 ≤ Wert ≤ 99 Eine gültige Äquivalenzklasse: 1 ≤ Wert ≤ 99 Zwei ungültige Äquivalenzklassen: Wert < 1, Wert > 99

52

2 Funktionsorientierter Test

Im Einzelnen werden folgende Regeln zur Äquivalenzklassenbildung benutzt /Myers 79/: Falls eine Eingabebedingung einen Wertebereich spezifiziert, so sind eine gültige Äquivalenzklasse und zwei ungültige Äquivalenzklassen zu bilden (siehe oben angegebenes Beispiel). Spezifiziert eine Eingabebedingung eine Anzahl von Werten, so sind eine gültige Äquivalenzklasse und zwei ungültige Äquivalenzklassen zu bilden.

Für ein Auto können zwischen einem und sechs Besitzer eingetragen sein.

BEISPIEL

Eine gültige Äquivalenzklasse: >

Ein Besitzer bis sechs Besitzer

Zwei ungültige Äquivalenzklassen: >

Kein Besitzer

>

Mehr als sechs Besitzer

Falls eine Eingabebedingung eine Menge von Werten spezifiziert, die unterschiedlich behandelt werden, so ist für jeden Wert eine eigene gültige Äquivalenzklasse zu bilden. Für alle Werte mit Ausnahme der gültigen Werte ist eine ungültige Äquivalenzklasse zu bilden.

Tasteninstrumente: Klavier, Cembalo, Spinett, Orgel.

BEISPIEL

Vier gültige Äquivalenzklassen: >

Klavier

>

Cembalo

>

Spinett

>

Orgel

Eine ungültige Äquivalenzklasse: >

Alles andere, z. B. Violine

Falls eine Eingabebedingung eine Situation festlegt, die zwingend erfüllt sein muss, so sind eine gültige Äquivalenzklasse und eine ungültige Äquivalenzklasse zu bilden.

2.2 Funktionale Äquivalenzklassenbildung

53

BEISPIEL

Das erste Zeichen muss ein Buchstabe sein. Eine gültige Äquivalenzklasse: >

Das erste Zeichen ist ein Buchstabe.

Eine ungültige Äquivalenzklasse: >

Das erste Zeichen ist kein Buchstabe (z. B. Ziffer oder Sonderzeichen).

Falls Grund zu der Annahme besteht, dass Elemente einer Äquivalenzklasse unterschiedlich behandelt werden, so ist diese Äquivalenzklasse entsprechend aufzutrennen. Bildung von Ausgabeäquivalenzklassen

BEISPIEL

Diese Regeln für die Bildung von Eingabeäquivalenzklassen können auf die Bildung von Ausgabeäquivalenzklassen übertragen werden. Als Beispiel ist hier die Regel für die Situation, dass ein Ausgabewertebereich spezifiziert ist, angegeben. Spezifiziert eine Ausgabebedingung einen Wertebereich, so sind alle Eingabewerte, die Ausgaben innerhalb des Wertebereichs erzeugen, einer gültigen Äquivalenzklasse zuzuordnen. Alle Eingaben, die Ausgaben unterhalb des spezifizierten Wertebereichs verursachen, werden einer ungültigen Äquivalenzklasse zugeordnet. Alle Eingaben, die Ausgaben oberhalb des spezifizierten Wertebereichs verursachen, werden einer anderen ungültigen Äquivalenzklasse zugeordnet.

Ausgabebereich: 1 ≤ Wert ≤ 99 Eine gültige Äquivalenzklasse: >

Alle Eingaben, die Ausgaben zwischen 1 und 99 erzeugen.

Zwei ungültige Äquivalenzklassen: >

Alle Eingaben, die Ausgaben kleiner als 1 erzeugen

>

Alle Eingaben, die Ausgaben größer als 99 erzeugen

Die Bildung gültiger und ungültiger Äquivalenzklassen ist sinnvoll für Programme, die ihre Eingaben über Ein-/Ausgabekanäle erhalten, da für ungültige Äquivalenzklassen Fehlerbehandlungen existieren müssen. Für unterlagerte Operationen, die ihre Eingaben über Parameterschnittstellen erhalten, sind die Beschränkungen bezüglich der Eingaben zu beachten. Das aufrufende Programm führt möglicherweise gewisse Fehlerbehandlungen bereits durch. Eine erneute Fehlerabfrage in der Operation

54

2 Funktionsorientierter Test

führt in diesem Fall zu dynamisch nicht erreichbarem Code. Oft existieren auch bestimmte Abhängigkeiten zwischen Eingaben, die eine Herstellung mancher Eingabekonstellationen ausschließen. Durch Nichtbeachtung dieser Aspekte werden Testfälle erzeugt, die für den Test ungeeignet sind.

Für die Operation ZaehleZchn können die folgenden Äquivalenzklassen gebildet werden (siehe Beispielspezifikation in Abschnitt 2.4):

BEISPIEL

1. Zchn < ’A’ 2. Zchn > ’Z’ 3. Zchn ≥ ’A’ und Zchn ≤ ’Z’ 4. Zchn ist ein großer Konsonant. 5. Zchn ist ein großer Vokal. 6. Zchn ist weder ein großer Konsonant noch ein großer Vokal. 7. Gesamtzahl < INT_MAX 8. Gesamtzahl = INT_MAX 9. Gesamtzahl > INT_MAX Für VokalAnzahl müssen keine Äquivalenzklassen gebildet werden, da aufgrund der Abhängigkeit zwischen VokalAnzahl und Gesamtzahl die Verarbeitung vom Wert der Variablen VokalAnzahl unabhängig ist. Die Äquivalenzklassen sind zum Teil nicht disjunkt. So ergeben die Äquivalenzklassen 4 und 5 zusammen die Äquivalenzklasse 3. Außerdem sind nicht zu allen Äquivalenzklassen Testfälle erzeugbar. Aufgrund des Datentyps von Gesamtzahl können Testfälle zur Äquivalenzklasse 9 nicht erzeugt werden.

Die Äquivalenzklassen sind eindeutig zu nummerieren. Für die Erzeugung von Testfällen aus den Äquivalenzklassen sind zwei Regeln zu beachten: >

Die Testfälle für gültige Äquivalenzklassen werden durch Auswahl von Testdaten aus möglichst vielen gültigen Äquivalenzklassen gebildet. Dies reduziert die Testfälle für gültige Äquivalenzklassen auf ein Minimum.

>

Die Testfälle für ungültige Äquivalenzklassen werden durch Auswahl eines Testdatums aus einer ungültigen Äquivalenzklasse gebildet. Es wird mit Werten kombiniert, die ausschließlich aus gültigen Äquivalenzklassen entnommen sind. Da für alle ungültigen Eingabewerte eine Fehlerbehandlung existieren muss, kann bei Eingabe eines fehlerhaften Wertes pro Testfall die Fehlerbehandlung nur durch

2.2 Funktionale Äquivalenzklassenbildung

Bildung von Testfällen aus Äquivalenzklassen

55

dieses fehlerhafte Testdatum verursacht worden sein. Würden mehrere fehlerhafte Eingaben pro Testfall verwendet, so ist nicht erkennbar, welches fehlerhafte Testdatum die Fehlerbehandlung ausgelöst hat.

BEISPIEL

Ein Programm zur Lagerverwaltung einer Baustoffhandlung besitzt eine Eingabemöglichkeit für die Registrierung von Anlieferungen. Werden Holzbretter angeliefert, so wird die Holzart eingegeben. Das Programm kennt die Holzarten Eiche, Buche und Kiefer. Ferner wird die Länge in Zentimetern angegeben, die stets zwischen 100 und 500 liegt. Als gelieferte Anzahl kann ein Wert zwischen 1 und 9999 angegeben werden. Außerdem erhält die Lieferung eine Auftragsnummer. Jede Auftragsnummer für Holzlieferungen beginnt mit dem Buchstaben H. Anhand dieser Beschreibung können, unter Verwendung der angegebenen Regeln, die Äquivalenzklassen nach Tab. 2.1 gebildet werden. Tab. 2.2 stellt einen vollständigen Satz von Testfällen dar. Die Testdaten sind ohne Anwendung einer konkreten Strategie aus den Äquivalenzklassen gewählt. Die in Tab. 2.3 dargestellten Testfälle sind durch gemeinsame Anwendung von Äquivalenzklassenanalyse und Grenzwertanalyse entstanden. Als Testdaten sind systematisch die Grenzen der Äquivalenzklassen gewählt worden. Das Kürzel U oder O hinter der Angabe der getesteten Äquivalenzklasse kennzeichnet einen Test der unteren bzw. oberen Grenze der angegebenen Äquivalenzklasse.

Tabelle 2.1 Äquivalenzklassen-Aufstellung

Tabelle 2.2 Testfälle nach einer Äquivalenzklassenanalyse

56

2 Funktionsorientierter Test

Tabelle 2.3 Testfälle nach einer Äquivalenzklassenanalyse und Grenzwertanalyse

2.2.3

Bewertung der funktionalen Äquivalenzklassenbildung

Die funktionale Äquivalenzklassenbildung ist eine ziemlich universell einsetzbare Testtechnik. Im Modultest wird eine Fallunterscheidung bezüglich konkreter Ein- und Ausgabewerte durchgeführt. Im Integrationstest werden die über Schnittstellen möglichen Interaktionen unterschieden. Im Systemtest werden unterschiedliche Anwendungsfälle unterschieden. Das Verfahren ist einfach anwendbar. Darüber hinaus ist zu erwarten, dass zahlreiche Softwaretester, die bislang ohne konkrete Methodik gearbeitet haben, implizit bereits ähnliche Verfahren angewendet haben. Die Durchführung einer funktionalen Äquivalenzklassenbildung in der hier beschriebenen Vorgehensweise systematisiert daher sicherlich in vielen Fällen nur eine Technik, die in einfacherer Form bereits etabliert ist. Es ist deshalb damit zu rechnen, dass die Einführung der funktionalen Äquivalenzklassenbildung als Testtechnik problemlos vonstatten gehen wird. Aufgrund der beschriebenen Vorgehensweise, die vorsieht, dass Testfälle tabellarisch geplant und abgelegt werden, ist zu erwarten, dass im Falle des Wechsels von Testzuständigkeiten die Einarbeitung erleichtert wird. Darüber hinaus ist es möglich, Fehler, die beim Testen nicht gefunden und zu einem späteren Zeitpunkt erkannt wurden, auf die Äquivalenzklassenschemata abzubilden, um die Äquivalenzklassenbildung zu optimieren. Neben den genannten Vorteilen existieren einige Nachteile. Die funktionale Äquivalenzklassenbildung gestattet es nicht, Wechselwirkungen zwischen Äquivalenzklassen zu beschreiben. Falls Software-Reaktionen an eine ganz bestimmte Verknüpfung von Äquivalenzklassen gebunden sind, so kann dies bei der funktionalen Äquivalenzklassenbildung nicht geeignet beschrieben werden. Die im Folgenden noch beschriebene Ursache-Wirkungs-Analyse bietet eine Lösungsmöglichkeit für dieses Problem. Die funktionale Äquivalenzklassenbildung bereitet weiterhin Schwierigkeiten bei der Anwendung auf zustandsbasierte Soft-

2.2 Funktionale Äquivalenzklassenbildung

Vorteil: Einfachheit

Gute Testdokumentation erleichtert die Einarbeitung

PROBLEME: Wechselwirkungen von Äquivalenzklassen sind nicht erfassbar; zustandsbasierte Software ist nicht behandelbar.

57

ware. In zustandsbasierter Software wird im Allgemeinen auf Eingaben je nach Zustand der Software unterschiedlich reagiert. Diese Abhängigkeit zwischen Äquivalenzklassen und Zuständen kann ebenfalls nicht geeignet beschrieben werden. Zusammenfassend kann formuliert werden: Die funktionale Äquivalenzklassenbildung ist gut geeignet für den Test von Software, die nicht zustandsbasiert ist und bei der die Reaktionen nicht abhängig sind von komplizierten Eingabeverknüpfungen.

2.3 2.3.1

Zustandsbasierte vs. zustandsfreie Systeme

Zustandsautomaten sind ein verbreitetes Beschreibungsmittel.

Zustandsbasierter Test Eigenschaften und Ziele des zustandsbasierten Tests

Die Unterscheidung zwischen zustandsbasierten und zustandsfreien Systemen ist auch in anderen Disziplinen als der Informatik verbreitet. So unterscheidet man z. B. in der Elektrotechnik Schaltnetze – zustandsfreie Schaltungen – und Schaltwerke – zustandsbehaftete Schaltungen. Man spricht insgesamt auch von gedächtnisbehafteten und gedächtnislosen Systemen. Streng genommen ist jede Software gedächtnisbehaftet, denn sie verfügt über einen Speicher. Diese Gedächtnisbehaftung steht aber nicht stets so im Vordergrund, dass sie für den Test beachtet werden muss. Falls sie ignoriert werden kann, so reicht eine funktionale Äquivalenzklassenbildung als Testtechnik aus. Falls das Gedächtnis das Verhalten der Software wesentlich bestimmt, so muss eine Testtechnik verwendet werden, die dies berücksichtigen kann. Der zustandsbasierte Test ist eine solche Technik. Zustandsautomaten sind ein verbreitetes Beschreibungsmittel in technischen Disziplinen. In der Informatik sind sie eine so genannte Basistechnik zur Beschreibung von Verhalten. Moderne Analyse- und Entwurfstechniken – z. B. UML (Unified Modeling Language) – bieten Zustandsautomaten als Beschreibungsmittel an. In der UML können Zustandsautomaten zur Beschreibung des Verhaltens von Klassen genutzt werden. Zustandsbasiertes Testen ist eine funktionsorientierte Testtechnik für Software, die als Zustandsautomat spezifiziert ist oder zumindest als Zustandsautomat spezifiziert werden kann.

2.3.2

Beschreibung des zustandsbasierten Tests

Zustandsbasiertes Testen zielt auf die vollständige Testabdeckung von Zustandsautomaten. Da die Zustandsautomaten eine Spezifikation sind, handelt es sich hier um einen funktionsorientierten Ansatz. Im Folgenden ist ein Ausschnitt einer Modulspezifikation in Textform angegeben. Die Modulspezifikation besitzt einige Unzulänglichkeiten, die typisch für textuelle Beschreibungen von zustandslastiger Software sind.

58

2 Funktionsorientierter Test

Es ist ein Verbindungsaufbau und -abbau zwischen einem rufenden Teilnehmeranschluss und einem gerufenen Teilnehmeranschluss zu realisieren. Initial befindet sich die Verbindung im Zustand Getrennt. Bei aufgelegtem Hörer befindet sich die Software stets in diesem Zustand. Falls der Gesprächsaufbau begonnen wurde aber noch nicht beendet ist, so befindet sich die Software im Zustand Wählend. Falls der Gesprächsaufbau erfolgreich war, so befindet sich die Software im Zustand Verbunden.

BEISPIEL

Ein erfolgreicher Gesprächsaufbau beginnt stets mit dem Abnehmen des Telefonhörers, gefolgt von der Wahl einer Ziffernfolge, die eine gültige Rufnummer darstellt. Ein Auflegen des Hörers führt stets zum vollständigen Abbruch des Gesprächs. Falls im Zustand Wählend ein Timeout auftritt, so kann nur durch Auflegen des Hörers in den Initialzustand zurückgekehrt werden.

Die angegebene Spezifikation enthält keine Fehler; aber sie enthält Unvollständigkeiten. Obwohl es sich bei der in der Spezifikation beschriebenen Funktionalität um einen Vorgang handelt, den jeder täglich vollzieht, sind die Schwächen der Spezifikation nicht auf den ersten Blick zu erkennen. Eine intuitive Vorstellung der konkreten Abläufe entsteht allein anhand der textuellen Spezifikation nicht. Die Ursache für diese Mängel ist der Typ des betrachteten Systems: Es ist gedächtnisbehaftet. In gedächtnisbehafteten Systemen sind die Abläufe flächig. In einem betrachteten Zustand können im Allgemeinen mehrere unterschiedliche Ereignisse auftreten, die unterschiedliche Aktionen verursachen und Übergänge in unterschiedliche Folgezustände bewirken. Aus diesem Grund gibt es keine überzeugende Möglichkeit, Zustandsautomaten – also flächige, zweidimensionale Gebilde – eindimensional darzustellen. Texte sind stets eindimensionale Gebilde, in denen entschieden werden muss, welcher Sachverhalt zuerst und welcher Sachverhalt anschließend beschrieben wird. Die Darstellung eines Zustandsautomaten als Text ist daher unangemessen. Eine bessere Darstellungsform ist der grafisch notierte Zustandsautomat oder die dazu äquivalente Darstellung als Zustandsübergangstabelle. Abb. 2.2 ist die grafische Darstellung der im Beispiel angegebenen Modulspezifikation als Zustandsautomat. Von den zahlreichen verfügbaren Notationsformen ist die in der objektorientierten Welt verbreitete Notation für Zustandsautomaten aus der UML verwendet worden. Zustandsübergänge werden in Form gerichteter Kanten zwischen zwei Zuständen notiert. Das den Zustandsübergang auslösende Ereignis wird vor einem Schrägstrich angegeben. Die mit dem Zustandsübergang verknüpfte Aktion wird hinter dem Schrägstrich notiert. Der von rechts auf den Zustand Getrennt gerichtete Pfeil markiert diesen Zustand als Initialzustand. Der angegebene Zustandsautomat besitzt kleine Ergänzungen zur Modulspezifikation in Textform. Einerseits wird in der textuellen Spezifikation die Existenz des Zustandsübergangs vom Zustand Wählend in den Zustand Getrennt, der auftritt, wenn im Zustand Wählend der Telefonhörer auf-

2.3 Zustandsbasierter Test

Text ist eine unangemessene Beschreibung für zustandsbasierte Systeme.

59

Abbildung 2.2 Zustandsautomat zum Telefonbeispiel

EMPFEHLUNG: Zustandsbasierte Software stets grafisch spezifizieren!

Testvollständigkeitskriterien

Alle Zustände

Alle Zustandsübergänge

60

gelegt wird, nicht gefordert. Andererseits ist dies ohne Zweifel eine Unvollständigkeit der textuellen Spezifikation, da es möglich sein muss, im Zustand Wählend den Hörer aufzulegen. Den Zustand Nummer ungültig, den es notwendig geben muss, erwähnt die textuelle Spezifikation nicht. Die grafische Darstellung bietet eine sehr viel bessere Basis dafür, solche Unvollständigkeiten zu erkennen. Ich empfehle daher nachdrücklich, zustandsbasierte Software in grafischer Form mit Zustandsautomaten zu spezifizieren und diese Zustandsautomaten mit einem erläuternden Text zu versehen. Ich halte es für unklug, die grafische Notation durch eine reine Textform zu ersetzen. Neben den genannten Vorteilen in Bezug auf die Überprüfung der Vollständigkeit und Widerspruchsfreiheit der Spezifikation bietet der Zustandsautomat eine direkte Basis zur Erzeugung von Testfällen. Das einfachste aller zustandsbasierten Testvollständigkeitskriterien ist die Forderung zur mindestens einmaligen Abdeckung aller Zustände durch Testfälle. Wie anhand von Abb. 2.2 zu erkennen ist, gewährleistet diese Strategie nicht, dass alle Zustandsübergänge durchlaufen werden. So ist es z. B. möglich, alle Zustände zu erreichen, ohne den Zustandsübergang von Wählend in den Zustand Getrennt zu testen, der auftritt, wenn der Hörer aufgelegt wird. Daher ist die Forderung des Tests aller Zustandsübergänge ein gründlicheres Testkriterium als lediglich das Testen aller Zustände. Abb. 2.2 zeigt, dass ein Durchlaufen aller Zustandsübergänge garantiert, dass alle Zustände ebenfalls wenigstens ein Mal betreten worden sind. Der anhand dieses Beispiels erkennbare Zusammenhang gilt grundsätzlich. Der Test aller Zustandsübergänge subsumiert den Test aller Zustände. Der Test aller Zustandsübergänge ist mit den folgenden

2 Funktionsorientierter Test

Testfällen möglich (Zustände sind jeweils in kursiver Schrift, Ereignisse in nicht kursiver Schrift notiert): Getrennt, Abnehmen → Wählend, Auflegen → Getrennt Getrennt, Abnehmen → Wählend, Timeout → Timeout aufgetreten, Auflegen → Getrennt Getrennt, Abnehmen → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Rufnummer gültig → Verbunden, Auflegen → Getrennt Getrennt, Abnehmen → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Rufnummer ungültig → Nummer ungültig, Auflegen → Getrennt Getrennt, Abnehmen → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Ziffer 0 ... Ziffer 9 → Wählend, Rufnummer ungültig → Nummer ungültig, Timeout → Timeout aufgetreten, Auflegen → Getrennt Darüber hinaus ist es sinnvoll alle Ereignisse (events) zu testen, falls Zustandsübergänge durch unterschiedliche Ereignisse ausgelöst werden können. In dem Zustandsautomaten nach Abb. 2.2 gilt dies für die Ziffernwahl im Zustand Wählend. Hier wird ein Zustandsübergang durch zehn unterschiedliche Ereignisse – die Wahl der zehn unterschiedlichen Ziffern – ausgelöst. Während der Test aller Zustandsübergänge an dieser Stelle stets durch Auslösen ein und desselben Ereignisses durchgeführt werden könnte, verlangt der Test aller Ereignisse, dass alle zehn möglichen Ereignisse während der Testdurchführung an dieser Stelle wenigstens ein Mal auftreten. Die drei genannten Vollständigkeitskriterien für den zustandsbasierten Test bilden eine Hierarchie: Der Test aller Ereignisse an allen Zustandsübergängen subsumiert den Test aller Zustandsübergänge, der seinerseits den Test aller Zustände subsumiert. Es ist wichtig bei der Nutzung von Zustandsautomaten zur Testfallgenerierung zu berücksichtigen, welche Form des Zustandsautomaten vorliegt. Der in Abb. 2.2 dargestellte Zustandsautomat beschreibt lediglich das gewünschte Verhalten. Daher sind die aus dem Zustandsautomaten abgeleiteten Testfälle ausschließlich Normalfälle. Testfälle für Fehlersituationen sind nicht enthalten. Diese Fälle werden daher beim Test auf Basis von Zustandsautomaten gern übersehen. Für die Erzeugung von Testfällen für Fehlersituationen ist die Darstellung von Zustandsautomaten als Zustandsübergangstabelle hilfreich. Die Zustandsübergangstabelle ordnet jedem Zustands-Ereignis-Paar einen Folgezustand und gegebenenfalls die mit dem Zustandsübergang verknüpften Aktionen zu. Eine Zustandsübergangstabelle für den in Abb. 2.2 angegebenen Zustandsautomaten ist in Tab. 2.4 dargestellt. Tab. 2.4 ist aus dem Zustandsautomaten nach Abb. 2.2 erzeugt worden, indem für jedes

2.3 Zustandsbasierter Test

Alle Ereignisse

ACHTUNG: Fehlerfälle nicht vergessen Zustandsübergangstabelle für die Analyse von Fehlersituationen

61

Zustand

Getrennt

Wählend

Nummer ungültig

Verbunden

Ereignis

Timeout aufgetreten

Wählend

Abnehmen

Rufnr. zurücksetzen Getrennt

Auflegen

Getrennt

Rufnr. zurücksetzen

Rufnr. zurücksetzen Verbind. abbauen

Getrennt Rufnr. zurücksetzen

Getrennt

-

Wählend

Ziffer z. Rufnr. Hinzuf., Rufnr. prüfen

Ziffer 0

Wählend

Ziffer z. Rufnr. hinzuf., Rufnr. prüfen

Ziffer 9

Timeout aufgetreten Rufnr. zurücksetzen

Timeout

Timeout aufgetreten Rufnr. zurücksetzen

Verbunden Verbindung aufbauen Nummer ungültig

Rufnummer gültig Rufnummer ungültig

-

Ausgangszustand

Legende: Ereignis

Folgezustand Aktion(en)

Tabelle 2.4 Unvollständige Zustandsübergangstabelle zum Zustandsautomaten nach Abb. 2.2

Ereignis an jeder Kante des Zustandsautomaten ein entsprechender Eintrag in die Tabelle erstellt worden ist. Wie Tab. 2.4 zeigt, bleiben zahlreiche Tabellenfelder leer. Die Tabelle ist unvollständig. Gefüllte Tabellenfelder geben stets einen Folgezustand und – falls erforderlich – auch eine Aktion an. Da jedes gefüllte Tabellenfeld einem Ereignis an einer Kante des Zustandsautomaten entspricht, ist eine vollständige Überdeckung aller Zustandsübergänge mit allen Ereignissen herstellbar, indem jedes gefüllte Tabellenfeld als Testschritt berücksichtigt wird. Zu leeren Tabellenfelder sind im Zustandsautomaten nach Abb. 2.2 keine Kanten enthalten. Daher werden für die entsprechenden Zustands-Ereignis-Paare keine Zustandswechsel und keine Aktionen durchgeführt. Der Zustandsautomat nach Abb. 2.2 ignoriert bestimmte Ereignisse in bestimmten Zuständen einfach. So bleiben z. B. die Ereignisse Ziffer0 bis Ziffer9 im Zustand Getrennt ohne Wirkung. Eine Betätigung der Wähltastatur bei aufgelegtem Hörer ist möglich; sie soll aber keine Folgen haben. Um dieses Verhalten zu beschreiben, müssen die freien Felder in Tab. 2.4 gefüllt werden. Der Folgezustand muss identisch mit dem jeweiligen Ausgangszustand sein, und es ist keine Aktion einzutragen. Man erhält auf diese Weise die in Tab. 2.5 angegebene Zustandsübergangstabelle. Zu den grau hinterlegten Feldern weist der Zustandsautomat nach Abb. 2.2 keine Elemente auf. Daher werden diese Fälle oft übersehen. Die Zustandsübergangsta-

62

2 Funktionsorientierter Test

Zustand

Getrennt

Wählend

Verbunden

Ereignis Wählend

Abnehmen Auflegen

Wählend

Rufnr. zurücksetzen Getrennt

Getrennt

Getrennt

Wählend

Ziffer z. Rufnr. Hinzuf., Rufnr. prüfen

-

Getrennt

Ziffer 9

Wählend

Ziffer z. Rufnr. hinzuf., Rufnr. prüfen

Getrennt

Timeout

-

Rufnummer gültig

Getrennt

Rufnummer ungültig

Getrennt

-

Getrennt

Rufnr. zurücksetzen

-

Ziffer 0

Verbunden

-

Rufnr. zurücksetzen Verbind. abbauen

Verbunden

-

Verbunden

Timeout aufVerbunden getreten Rufnr. zurücksetzen Verbunden Verbunden Verbindung aufbauen Nummer unVerbunden gültig

-

-

Nummer ungültig

Timeout aufgetreten

Nummer ungültig

Timeout aufgetreten

Getrennt

Getrennt

-

-

Rufnr. zurücksetzen Timeout aufNummer ungetreten gültig

-

-

Nummer ungültig

Timeout aufgetreten

-

-

Timeout aufTimeout aufgetreten getreten Rufnr. zurücksetzen Timeout aufNummer ungetreten gültig

-

-

Nummer ungültig

Timeout aufgetreten

-

-

Ausgangszustand

Legende: Ereignis

Folgezustand Aktion(en)

Tabelle 2.5 Vollständige Zustandsübergangstabelle zum Zustandsautomaten nach Abb. 2.2

belle nach Tab. 2.5 enthält Einträge zu diesen Zustands-Ereignis-Paaren, so dass sie einerseits beim Testen nicht übersehen werden. Andererseits können sie aus Aufwandsgründen oft nicht alle getestet werden, so dass eine Auswahl getroffen werden muss. Würden alle Tabelleneinträge in Testfällen berücksichtigt, so müssten alle Ereignisse in allen Zuständen getestet werden. Das ist oft mit den zur Verfügung stehenden Ressourcen nicht möglich. Darüber hinaus ist dieser Test häufig nicht sinnvoll. Im Regelfall wird man drei Situationen in einem zustandsbasierten System unterscheiden wollen: >

Ereignisse, die, falls sie in einem betrachteten Zustand auftreten, einen Zustandsübergang und bzw. oder eine Aktion auslösen.

>

Ereignisse, die in einem betrachteten Zustand auftreten können, aber ignoriert werden.

>

Ereignisse, die, falls sie in einem betrachteten Zustand auftreten, eine Fehlerbehandlung erfordern.

Fallunterscheidung für die Verarbeitung von Ereignissen

Einerseits ist die letztgenannte Kategorie in dem Zustandsautomaten nach Abb. 2.2 und in den Zustandsübergangstabellen nicht berücksich-

2.3 Zustandsbasierter Test

63

tigt. Andererseits ist es sinnvoll, sie zu beachten. Während die Betätigung von Wähltasten (Ereignisse Ziffer0 bis Ziffer9) im Zustand Getrennt sinnlos aber möglich ist, deutet z. B. das Auftreten des Ereignisses Auflegen im Zustand Getrennt auf eine Fehlersituation hin, da der Hörer im Zustand Getrennt bereits aufgelegt ist. Eine Analyse der Zustandsübergangstabelle 2.5 im Hinblick auf derartige Situationen führt zur Zustandsübergangstabelle 2.6. Die in Tab. 2.6 dunkelgrau hinterlegten Felder beschreiben jeweils einen Zustandsübergang in den Fehlerzustand Fehlverhalten. Durch Hinzufügen des Fehlerzustands zum Zustandsautomaten erhält man den Zustandsautomaten nach Abb. 2.3, welcher der Zustandsübergangstabelle 2.6 entspricht.

2.3.3 Zustandsbasiertes Testen insbesondere im Modul- und Systemtest

Zustandsbasiertes Testen im objektorientierten Modultest

Bei großen Systemen: Verwendung hierarchischer Zustandsautomaten (so genannte state charts) /Harel 87/

64

Bewertung des zustandsbasierten Tests

Zustandsbasiertes Testen kann als Testtechnik insbesondere im Modultest und Systemtest eingesetzt werden. Zustandsautomaten besitzen in der Praxis eine weite Verbreitung, so dass die Basis für zustandsbasiertes Testen oft vorhanden sein wird. Insbesondere in technischen Anwendungsbereichen, z. B. der Automatisierungstechnik, sind Zustandsautomaten ein verbreitetes Beschreibungsmittel. Sie werden aber auch verbreitet in nicht-technischen Software-Entwicklungen, z. B. zur Beschreibung des Verhaltens grafischer Benutzungsoberflächen, eingesetzt. Moderne Software-Entwicklungsmethoden bieten zudem Zustandsautomaten oft als Beschreibungsmittel an. Als Beispiel seien die Zustandsautomaten der objektorientierten Technik UML (Unified Modeling Language) angeführt. Diese Zustandsautomaten dienen zur Beschreibung des Verhaltens einer Klasse. Sie bieten daher eine geeignete Grundlage für den objektorientierten Modultest. Neben zahlreichen Vorteilen besitzt zustandsbasiertes Testen auch einige Nachteile, die durch die Eigenschaften von Zustandsautomaten als Beschreibungsmittel verursacht werden. So tendieren Zustandsautomaten bei großen Systemen zu einer Explosion der Zustandsanzahl, die mit einer entsprechend starken Zunahme der Zustandsübergänge einhergeht. In derartigen Situationen ist durch zustandsbasiertes Testen nur noch eine sehr geringe Überdeckung der Zustandsautomaten möglich. Dies ist nicht als Schwäche des zustandsbasierten Tests sondern als Auswirkung eines unzureichenden Entwurfsprozesses zu werten. Ob Zustandsautomaten von Modulen hinreichend klein sind, um als Basis für den Test zu dienen, entscheidet sich in der Entwurfsphase bei der Festlegung der Software-Architektur. Es ist daher sinnvoll, einen Tester in die Entwurfsphase einzubinden – zumindest in die Inspektion der Entwurfsdokumente – dessen Aufgabe es ist, auf die Testbarkeit des Entwurfs zu achten. Beim Testen auf Basis von Zustandsautomaten sollten Normal- und Fehlerfälle betrachtet werden. Im Einzelnen schlage ich vor, die folgenden Regeln zu beachten:

2 Funktionsorientierter Test

Zustand

Getrennt

Wählend

Verbunden

Ereignis Wählend

FehlverRufnr. halten zurücksetzen

Abnehmen

Fehlverhalten

Auflegen

Fehlverhalten

-

Getrennt

Getrennt

Wählend

Ziffer 0

Ziffer z. Rufnr. Hinzuf., Rufnr. prüfen

-

Getrennt

Wählend

Ziffer 9

Ziffer z. Rufnr. hinzuf., Rufnr. prüfen

-

Timeout

Getrennt Fehlverhalten

Rufnummer gültig

Getrennt Fehlverhalten

Rufnummer ungültig

Getrennt Fehlverhalten

-

Fehlverhalten

-

Getrennt

Rufnr. zurücksetzen

-

Rufnr. zurücksetzen Verbind. abbauen

Verbunden

-

Verbunden

-

Timeout aufFehlvergetreten Rufnr. halten zurücksetzen Verbunden Verbindung aufbauen Nummer ungültig

-

Fehlverhalten Fehlverhalten

Nummer ungültig

-

Getrennt

Timeout aufgetreten Fehlverhalten

-

Getrennt

Rufnr. zurücksetzen Timeout aufNummer ungetreten gültig

-

-

Nummer ungültig

Timeout aufgetreten

-

-

Timeout aufTimeout aufgetreten getreten Rufnr. zurücksetzen

-

Fehlverhalten

-

Fehlverhalten

-

-

Fehlverhalten Fehlverhalten

-

Ausgangszustand

Legende: Ereignis

Folgezustand Aktion(en)

Tabelle 2.6 Zustandsübergangstabelle mit Fehlerzustand Timeout aufgetreten Timeout/ Rufnummer zurücksetzen

Auflegen Auflegen/ Rufnummer zurücksetzen

Wählend

Getrennt Abnehmen/ Rufnummer zurücksetzen

Ziffer 0, Ziffer 1, .. , Ziffer 9/ Ziffer zur Rufnummer hinzufügen, Rufnummer prüfen

Auflegen/ Rufnummer zurücksetzen

Rufnummer gültig/ Port_B berechnen Rufnummer ungültig

Abnehmen, Timeout, Rufnummer gültig, Rufnummer ungültig Timeout/ Rufnummer zurücksetzen

Nummer ungültig

Abnehmen, Rufnummer gültig, Rufnummer ungültig

Abnehmen, Rufnummer gültig, Rufnummer ungültig

Fehlverhalten

Abnehmen

Verbunden

Auflegen/ Rufnummer zurücksetzen

Auflegen, Timeout, Rufnummer gültig, Rufnummer ungültig

Abbildung 2.3 Zustandsautomat zur Zustandsübergangstabelle Tab. 2.6

2.3 Zustandsbasierter Test

65

Regeln für den zustandsbasierten Test

Beim Testen wird man alle Zustandsübergange – eventuell auch alle zugeordneten Ereignisse – berücksichtigen, die nicht in einen Fehlerzustand führen. Darüber hinaus wird man einen Teil der Ereignisse in jenen Zuständen testen, die weder einen Zustandswechsel noch eine Aktion bewirken. Ein Ereignis in bestimmten Situationen zu ignorieren, ist auch Funktionalität, deren korrektes Funktionieren keineswegs selbstverständlich ist. Für diese Fälle wird es oft erforderlich sein, eine Auswahl zu treffen, da die Berücksichtigung aller Fälle oft das Mengengerüst sprengt. Diese Auswahl erfordert inhaltliches Wissen über die gewünschte Funktionalität. So wird man bezogen auf das angeführte Telefonbeispiel z. B. testen wollen, ob die Betätigung von Zifferntasten im Zustand Verbunden tatsächlich ignoriert wird. Das ist wichtig für die korrekte Funktion, um z. B. mit einem Frequenzwahltelefon einen Anrufbeantworter fernsteuern zu können. Dass die Betätigung von Zifferntasten ignoriert wird, wenn bereits ein Timeout aufgetreten ist, ist sicherlich nicht besonders wichtig. Ich würde auf diesen Testfall verzichten. Der Test von Zustandsübergängen in Fehlerzustände wird nicht immer möglich sein, da die entsprechenden Ereignisse eigentlich nicht auftreten sollen. Man wird daher Schwierigkeiten haben, diese Testfälle herzustellen. Falls eine derartige Testsituation herstellbar ist, so sollte der Test durchgeführt werden. Anderenfalls ist sicherzustellen, dass die Situation SICHER nicht eintreten kann.

2.4

Die Ursache-WirkungsAnalyse betrachtet Kombinationen von Äquivalenzklassen.

Ursache-Wirkungs-Analyse

Die funktionale Äquivalenzklassenbildung betrachtet einzelne Eingabeoder Ausgabebedingungen. Beziehungen, Wechselwirkungen und Abhängigkeiten zwischen Äquivalenzklassen werden nicht beachtet. Gerade dies ist jedoch wichtig, da Fehler häufig an bestimmte Wertekombinationen unterschiedlicher Daten gebunden sind. Die geeignete Beachtung von Wertekombinationen ist schwierig, da häufig eine sehr hohe Anzahl von Kombinationsmöglichkeiten existiert. Die Ursache-Wirkungs-Analyse unterstützt die Auswahl sinnvoller Kombinationen. Die Ursache-Wirkungs-Analyse, die /Myers 76/ als Cause-Effect Graphing beschreibt, sieht eine formale, grafische Sprache als Hilfsmittel zur Wahl eines Satzes von Testfällen vor, die den angenehmen Nebeneffekt besitzt, Unvollständigkeiten und Widersprüche aufzudecken. Dieser Ursache-Wirkungs-Graph ist ein kombinatorisches logisches Netzwerk.

Vorgehensweise zur Erzeugung von Testfällen

66

Die Vorgehensweise zur Erzeugung von Testfällen nach dem Verfahren der Ursache-Wirkungs-Analyse sieht sechs Schritte vor:

2 Funktionsorientierter Test

1. Die Spezifikation ist in handhabbare Teile zu zerlegen, um die Kom-

binationsmöglichkeiten zu reduzieren und den Ursache-WirkungsGraph übersichtlich zu halten. 2. Die Ursachen und die Wirkungen jeder Teilspezifikation sind zu

identifizieren. Eine Ursache ist eine einzelne Eingabebedingung oder eine Äquivalenzklasse von Eingabebedingungen. Ursachen und Wirkungen besitzen stets einen Booleschen Wertebereich (z. B. Alter > 18, Zchn ist ein Vokal, Antrieb ist eingeschaltet). Eine Wirkung ist eine Ausgabebedingung oder eine Systemtransformation. Ursachen und Wirkungen werden durch Analysieren der Spezifikation identifiziert. In einer Spezifikation, die als Text vorliegt, können die Satzteile, die Ursachen bzw. Wirkungen beschreiben, z. B. mit unterschiedlichen Textmarkern markiert werden. Jeder Ursache und jeder Wirkung wird eine eindeutige Bezeichnung (z. B. eine Nummer) zugeordnet. 3. Durch Transformation der Spezifikation in einen Booleschen Gra-

phen, der Ursachen und Wirkungen durch logische Verknüpfungen verbindet, wird der Ursache-Wirkungs-Graph erzeugt. 4. In den Graphen werden Abhängigkeiten zwischen Ursachen und/o-

der Wirkungen eingetragen, die aufgrund von syntaktischen Zwängen oder Umgebungsbedingungen entstehen. So ist es z. B. möglich, dass bestimmte Kombinationen von Ursachen keinen Sinn ergeben. 5. Der Ursache-Wirkungs-Graph wird zu einer Entscheidungstabelle

umgeformt. 6. Aus jeder Spalte der Entscheidungstabelle wird ein Testfall erzeugt.

Die Basiselemente des Ursache-Wirkungs-Graphen sind die Symbole für Identität, Negation, das logische UND und das logische ODER (Abb. 2.4). Stellt man die Anwesenheit bzw. Abwesenheit von Ursachen und Wirkungen als 1 bzw. 0 dar, so kann man die Funktionalität der Basiselemente bezogen auf Abb. 2.4 auf folgende Weise beschreiben: >

Falls eine Ursache und eine Wirkung stets den gleichen Booleschen Wert besitzen, so besteht zwischen dieser Ursache und der Wirkung eine Identität.

>

Die Negation ist dann gegeben, falls eine Wirkung stets den zu einer Ursache inversen Booleschen Wert besitzt. Die Wirkung tritt dann auf, falls die Ursache nicht vorhanden ist, und sie bleibt aus, falls die Ursache vorhanden ist.

>

Tritt eine Wirkung ein, falls mindestens eine von mehreren Ursachen erfüllt ist, so liegt eine ODER-Beziehung vor.

2.4 Ursache-Wirkungs-Analyse

Die Basiselemente von Ursache-WirkungsGraphen: logische Verknüpfungen

67

Abbildung 2.4 Basiselemente des Ursache-Wirkungs-Graphen

>

Die UND-Funktion beschreibt den Eintritt einer Wirkung, falls mehrere Ursachen gleichzeitig erfüllt sein müssen.

Die in Abb. 2.4 angegebenen Verknüpfungen wirken von links nach rechts. Ursachen stehen links. Wirkungen stehen rechts. Um bei komplizierten Graphen Eindeutigkeit zu erreichen, kann die Wirkrichtung durch Pfeilspitzen angegeben werden. Zusätzliche Elemente von Ursache-WirkungsGraphen zur Notation von Einschränkungen

68

Neben diesen Basiselementen existieren zusätzliche Elemente, die ggf. Einschränkungen beschreiben, denen die Ursachen unterliegen (Abb. 2.5): >

Falls die Anwesenheit einer Ursache die Anwesenheit anderer Ursachen ausschließt, so besteht zwischen ihnen eine exklusive Abhängigkeit (E). Es ist entweder genau eine oder keine der verknüpften Ursachen wahr (z. B. Währung = US$, Währung = Euro: Die Währung ist entweder US$ oder Euro oder eine Andere)

>

Falls sichergestellt ist, dass stets mindestens eine von mehreren Ursachen erfüllt ist, so liegt eine inklusive Beziehung (I) vor (z. B. Ampelfarbe = grün, Ampelfarbe = gelb, Ampelfarbe = rot: Die Ampel zeigt mindestens eine der drei Farben; gelb und rot können aber auch zusammen auftreten).

>

Die O(One, and only one)-Abhängigkeit ist dann gegeben, falls immer genau eine von mehreren Ursachen erfüllt ist (z. B. Geschlecht = weiblich und Geschlecht = männlich: Das Geschlecht ist entweder weiblich oder männlich; andere Möglichkeiten existieren nicht).

>

Die R(Requires)-Abhängigkeit ist dann vorhanden, falls für die Anwesenheit einer bestimmten Ursache die Anwesenheit einer anderen Ursache Voraussetzung ist (z. B. Alter > 21 und Alter > 18: Eine Person kann nur älter als 21 Jahre sein, wenn sie älter als 18 Jahre ist).

2 Funktionsorientierter Test

Abbildung 2.5 Elemente zur Beschreibung von Abhängigkeiten

>

Die M(Masks)-Abhängigkeit beschreibt die Maskierung einer Ursache durch eine andere Ursache (z. B. Fehlermeldung „Kein Netz“ und Handy läutet: Das Vorliegen der Fehlermeldung „Kein Netz“ garantiert, dass das Handy nicht läutet). Wie man leicht sieht, kann die M-Abhängigkeit als R-Abhängigkeit ausgedrückt werden. Das Handy kann nur dann läuten, wenn die Fehlermeldung „Kein Netz“ nicht vorliegt. Das ist eine R-Abhängigkeit.

>

/Riedemann 97/ schlägt zusätzlich die IR(Irrelevant)-Abhängigkeit vor. Falls die unabhängige Ursache erfüllt ist, so kann die abhängige Ursache nicht bewertet werden (z. B. Dateiende erreicht und Datensatztyp = Geschäftskunde: Wenn das Dateiende erreicht wurde, so liegt kein gültiger Datensatz mehr vor, so dass der Datensatztyp nicht bewertet werden kann). Falls man der abhängigen Ursache in dieser Situation per Definition den Wert falsch zuweist, so kann die IR-Abhängigkeit als M-Abhängigkeit dargestellt werden.

Die Transformation des Ursache-Wirkungs-Graphen in eine Entscheidungstabelle erfolgt nach dem folgendem Verfahren: 1. Auswahl einer Wirkung

Transformation des Ursache-WirkungsGraphen in eine Entscheidungstabelle

2. Durchsuchen des Graphen nach Kombinationen von Ursachen, die

den Eintritt der Wirkung hervorrufen bzw. nicht hervorrufen 3. Erzeugung jeweils einer Spalte der Entscheidungstabelle für alle ge-

fundenen Ursachenkombinationen und die verursachten Zustände der übrigen Wirkungen. 4. Überprüfung, ob Entscheidungstabelleneinträge mehrfach auftreten

und ggf. Entfernen dieser Einträge. Die Ermittlung der Ursachenkombinationen nach Punkt 2 geschieht ausgehend von der betrachteten Wirkung in Richtung der Ursachen.

2.4 Ursache-Wirkungs-Analyse

69

>

Für ODER-Verknüpfungen mit dem Ergebnis 1 (die Wirkung tritt ein) sind nur solche Eingabekombinationen zu bilden, bei denen eine Eingabe den Wert 1 und alle anderen Eingaben den Wert 0 besitzen. Der Grund für diese Regel ist die Vermeidung von Fehlermaskierungen.

>

Für ODER-Verknüpfungen mit dem Ergebnis 0 (die Wirkung tritt nicht ein) sind alle Eingaben auf 0 zu setzen.

>

Für UND-Verknüpfungen mit dem Ergebnis 0 (die Wirkung tritt nicht ein) sind nur solche Eingabekombinationen zu bilden, bei denen eine Eingabe den Wert 0 und alle anderen Eingaben den Wert 1 besitzen. Der Grund für diese Regel ist die Vermeidung von Fehlermaskierungen.

>

Für UND-Verknüpfungen mit dem Ergebnis 1 sind alle Eingaben auf 1 zu setzen.

Aufwandsreduzierung von exponentiell auf linear!

Anstelle der für eine UND- bzw. ODER-Verknüpfung mit n Eingängen prinzipiell möglichen 2n Testfälle, erhält man durch Anwendung der angegebenen Regeln n + 1 Testfälle. Der Aufwand sinkt von dem vollständig unakzeptablen exponentiellen auf ein lineares Niveau. Dies ist eine wichtige Eigenschaft für die praktische Nutzbarkeit der Technik.

BEISPIELSPEZIFIKATION

Die Operation ZaehleZchn liest Zeichen von der Tastatur, solange große Konsonanten oder große Vokale eingegeben werden sowie Gesamtzahl kleiner ist als der Maximalwert des Datentyps integer. Ist ein gelesenes Zeichen ein großer Konsonant oder Vokal, so wird Gesamtzahl um eins inkrementiert. Falls das eingelesene Zeichen ein großer Vokal ist, so wird auch VokalAnzahl um eins inkrementiert. Für die Operation ZaehleZchn werden folgende Ursachen und Wirkungen identifiziert: Ursachen: U1 . Zchn ist ein großer Konsonant U2 . Zchn ist ein großer Vokal U3 . Gesamtzahl ist kleiner als der maximale Integerwert Wirkungen: W1 . Gesamtzahl wird inkrementiert W2 . VokalAnzahl wird inkrementiert W3 . Zchn wird gelesen W4 . Operation wird beendet Der Ursache-Wirkungs-Graph ist in Abb. 2.6 dargestellt. Man erkennt, dass die Wirkungen W1 und W3 in identischen Situationen eintreten bzw. nicht eintreten. Wirkung W4 tritt genau dann ein, wenn die Wirkungen W1 und W3 nicht eintreten und umgekehrt. Daher hält man für die drei Wirkungen W1 , W3 und W4 identische Testfälle. Es reicht daher aus, die Testfälle für die Wirkungen W1 und W2 zu erzeugen.

70

2 Funktionsorientierter Test

Abbildung 2.6 Ursache-Wirkungs-Graph zu ZaehleZchn

Betrachten wir zunächst den Eintritt der Wirkung W1 , d. h. W1 = 1. Wirkung W1 kommt durch eine UND-Verknüpfung der Zwischenwirkung Z1 und der Ursache U3 zustande. Entsprechend der oben angegebenen Regel für UND-Verknüpfungen sind alle Eingaben auf den Wert 1 zu setzen, d. h. Z1 = 1 und U3 = 1. Z1 wird durch eine ODER-Verknüpfung der Ursachen U1 und U2 erzeugt. Für ODER-Verknüpfungen mit dem Ergebnis 1 sind nur solche Eingabekombinationen zu bilden, bei denen eine Eingabe den Wert 1 und alle anderen Eingaben den Wert 0 besitzen. Es sind also die zwei Fälle U1 = 0 und U2 = 1 sowie U1 = 1 und U2 = 0 zu berücksichtigen. Der Fall U1 = 1 und U2 = 1, muss aufgrund der oben angegebenen Regel für die Behandlung von ODER-Verknüpfungen nicht beachtet werden. Da zwischen Ursache U1 und U2 eine exklusive Abhängigkeit besteht, ist diese Kombination auch prinzipiell nicht möglich. Nun ist noch der Nichteintritt von W1 zu betrachten, d. h. W1 = 0. Für UND- Verknüpfungen mit dem Ergebnis 0 sind nur solche Eingabekombinationen zu bilden, bei denen eine Eingabe den Wert 0 und alle anderen Eingaben den Wert 1 besitzen. Dies führt auf die Fälle Z1 = 0 und U3 = 1 sowie Z1 = 1 und U3 = 0. Die Zwischenwirkung Z1 tritt nicht ein, falls U1 und U2 nicht eintreten. Für den Fall Z1 = 1 sind die zwei Situationen U1 = 0 und U2 = 1 sowie U1 = 1 und U2 = 0 zu berücksichtigen. Da W3 identisch und W4 komplementär zu W1 ist ergeben sich identische Testsituationen, so dass auf die Analyse von W3 und W4 verzichtet werden kann. Für W2 erhält man durch Anwendung der oben angegebenen Regeln die Testsituationen U2 = 1 und U3 = 1, U2 = 0 und U3 = 1 sowie U2 = 1 und U3 = 0. Diese drei Fälle sind in den für W1 erzeugten Testsituationen bereits enthalten, so dass sie nicht explizit berücksichtigt werden müssen. Insgesamt erhält man daher die Entscheidungstabelle nach Tab. 2.7. Aus dieser Tabelle können die folgenden Testfälle abgeleitet werden:

2.4 Ursache-Wirkungs-Analyse

71

Tabelle 2.7 Entscheidungstabelle zum Ursachen-Wirkungs-Graphen

1. Aufruf und Übergabe eines kleinen Wertes für Gesamtzahl, z. B. Ge-

samtzahl = 0 Einlesen eines großen Vokals Einlesen eines großen Konsonanten Einlesen eines Zeichens, dass weder ein großer Vokal noch ein großer Konsonant ist 2. Aufruf und Übergabe des Maximalwertes für Gesamtzahl Einlesen

eines großen Vokals 3. Aufruf und Übergabe des Maximalwertes für Gesamtzahl Einlesen

eines großen Konsonanten Der erste Testfall entspricht den Spalten 1, 2 und 3 der Entscheidungstabelle. Die erste Spalte der Tabelle verlangt, dass Zchn ein großer Konsonant ist und der Wert von Gesamtzahl hinreichend klein ist. Dies kann z. B. durch Übergabe des Wertes 0 für Gesamtzahl und durch Eingabe des großen Konsonanten B für Zchn erfüllt werden. Für diese Testdaten treten die Wirkungen W1 und W3 ein. Die Variable Gesamtzahl wird inkrementiert, und ein weiteres Zeichen wird gelesen. Das nächste Zeichen muss entsprechend der zweiten Spalte der Entscheidungstabelle ein großer Vokal – z. B. der Großbuchstabe A – sein. Die dritte Spalte der Entscheidungstabelle fordert das Einlesen eines Zeichens, das weder ein großer Konsonant, noch ein großer Vokal ist. Dies erreicht man z. B. durch Eingabe einer 1. Der zweite Testfall fordert den Test der Operation ZaehleZchn mit dem Maximalwert von Gesamtzahl und die Eingabe eines großen Vokals. Er repräsentiert die vierte Spalte der Entscheidungstabelle. Der dritte Testfall entspricht der fünften Spalte der Entscheidungstabelle. Die Operation wird ebenfalls mit dem Maximalwert von Gesamtzahl gestartet. Die Variable Zchn erhält einen großen Konsonanten zugewiesen.

72

2 Funktionsorientierter Test

2.5

Weitere funktionsorientierte Testtechniken

Die Anzahl funktionsorientierter Testtechniken ist mindestens so groß wie die Anzahl unterschiedlicher Spezifikationstechniken. Testtechniken, welche die Verwendung einer bestimmten Spezifikationstechnik voraussetzen, sind natürlich nur dann anwendbar, wenn diese Spezifikationstechnik genutzt wird. Im Unterschied zu diesen spezifischen funktionsorientierten Testtechniken sind die in den Abschnitten 2.2 bis 2.4 dargestellten Techniken auf ganze Klassen von Systemen unabhängig von der verwendeten Spezifikationstechnik anwendbar. Im Folgenden werden einige spezifische funktionsorientierte Testtechniken erläutert.

2.5.1

Syntaxtest

Der Syntaxtest ist auf Software anwendbar, die syntaktische Analysen durchführt (siehe auch /Beizer 95/). Derartige Software findet sich in Form der so genannten Parser als Bestandteil von Compilern. Darüber hinaus erfordert jede Kommandoschnittstelle, bei deren Benutzung eine fest vorgegebene Syntax zu beachten ist, entsprechende Analysesoftware. Die Anwendung des Syntaxtests fordert die Spezifikation der Syntax in einer so genannten Backus-Naur-Form (BNF) oder in einer so genannten erweiterten Backus-Naur-Form (EBNF). Alternativ kann die Spezifikation in Form von Syntaxdiagrammen angegeben sein. Backus-Naur-Formen und Syntaxdiagramme sind alternative Darstellungsformen, die ineinander umgeformt werden können. Abb. 2.7 zeigt zwei Syntaxdiagramme. Sie geben die Syntax von Gleitkommazahlen in der Programmiersprache JAVA an. Syntaxdiagramme enthalten Pfeile, Terminalsymbole und Nicht-Terminalsymbole. Jedes Syntaxdiagramm trägt einen Namen. Terminalsymbole sind Bestandteil der Sprache. Nicht-Terminalsymbole sind syntaktische Hilfskonstrukte, die so lange durch die entsprechende Regel ersetzt werden, bis ausschließlich Terminalsymbole vorliegen. Ein syntaktisch korrekter Satzteil kommt durch Durchlaufen des Syntaxdiagramms in Pfeilrichtung und gegebenenfalls Ersetzen von Nicht-Terminalsymbolen zustande. Terminalsymbole sind in Abb. 2.7 als Kreis dargestellt. Nicht-terminale Symbole sind als Rechteck angegeben. Das Syntaxdiagramm in Abb. 2.7 stellt dar, dass eine syntaktisch korrekte Gleitkommazahl mit einem Terminalsymbol „+“ oder „-“, einem Punkt oder einer Ziffer beginnen kann. Da die Zeichen „+“, „-“ und „.“ Terminalsymbole sind, sind sie Bestandteil der Gleitkommazahl, während die Ziffer als Nicht-Terminalsymbol einer weiteren Verfeinerung, d. h. der Anwendung weiterer Regeln, bedarf. Die weiteren Bestandteile einer Gleitkommazahl erhält man durch einfaches Verfolgen eines Pfades durch das Diagramm in Pfeilrichtung. Jeder so erzeugte Pfad repräsentiert eine gültige Gleitkommazahl. Nicht-Terminalsymbole sind weiter zu verfeinern. In Abb. 2.8 ist das entsprechende Syntaxdiagramm

2.5 Weitere funktionsorientierte Testtechniken

Test von Syntaxanalyse-Software

Syntaxdiagramme als Basis für funktionsorientiertes Testen

Terminalsymbole vs. Nicht-Terminalsymbole

73

. f

+ Ziffer Ziffer

Exponent

Ziffer

d

.

Abbildung 2.7 Syntaxdiagramm für Java-Gleitkommazahlen

Abbildung 2.8 Syntaxdiagramm für Java-Exponenten

für das Nicht-Terminalsymbol Exponent aufgeführt. Falls die Syntaxbeschreibung in Backus-Naur-Form vorliegt, so ist für die Anwendung des Syntaxtests eine Transformation in Syntaxdiagramme vorzunehmen.

Textvollständigkeitskriterien für den Syntaxtest

Für alle grafischen Darstellungen können stets die gleichen Regeln zur Testfallerzeugung aufgeführt werden. Die minimale Anforderung heißt stets: Man decke durch Testfälle alle Knoten des Diagramms ab. Bezogen auf Syntaxdiagramme bedeutet diese Forderung, dass Pfade gesucht sind, die alle Nicht-Terminal- und alle Terminalsymbole mindestens ein Mal durchlaufen. Einen etwas umfassenderen Test ergibt der Durchlauf durch alle Kanten des Syntaxdiagramms. Da nicht jede Kante notwendig einen Knoten enthalten muss, werden Kanten ohne Knoten durch die Knotenüberdeckung nicht notwendig getestet. Die Überdeckung aller Kanten berücksichtigt auch derartige Kanten. Aber auch die Überdeckung aller Kanten besitzt gewisse Schwächen. Grundsätzlich wäre eine Überdeckung aller Pfade des Syntaxdiagramms erstrebenswert. Im Allgemeinen ist eine vollständige Pfadabdeckung aufgrund der Schleifen in Syntaxdiagrammen jedoch nicht erreichbar. Ein geeigneter Kompromiss sieht eine Pfadabdeckung außerhalb der Schleifen vor. Ergänzend treten Testfälle hinzu, die die Schleifen involvieren. Für das Syntaxdiagramm der Gleitkommazahl nach Abb. 2.7 erhält man insgesamt 37 Testpfade. In Abb. 2.9 ist eine Auswahl dieser Testpfade dargestellt. 36 Pfade testen außerhalb von Schleifen. Ein Durchlauf der 37 Testpfade ist mit den folgenden Testfällen möglich:

74

2 Funktionsorientierter Test

1.

-2.

+3.

.4

-.5

+.6

7.d

-8.d

+9.d

.1d

-.2d

+.3d

4.f

-5.f

+6.f

.7f

-.8f

+.9f

1.e2

-2.E2

+3.e-2

.4E-2

-.5e+2

+.6E+2

7.e22d

-8.e2d

+9.e2d

.1e2d

-.2e2d

+.3e2d

4.e2f

-5.e2f

+6.e2f

.7e2f

-.8e2f

+.9e2f

36 Testfälle außerhalb der Schleifen

37. Testfall mit Schleifendurchläufen

1234.56 Ein Durchlaufen aller Kanten des Syntaxdiagramms wäre mit einem Durchlauf dreier Testpfade möglich gewesen (Abb. 2.10). Als Testfälle können die folgenden Gleitkommazahlen verwendet werden: 1.

-11.11e2d

+.1f

Die auf Basis von Syntaxdiagrammen erzeugten funktionsorientierten Testfälle sind ausschließlich Normalfälle. Neben der Verarbeitung korrekter Syntax dient eine Syntaxanalyse-Software aber auch dazu, unkorrekte Syntax zu erkennen. Daher sind zusätzlich Testfälle für Fehlersituationen zu erzeugen. Hier liefert das Syntaxdiagramm keine direkte Unterstützung. Beim Testen unkorrekter Syntax ist es sinnvoll darauf zu achten, kleine Syntaxfehler zu erzeugen (z. B. Komma fehlt, Komma ist gegen Semikolon vertauscht). Ein sehr häufiger Fehler bei Software zur Syntaxanalyse ist die unkorrekte Behandlung so genannter Kontextbedingungen. Syntaxdiagramme beschreiben so genannte kontextfreie oder reguläre Sprachen. Die Kontextfreiheit ist aber in der Praxis nur näherungsweise gegeben. Für das hier verwendete Beispiel der Gleitkommazahlen existieren bestimmte Minimal- und Maximalwerte, über die das Syntaxdiagramm keine Aussage liefert. Der Test dieser Grenzen bietet sich daher an.

2.5.2

ACHTUNG: Fehlerfälle nicht vergessen

Transaktionsflussbasiertes Testen

Nach /Beizer 90/ ist eine Transaktion ein Verarbeitungsmodul aus der Sicht eines Systembenutzers. Transaktionen bestehen aus einer Sequenz von Verarbeitungsschritten. Eine transaktionsflussbasierte Systemsicht existiert sehr häufig in frühen Entwicklungsphasen bzw. späten Testphasen. Da es sich bei dieser Systemsicht um die Wahrnehmung eines Systems von außen handelt, passen transaktionsflussbasierte Testtechniken besonders gut zum Systemtest. Zur Notation von Transaktionsflüs-

2.5 Weitere funktionsorientierte Testtechniken

Transaktionen als Basis für den funktionsorientierten Test

75

+9.d

+.3d

+9.e2d

+.3e2d

1234.56

Abbildung 2.9 Testpfade für den Syntaxtest

sen existieren unterschiedliche Darstellungsformen. Beizer verwendet in /Beizer 90/ Flussdiagramme zur Notation von Transaktionsflüssen. Ich ziehe so genannte Sequenzdiagramme vor. Diese Diagrammform wird bereits seit langem zur Beschreibung des Verhaltens von Datenübertragungsprotokollen verwendet. Darüber hinaus ist sie als Sequence Chart Bestandteil der objektorientierten Methodik UML. Abb. 2.11 zeigt ein Sequenzdiagramm in Anlehnung an /Kauffels 99, S. 383/. Beispiel: Datenübertragung

76

Das Sequenzdiagramm nach Abb. 2.11 zeigt den Nachrichtenaustausch zwischen zwei so genannten HDLC-Protokollen auf zwei unterschiedlichen Stationen. Der Verbindungsaufbau geschieht durch eine einschlägige Aufforderung (SABM), die quittiert wird (UA). Anschließend werden Nutzdaten transferiert. Am Ende wird die Verbindung abgebaut (DISC)

2 Funktionsorientierter Test

. f

+ Ziffer Ziffer

Ziffer

.

Exponent d

1.

-11.11e2d

+.1f

Abbildung 2.10 Testpfade für den Syntaxtest

und der Abbau quittiert (UA). In Sequenzdiagrammen werden die unterschiedlichen beteiligten Instanzen in der Horizontalen nebeneinander geschrieben. Die Zeit schreitet von oben nach unten in vertikaler Richtung voran. Einerseits ist ein solches Diagramm eine gute Ausgangsbasis für die Erzeugung von Testfällen. Es gibt mögliche Testfälle direkt an. Andererseits haben Sequenzdiagramme in der Regel nur einen exemplarischen Charakter. So hätte in dem Sequenzdiagramm nach Abb. 2.11 die Aufforderung zum Verbindungsaufbau (SABM) nicht notwendig positiv quittiert werden müssen, sondern der Verbindungsaufbau hätte möglicherweise nicht zustande kommen können. Auch die zeitliche Reihenfolge des Versendens von Nachrichten, die Informationen tragen, und ihre Quittierung könnte anders vonstatten gehen als in Abb. 2.11 dargestellt. Trotz dieses exemplarischen Charakters der in Sequenzdiagrammen gezeigten Abläufe sind sie eine geeignete Ausgangsbasis für den Test. Es ist zu erwarten, das Sequenzdiagramme die besonders wichtigen Situationen beschreiben, deren Test notwendig geleistet werden muss. Im Hinblick auf die Vollständigkeit des funktionsorientierten Tests ist ein transaktionsflussbasierter Ansatz als notwendig, nicht aber als hinreichend zu bewerten. Der Test besteht in der Erzeugung der angegebenen Nachrichten, z. B. aus Sicht einer der beiden in Abb. 2.11 angegebenen Stationen, und der Überprüfung, ob die erzeugten Antworten, so wie im Sequenzdiagramm angegeben, zustande kommen. In Sequenzdiagrammen können grundsätzlich beliebig viele beteiligte Instanzen dargestellt werden. Die Grenze ist nur durch den Wunsch bestimmt, Übersichtlichkeit zu wah-

2.5 Weitere funktionsorientierte Testtechniken

VORSICHT: Sequenzdiagramme besitzen nur Beispielcharakter

77

ren. In der objektorientierten Methodik UML dienen Sequenzdiagramme zur Darstellung des Interagierens von Objekten. Abb. 2.12 stellt ein derartiges Sequenzdiagramm nach /Balzert 00, S. 211/ dar. Station A

Station B

SAB

M Aufbau

UA I(0,0 ) I(0,1 )

) I(1,0 I(1,2 )

Zeit

Daten

) RR(3 C S I D Abbau

UA

Abbildung 2.11 Sequenzdiagramm eines HDLC-Protokolls Bereits existierende Objekte Akteur

erstesObjekt :Klasse1

:Klasse2

Operation1() Klasse3()

Neu erzeugtes Objekt neuesObjekt :Klasse3

Botschaft

Operation5()

Objekt schickt Botschaft an sich selbst Operation3()

Operation2()

Objekt wird gelöscht

Balkenlänge gibt die relative Dauer der Aktivität an

Abbildung 2.12 Sequenzdiagramm in UML

78

2 Funktionsorientierter Test

2.5.3

Test auf Basis von Entscheidungstabellen oder Entscheidungsbäumen

Die Nutzung von Entscheidungstabellen oder Entscheidungsbäumen ist ein etablierter Ansatz für den funktionsorientierten Test. Einerseits gewährleisten Entscheidungstabellen und Entscheidungsbäume durch ihre Systematik eine gewisse Testvollständigkeit. Andererseits steigt der Umfang dieser Darstellungen exponentiell mit der Anzahl der Bedingungen. Für umfangreiche Darstellungen sind diese Techniken daher nur begrenzt geeignet. Tab. 2.8 spezifiziert, ob ein E-Commerce-Unternehmen Bestellungen per Rechnung abrechnet. Ob eine Zahlung per Rechnung möglich ist, richtet sich danach, ob der Kunde ein Erstkunde ist, ob der Bestellwert größer als 1000 e ist, und ob es sich um einen Privatkunden handelt. Die drei Bedingungen ergeben acht (23) Kombinationsmöglichkeiten. Diese sind in Tab. 2.8 dargestellt. Grundsätzlich könnte man jede der acht Spalten als Testfall berücksichtigen. Da die Anzahl der Spalten aber exponentiell von der Anzahl der Bedingungen abhängt, wird dies im Allgemeinen bei umfangreicheren Tabellen nicht möglich sein. Oft ist es möglich, Entscheidungstabellen zu vereinfachen. So stellt die optimierte Entscheidungstabelle nach Tab. 2.9 den gleichen Sachverhalt dar wie Tab. 2.8. Eine Zahlung per Rechnung ist nur dann nicht möglich, wenn ein Privatkunde erstmalig eine Bestellung im Wert von mehr als 1000 e tätigt. In allen anderen Fällen ist eine Zahlung per Rechnung möglich. Die acht Fälle aus Tab. 2.8 können daher auf vier Fälle komprimiert werden. Abb. 2.13 zeigt den entsprechenden Entscheidungsbaum. Jeder Weg von der Baumwurzel zu einem Blatt entspricht einem Testfall. Insgesamt erhält man daher vier Testfälle. Der Entscheidungsbaum fragt die so genannten „Don’t cares“ der Tab. 2.9 nicht ab oder belegt sie mit dem Wert „Ja“.

Entscheidungstabellen als Basis für den funktionsorientierten Test

So genannte „Don’t cares“ markieren unerhebliche Bedingungen. Sie gestatten die Optimierung von Entscheidungstabellen.

Hier ist zu erkennen, dass ein Test auf Basis optimierter Entscheidungstabellen Ähnlichkeiten zur Testplanung mit der Ursache-Wirkungs-Analyse besitzt. Die Ursache-Wirkungs-Analyse liefert ähnliche vier Testfälle wie der Entscheidungsbaum (Tab. 2.10). Der zugehörige Ursache-WirkungsGraph ist in Abb. 2.14 angegeben.

Tabelle 2.8 Entscheidungstabelle

2.5 Weitere funktionsorientierte Testtechniken

79

Tabelle 2.9 Optimierte Entscheidungstabelle

Kunde = Erstkunde J

N Rechnung ist möglich

Bestellwert > 1000 € N

J

Rechnung ist möglich N Rechnung ist möglich

Kundentyp = Privatkunde J Rechnung ist nicht möglich

Abbildung 2.13 Entscheidungsbaum

Tabelle 2.10 Testfälle nach der Ursache-Wirkungs-Analyse

Abbildung 2.14 Ursache-Wirkungs-Graph

80

2 Funktionsorientierter Test

2.6

Bewertung des funktionsorientierten Tests

Eine systematische funktionsorientierte Testplanung und Durchführung ist notwendiger Bestandteil jeder akzeptablen Testvorgehensweise. Alle Standards zur Software-Qualitätssicherung verlangen dies. Funktionsorientiertes Testen ist daher als unverzichtbarer Bestandteil jedes SoftwareEntwicklungsprozesses zu sehen. Die erfolgreiche Durchführung systematisch funktionsorientiert geplanter Testfälle vermittelt ein begründetes Vertrauen in die Software-Qualität.

Funktionsorientiertes Testen ist unverzichtbar.

Für die Auswahl einer bestimmten funktionsorientierten Testtechnik existieren in der Regel keine Vorschriften. Anders als bei den strukturorientierten Testtechniken existiert kein akzeptiertes Minimalkriterium. Das eingesetzte funktionsorientierte Testverfahren sollte daher im Hinblick auf seine Eignung für die Testaufgabe ausgewählt werden. Für die unterschiedlichen Testphasen – z. B. Modultest, Integrationstest und Systemtest – können unterschiedliche Testtechniken gewählt werden. Entscheidend ist, dass die Testtechnik zur Situation passt. Es ist zu erwarten, dass für den Test objektorientierter Software andere Techniken gewählt werden als für den Test klassischer Software. Während beim Test klassischer Software die funktionale Äquivalenzklassenanalyse eine sehr häufig eingesetzte Technik im Modultest ist, wird man für den objektorientierten Modultest – den Test von Klassen – häufig zustandsbasiertes Testen einsetzen. Das Verhalten von Objekten kann häufig gut mit Zustandsautomaten spezifiziert werden, die z. B. bei Nutzung der Technik UML bereits vorhanden sein werden und daher für den Test genutzt werden sollten. Da beim Integrationstest die möglichen, unterschiedlichen Situationen auf Schnittstellen zu unterscheiden sind, findet man hier sowohl in der objektorientierten wie auch in der klassischen Software-Entwicklung häufig die funktionale Äquivalenzklassenanalyse. In der Objektorientierung bietet sich bei Verwendung von Sequenzdiagrammen das geschilderte Verfahren zum transaktionsflussbasierten Testen auf Basis von Sequenzdiagrammen an.

Keine minimale funktionsorientierte Testtechnik

>

Prüfen Sie, in welcher Form Spezifikationen vorliegen (z. B. Zustandsautomaten, Entscheidungstabellen, Sequenzdiagramme usw.), und ob diese Spezifikationen für den Test genutzt werden können.

>

Überlegen Sie sich pro Testphase, welche Testsicht geeignet ist.

>

Planen Sie Ihre Testfälle unbedingt nach einer systematischen funktionsorientierten Technik.

2.6 Bewertung des funktionsorientierten Tests

CHECKLISTE

81

“This page left intentionally blank.”

3 Kontrollflussorientierter, strukturorientierter Test In diesem Kapitel werden dynamische Testtechniken beschrieben, welche die Vollständigkeit des Tests anhand der Abdeckung des Software-Quellcodes beurteilen. Daher bezeichnet man sie als strukturorientierte Testtechniken. Die beschriebenen Techniken basieren auf der Kontrollstruktur bzw. auf dem Kontrollfluss der zu testenden Software. Aus diesem Grund spricht man von kontrollflussorientierten, strukturorientierten Testtechniken. Diese Gruppe von Testtechniken besitzt eine hohe praktische Bedeutung. Das gilt insbesondere für ihren Einsatz im Modultest, das so genannte „Testen im Kleinen“. Die Gruppe der kontrollflussorientierten Testtechniken wird von Testwerkzeuganbietern gut unterstützt. Darüber hinaus gibt es im Bereich des kontrollflussorientierten Tests akzeptierte Minimalkriterien, die im Sinne eines adäquaten Tests beachtet werden sollten. Ein als minimal, d. h. notwendig akzeptiertes Testverfahren ist der so genannte Zweigüberdeckungstest. In besonders kritischen Anwendungsbereichen verlangen einschlägige Standards weitergehende Prüfungen. Ein Standard für Software-Anwendungen in der Avionik fordert z. B. einen so genannten Bedingungsüberdeckungstest. Bestimmte kontrollflussorientierte Testtechniken besitzen einen derartig grundlegenden Charakter, dass eine Prüfung als unzureichend bewertet werden muss, die auf die Anwendung dieser Techniken insbesondere im Modultest verzichtet.

Übersicht 3.1

Eigenschaften und Ziele des kontrollflussorientierten Tests . . 84

3.2

Anweisungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.3

Zweigüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.4

Bedingungsüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

3.5

Techniken für den Test von Schleifen . . . . . . . . . . . . . . . . . . . . . . . 117

3.6

Pfadüberdeckungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

3.7

Bewertung des kontrollflussorientierten Tests . . . . . . . . . . . . . . 138 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

83

3.1

Kontrollflussorientierte Testtechniken definieren keine Regeln für die Testdatenerzeugung.

Hauptanwendungsbereich: Modultest

Eigenschaften und Ziele des kontrollflussorientierten Tests

Die kontrollflussorientierten Testtechniken gehören zur Gruppe der strukturorientierten Testtechniken. Aus diesem Grund besitzen sie die entsprechenden Vor- und Nachteile. Die Testvollständigkeit wird anhand der Abdeckung der Kontrollstruktur oder des Kontrollflusses bewertet. Für die Beurteilung der Ausgaben ist eine entsprechende Spezifikation erforderlich. Kontrollflussorientierte Testtechniken definieren, wie alle strukturorientierten Testtechniken, keine Regeln für die Erzeugung von Testfällen. Es ist lediglich wichtig, dass die – wie auch immer erzeugten – Testfälle entsprechende Abdeckungen in der Struktur hervorrufen. Dieser Freiheitsgrad bezüglich der Testfallerzeugung ist ausgesprochen wichtig, da er es ermöglicht, andere Techniken zur Testfallerzeugung mit strukturorientierten Testtechniken zu kombinieren. Der wichtigste Anwendungsbereich der kontrollflussorientierten Testtechniken ist der Modultest. Kontrollflussorientierte Testtechniken können im Integrationstest noch eine gewisse Bedeutung besitzen, während sie im Systemtest nicht eingesetzt werden. Kontrollflussorientierte Testtechniken betrachten die Struktur des Codes. Im Einzelnen werden Aspekte der Verarbeitungslogik beachtet, die in der Software als Anweisungen, Zweige, Bedingungen, Schleifen oder Pfade repräsentiert sind. Pfad

(int VokalAnzahl, nstart void ZaehleZchn (int& int& Gesamtzahl) { char Zchn; cin >> Zchn;

n1 Zweig, Kante Anweisung, Knoten

while ((Zchn >=‘A‘) && (Zchn > Zchn; Zchn

n5

} nfinal }

Abbildung 3.1 Kontrollflussgraph

84

3 Kontrollflussorientierter, strukturorientierter Test

Nachteilig ist, dass diese Vorgehensweise blind gegenüber Auslassungsfehlern in der Software ist. Nicht realisierte aber spezifizierte Funktionen werden nur zufällig erkannt, da für diese Funktionen kein zu überdeckender Code vorhanden ist. Die Testgrundlage bildet der so genannte Kontrollflussgraph (8.3.2.1). Der Kontrollflussgraph kann für jedes in einer imperativen Programmiersprache realisierte Programm erstellt werden. Aus diesem Grund sind die kontrollflussorientierten Testtechniken über die Darstellung eines zu testenden Software-Moduls als Kontrollflussgraph auf alle in einer imperativen Sprache erstellten Programme gleichermaßen anwendbar. Abb. 3.1 zeigt den Kontrollflussgraph zu der Operation ZaehleZchn. Werkzeuge zur Unterstützung kontrollflussorientierter Testtechniken erzeugen in der Regel derartige Kontrollflussgraphen und verwenden sie zur Darstellung der Testergebnisse.

3.2 3.2.1

Testgrundlage: Kontrollflussgraph

Anweisungsüberdeckungstest Eigenschaften und Ziele des Anweisungsüberdeckungstests

Der Anweisungsüberdeckungstest ist die einfachste kontrollflussorientierte Testmethode. Er wird abkürzend auch als C0 -Test bezeichnet. Im Englischen bezeichnet man den Anweisungsüberdeckungstest als statement coverage test. Das Ziel der Anweisungsüberdeckung ist die mindestens einmalige Ausführung aller Anweisungen des zu testenden Programms, also die Abdeckung aller Knoten des Kontrollflussgraphen. Als Testmaß wird der erreichte Anweisungsüberdeckungsgrad definiert. Er ist das Verhältnis der ausgeführten Anweisungen zu der Gesamtzahl der im Prüfling vorhandenen Anweisungen. CAnweisung =

Anweisungsüberdeckungsgrad

Anzahl der ausgeführten Anweisungen Anzahl der Anweisungen

Sind alle Anweisungen des zu testenden Moduls durch die eingegebenen Testdaten mindestens einmal ausgeführt worden, so ist eine vollständige Anweisungsüberdeckung erreicht.

Der Anweisungsüberdeckungstest verlangt die Abdeckung aller Knoten des Kontrollflussgraphen, die in Abb. 3.2 hervorgehoben dargestellt sind. Von den Testfällen wird verlangt, dass die entsprechenden Programmpfade alle Knoten des Kontrollflussgraphen enthalten. In dem Kontrollflussgraph nach Abb. 3.2 ist das z. B. mit dem folgenden Testfall möglich:

3.2 Anweisungsüberdeckungstest

BEISPIEL

85

Aufruf von ZaehleZchn mit: Gesamtzahl = 0 Eingelesene Zeichen: ’A’, ’1’ Durchlaufener Pfad: (nstart , n1 , n2 , n3 , n4 , n5 , n2 , n f inal ) Der Testpfad enthält alle Knoten. Er enthält aber nicht alle Kanten des Kontrollflussgraphen. Die Kante (n3 , n5 ), die dem optionalen else-Teil der einfachen Verzweigung entspricht, ist nicht enthalten. Da der else-Teil in der Verzweigung des Beispiels nicht genutzt wird, ist ihm keine Anweisung zugeordnet, die durch die Anweisungsüberdeckung ausgeführt werden muss. Im Kontrollflussgraph existiert jedoch eine Kante, die den Knoten n5 umgeht und die durchlaufen wird, falls die Verzweigungsbedingung den Wahrheitswert falsch ergibt.

n1

nstart void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl) { char Zchn; cin >> Zchn; while ((Zchn >=‘A‘) && (Zchn > Zchn;

n5

} nfinal }

Zweig (n3,n5) wird nicht notwendig ausgeführt

Abbildung 3.2 Kontrollflussgraph – Anweisungsüberdeckung

3.2.2

Beschreibung des Anweisungsüberdeckungstests

Die Strategie, alle Anweisungen, die ein Programmierer zu einem Programm zusammengefügt hat, mindestens einmal mit Testdaten auszuführen, ist direkt einsichtig. Sie stellt sicher, dass in der zu testenden Software keine Anweisungen existieren, die niemals ausgeführt worden sind. Einerseits ist die Ausführung einer Anweisung sicherlich ein notwendiges Kriterium, das zu erfüllen ist, um einen in der Anweisung enthalte-

86

3 Kontrollflussorientierter, strukturorientierter Test

nen Fehler zu finden. Andererseits ist dies kein hinreichendes Kriterium. Das Auftreten der Fehlerwirkung kann z. B. an die Ausführung mit bestimmten Testdaten gekoppelt sein.

Angenommen ein Software-Modul enthält die fehlerhafte Entscheidung (x > 5). Korrekterweise müsste die Entscheidung (x ≥ 5) heißen. Die fehlerhafte Entscheidung kann mit jedem Wert von x mit Ausnahme des Wertes 5 ausgeführt werden, ohne dass ein Fehlverhalten auftritt. Die fehlerhafte und die korrekte Entscheidung verhalten sich für alle Werte mit Ausnahme des Wertes 5 identisch. Eine alleinige Ausführung der fehlerhaften Stelle garantiert demzufolge nicht, dass ein Fehlverhalten auftritt und der Fehler erkannt wird.

BEISPIEL

Auch wenn das Fehlverhalten aufgetreten ist, so kann nicht garantiert werden, dass es von der testenden Person erkannt wird. Die fehlerhafte Situation muss sich an eine von außen beobachtbare Stelle fortpflanzen. Der Anweisungsüberdeckungstest versucht – wie alle Überdeckungstests – das notwendige Kriterium der Ausführung potentiell fehlerhafter Stellen der Software zu erfüllen. Die Ausführung aller Anweisungen ist Bestandteil fast aller wichtigen Testverfahren, die zusätzlich weitere Aspekte beachten. Der Anweisungsüberdeckungstest nimmt als eigenständiges Testverfahren eine untergeordnete Stellung ein und wird nur von wenigen Werkzeugen direkt unterstützt. Der Anweisungsüberdeckungstest bietet die Möglichkeit, nicht ausführbare Anweisungen (sog. „toten Code“) aufzuspüren. Das Anweisungsüberdeckungsmaß kann zur Quantifizierung der erreichten Testabdeckung genutzt werden.

3.2.3

Bewertung des Anweisungsüberdeckungstests

Der Anweisungsüberdeckungstest ist selten die Hauptfunktion von Testwerkzeugen. Er tritt als Nebenprodukt von Werkzeugen zur Unterstützung des Zweigüberdeckungstests und anderen Testwerkzeugen auf. Der Anweisungsüberdeckungstest gilt als zu schwaches Kriterium für eine sinnvolle Testdurchführung. Er besitzt eine untergeordnete praktische Bedeutung.

Der Anweisungsüberdeckungstest gilt als zu schwach.

Das Minimalkriterium der kontrollflussorientierten Testtechniken ist der so genannte Zweigüberdeckungstest, der den Anweisungsüberdeckungstest enthält. Daher ist von der Verwendung des Anwendungsüberdeckungstests als strukturorientiertes Testvollständigkeitskriterium abzuraten.

3.2 Anweisungsüberdeckungstest

87

/Girgis, Woodward 86/ haben empirische Untersuchungen bezüglich einiger unterschiedlicher Testansätze durchgeführt. Unter den verglichenen kontrollstrukturorientierten Verfahren besitzt die Anweisungsüberdeckung mit 18 % der enthaltenen Fehler die geringste Fehleridentifizierungsquote. Der Standard RTCA DO-178B für Software-Anwendungen in der Luftfahrt fordert den Anweisungsüberdeckungstest für Software ab Stufe C. Derartige Software kann im Falle eines Fehlverhaltens einen bedeutenden Ausfall (major failure condition) verursachen.

3.3 3.3.1

Der Zweigüberdeckungstest ist ein Minimalkriterium.

Zweigüberdeckungstest Eigenschaften und Ziele des Zweigüberdeckungstests

Der Zweigüberdeckungstest ist eine strengere Testtechnik als der Anweisungsüberdeckungstest. Der Anweisungsüberdeckungstest ist im Zweigüberdeckungstest vollständig enthalten. Man sagt auch: Der Zweigüberdeckungstest subsumiert den Anweisungsüberdeckungstest. Der Zweigüberdeckungstest gilt allgemein als das Minimalkriterium im Bereich des kontrollflussorientierten Testens. Man bezeichnet ihn auch abkürzend als C1 -Test. Im Englischen wird der Begriff branch coverage test verwendet. Das Ziel des Zweigüberdeckungstests ist die Ausführung aller Zweige des zu testenden Programms. Das verlangt den Durchlauf durch alle Kanten des Kontrollflussgraphen /Myers 79/. Für die Zweigüberdeckung wird üblicherweise als einfaches Maß das Verhältnis der Anzahl der ausgeführten Zweige zu der Anzahl der in der zu testenden Software vorhandenen Zweige benutzt.

3.3.2

Beschreibung des Zweigüberdeckungstests

Der Zweigüberdeckungstest gilt als das minimale Testkriterium. Die zentrale Stellung des Zweigüberdeckungstests wird insbesondere durch seine Position innerhalb der Testverfahren verdeutlicht. Als notwendige Testtechnik wird er durch die meisten anderen Testverfahren subsumiert (Abb. 3.16). Der Zweigüberdeckungstest bildet die größte gemeinsame Teilmenge aller dieser Testtechniken. Der Zweigüberdeckungstest bietet die Möglichkeit zum Aufspüren von nicht ausführbaren Programmzweigen. Dies ist der Fall, wenn keine Testdaten erzeugt werden können, die die Ausführung eines bisher nicht durchlaufenen Zweiges bewirken. Besonders oft durchlaufene SoftwareTeile können erkannt und gezielt optimiert werden. In einigen Fällen kann es aus unterschiedlichen Gründen schwierig sein, alle Programmzweige auszuführen. Oft sind nicht ausgeführte Zweige

88

3 Kontrollflussorientierter, strukturorientierter Test

ausführbar, und die Testfälle sind schwierig zu erzeugen, z. B. weil Betriebssystemzustände oder Dateikonstellationen mit vertretbarem Aufwand nicht herzustellen sind, oder die Testfälle aus dem Programm selbst schwer herleitbar sind. Zweige können aber auch prinzipiell nicht ausführbar sein. Die Ursache kann z. B. ein Entwurfsfehler sein, der zu einem überflüssigen Zweig geführt hat.

Der Zweigüberdeckungstest fordert die Überdeckung aller Zweige des Kontrollflussgraphen nach Abb. 3.3. Dies ist z. B. mit dem folgenden Testfall möglich:

BEISPIEL

Aufruf von ZaehleZchn mit: Gesamtzahl = 0 Eingelesene Zeichen: ’A’, ’B’, ’1’ Durchlaufener Pfad: (nstart , n1 , n2 , n3 , n4 , n5 , n2 , n3 , n5 , n2 , n f inal ) Der Testpfad enthält alle Kanten. Er enthält insbesondere die Kante, die durch den Anweisungsüberdeckungstest nicht notwendig ausgeführt wird. Der Zweigüberdeckungstest wird auch als Entscheidungsüberdeckung bezeichnet, da jede Entscheidung beim Test die Wahrheitswerte wahr und falsch mindestens einmal annehmen muss. Das Durchlaufen aller Zweige verursacht die Ausführung aller Anweisungen. Der Zweigüberdeckungstest subsumiert den Anweisungsüberdeckungstest.

n1

nstart void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl) { char Zchn; cin >> Zchn;

n2

while ((Zchn >=‘A‘) && (Zchn > Zchn; } nfinal }

Abbildung 3.3 Kontrollflussgraph – Zweigüberdeckung

3.3 Zweigüberdeckungstest

89

3.3.3 Der Zweigüberdeckungstest ist ungeeignet für den Test zusammengesetzter Entscheidungen und für den Test von Schleifen.

Problematiken des Zweigüberdeckungstests

Wie für den Anweisungsüberdeckungstest gilt auch für den Zweigüberdeckungstest, dass auch eine Software mit einer Überdeckungsrate von 100 % nicht notwendig fehlerfrei sein muss. Weder Kombinationen von Zweigen noch kompliziert aufgebaute Entscheidungen werden berücksichtigt. Auch Schleifen werden nicht ausreichend getestet, da ein einzelner Durchlauf durch den Schleifenkörper von abweisenden Schleifen und eine Wiederholung von nicht abweisenden Schleifen für die Zweigüberdeckung hinreichend ist. Im Zusammenhang mit dem Test von Schleifen ist insbesondere kritisch, dass eine beliebige, willkürlich gewählte Anzahl von Schleifenwiederholungen das Zweigüberdeckungskriterium erfüllt. Dies ist keine akzeptable Eigenschaft eines Kriteriums für den Test von Schleifen. Leistungsfähigere kontrollflussorientierte Testtechniken sehen an diesen Stellen Erweiterungen vor und versuchen Schleifen geeigneter zu überprüfen, den Abhängigkeiten zwischen Zweigen Rechnung zu tragen oder zusammengesetzte Entscheidungen näher zu analysieren.

Es gibt einen nichtlinearen Zusammenhang zwischen Überdeckungsrate und Testfallanzahl.

Als problematisch erweist sich das einfache Zweigüberdeckungsmaß. Da alle Zweige gleich gewichtet werden, ohne Abhängigkeiten zwischen ihnen zu berücksichtigen, entsteht kein linearer Zusammenhang zwischen der erreichten Überdeckungsrate und dem Verhältnis zwischen der Anzahl der dazu benötigten Testfälle und der Anzahl der Testfälle, die für 100 % Zweigüberdeckung notwendig sind (Abb. 3.4). Die unkritische Benutzung des einfachen Überdeckungsmaßes führt zu einer Überschätzung der durchgeführten Testaktivitäten, da die Überdeckungsrate stets größer ist, als die Anzahl der bisher durchgeführten Testfälle bezogen auf die Gesamtzahl der Testfälle bei vollständiger Überdeckung aller Zweige. Die Ursache ist, dass jeder Testfall eine Folge von Zweigen ausführt, von denen ein Anteil im Allgemeinen nicht allein zu einem Pfad gehört, sondern Bestandteil mehrerer Pfade und damit mehrerer Testfälle ist. Die zu Beginn des Tests durchgeführten Testfälle überdecken bereits eine große Anzahl dieser Zweige. Nach wenigen Testläufen wird eine verhältnismäßig hohe Überdeckungsrate erreicht. Die restlichen Testfälle überdecken diese Zweige ebenfalls, erhöhen aber die Überdeckungsrate lediglich durch Ausführung der nicht in den bereits getesteten Pfaden enthaltenen Zweige. Daher werden am Ende des Tests relativ viele Testfälle benötigt, um eine geringe Steigerung der Überdeckungsrate zu erreichen. Ein Lösungsansatz dieser Problematik betrachtet die Ausführungsabhängigkeiten zwischen Zweigen als Kriterium für die Einflussnahme auf das Überdeckungsmaß /Chusho 87/. Ein Zweig wird nicht berücksichtigt, falls er immer dann ausgeführt wird, wenn ein anderer Zweig ausgeführt wird. Die Zweige, die diese Eigenschaft nicht besitzen, heißen primitiv oder essentiell. Da die Ausführung der primitiven Zweige aufgrund der

90

3 Kontrollflussorientierter, strukturorientierter Test

Überdeckungsrate

100 %

beobachteter Anstieg der Überdeckungsrate mit der Anzahl der Test fälle

linearer Anstieg der Überdeckungsrate mit der Anzahl der Testfälle

aktuelle Testfallanzahl Testfallanzahl für 100 % Überdeckungsrate

Abbildung 3.4 Überdeckungsrate als Funktion der Testfallanzahl

beschriebenen Abhängigkeit die Ausführung aller nicht primitiven Zweige sicherstellt, ist es hinreichend nur die primitiven Zweige für die Berechnung des Überdeckungsmaßes zu benutzen. Es kann dann ein Überdeckungsmaß C primitiv =

Anzahl ausgeführter primitiver Zweige Anzahl primitiver Zweige

eingeführt werden. C primitiv ergibt ein lineareres Verhältnis zwischen Überdeckung und Testfallanzahl als das einfache Überdeckungsmaß. Außerdem muss nur ein Teil der Zweige – Untersuchungen /Chusho 87/ haben ca. 60 % ergeben – instrumentiert werden, was den durch die Instrumentierung verursachten Aufwand entsprechend senkt.

3.3.4

Bewertung des Zweigüberdeckungstests

Der Zweigüberdeckungstest ist das Minimalkriterium des strukturorientierten Software-Tests. Der Standard RTCA DO-178B für Software-Anwendungen im Bereich der Luftfahrt schreibt einen Zweigüberdeckungstest für Software ab Stufe B vor /RTCA DO-178B 92/. Ein Fehlverhalten derartiger Software könnte eine Systemfehlfunktion verursachen, die eine schwere Ausfallbedingung des Luftfahrzeuges verursachen würde.

3.3 Zweigüberdeckungstest

91

Die Leistungsfähigkeit des Zweigüberdeckungstests ist in einigen empirischen Studien untersucht worden, die zu recht unterschiedlichen Aussagen gelangen. Howden hat durch einen Zweigüberdeckungstest von 28 Fehlern in sechs Programmen sechs Fehler entdeckt /Howden 78a, Howden 78b,Howden 78c/. Diese Erfolgsquote von 21 % deckt sich im Wesentlichen mit jenen 25 % die /Gannon 79/ in einer Studie, die Zweigtest und statische Analyse gegenüberstellt, angibt. Eine frühere Untersuchung von /Gannon 78/, die sich auf Zweigtest und statische Analyse bezogen auf acht kleinere Programme stützt, hat eine Quote von 70 % entdeckter Fehler mit Hilfe der Zweigüberdeckung ergeben. In beiden Studien ist die Erfolgsquote der Zweigüberdeckung höher als die der statischen Analyse. Eine Betrachtung der Typen der gefundenen Fehler in Abhängigkeit des eingesetzten Testverfahrens zeigt eine gute Leistungsfähigkeit des Zweigüberdeckungstests bei der Behandlung von logischen Fehlern und Fehlern bei Berechnungen und einen Einbruch bei der Entdeckung von Datenfehlern. In der Studie von /Girgis, Woodward 86/ ist für die Zweigüberdeckung eine Trefferquote von 34 % angegeben – eine gegenüber der Anweisungsüberdeckung um 16 % höhere Quote. Die Zweigüberdeckung findet hier 79 % der Kontrollflussfehler und 20 % der Berechnungsfehler. In der Literatur existieren Angaben zur Leistungsfähigkeit der Zweigüberdeckung, die in einem weiten Bereich streuen. Es existiert eine sehr gute Werkzeugunterstützung des Zweigüberdeckungstests.

Für den Zweigüberdeckungstest existiert eine Vielzahl von unterstützenden Werkzeugen für unterschiedliche Programmiersprachen. Derartige Werkzeuge arbeiten in der Regel instrumentierend. Das Werkzeug analysiert die Kontrollstruktur des im Quellcode vorliegenden SoftwareModuls, lokalisiert Zweige und fügt zusätzliche Anweisungen (Zähler) ein, die es gestatten, den Kontrollfluss zu verfolgen. Falls Zweige nicht durch korrespondierende Anweisungen im Programmtext vertreten sind, z. B. bei Nichtbenutzung des optionalen else-Konstruktes einer Verzweigung, so wird eine entsprechende Anweisung von dem Werkzeug erzeugt. Die instrumentierte Version des Prüflings wird compiliert und das erzeugte ablauffähige Programm mit Testdaten ausgeführt. Die während der Testläufe durch die hinzugefügten Anweisungen gesammelten Informationen können anschließend ausgewertet werden. Für nicht durchlaufene Zweige müssen weitere Testfälle erzeugt werden. Zusätzlich kann das Werkzeug den erreichten Zweigüberdeckungsgrad anzeigen. Einige Werkzeuge bieten die Möglichkeit zur Darstellung der durch den zuletzt eingegebenen Testfall ausgeführten Zweige, die insbesondere zur Überprüfung des Kontrollflusses dient, und führen eine Gesamtstatistik zur Identifikation von nicht ausgeführten Zweigen und besonders häufig durchlaufenen Programmteilen.

EMPFEHLUNG: Zweigüberdeckungstest unbedingt nutzen

92

Aufgrund der Bedeutung des Zweigüberdeckungstests als notwendiges Testkriterium und der hervorragenden Verfügbarkeit von entsprechen-

3 Kontrollflussorientierter, strukturorientierter Test

den Testwerkzeugen empfehle ich Ihnen, diese Technik unbedingt einzusetzen. Dies sollte in jedem Falle werkzeugunterstützt geschehen. Eine Durchführung strukturorientierter Tests ohne Werkzeugunterstützung ist grundsätzlich nicht sinnvoll.

3.4 3.4.1

Bedingungsüberdeckungstest Eigenschaften und Ziele des Bedingungsüberdeckungstests

Der Bedingungsüberdeckungstest beachtet die logische Struktur von Entscheidungen der zu testenden Software. Im Englischen bezeichnet man den Bedingungsüberdeckungstest als condition coverage test. Es existieren unterschiedliche Ausprägungen, von denen die schwächste – der einfache Bedingungsüberdeckungstest (simple condition coverage test) – nicht den Anweisungs- und Zweigüberdeckungstest subsumiert. Der so genannte Mehrfach-Bedingungsüberdeckungstest (multiple condition coverage test) subsumiert die Zweigüberdeckung, besitzt jedoch andere Schwächen, die im Folgenden noch näher erläutert werden. Einen praktikablen Mittelweg stellen der minimale Mehrfach-Bedingungsüberdeckungstest (minimal multiple condition coverage test) und der so genannte modified condition/decision coverage test dar.

Der Bedingungsüberdeckungstest beachtet die Struktur von Entscheidungen.

Die Grundidee der Bedingungsüberdeckungstests ist die gründliche Überprüfung zusammengesetzter Entscheidungen der zu testenden Software. Für einen vollständigen Zweigüberdeckungstest ist es hinreichend, dass die Auswertung aller Entscheidungen einmal den Wert wahr und einmal den Wert falsch liefert. Diese Strategie berücksichtigt nicht den oft komplizierten Aufbau der Entscheidungen, die häufig in mehreren Ebenen geschachtelte logische Verknüpfungen von Teilentscheidungen enthalten. Entscheidungen sind oft aus Teilentscheidungen aufgebaut, die durch logische Operatoren verknüpft sind. Besteht eine Entscheidung oder eine Teilentscheidung nicht aus untergeordneten Teilentscheidungen, so wird sie als atomare Entscheidung bezeichnet.

Einfache Entscheidung: if (x > 5)...; Die Entscheidung (x > 5) kann als ausreichend getestet betrachtet werden, falls beide Wahrheitswerte beim Test aufgetreten sind. Die Entscheidung unterteilt die möglichen Testdaten in zwei Klassen und verlangt, dass mindestens ein Testdatum aus jeder Klasse gewählt wird.

BEISPIEL

Komplexe Entscheidung: if (((u == 0)||(x > 5))&&((y < 6)||(z == 0)))... Ein Test der Entscheidung (((u == 0)||(x > 5))&&((y < 6)||(z == 0)))

3.4 Bedingungsüberdeckungstest

93

gegen beide Wahrheitswerte kann nicht als hinreichend betrachtet werden, da die Struktur der Entscheidung nicht geeignet beachtet wird. Ein vollständiger Zweigüberdeckungstest kann z. B. mit den folgenden Testfällen erreicht werden: Testfall 1: u = 1, x = 4, y = 5, z = 0 Testfall 2: u = 0, x = 6, y = 5, z = 0 Nehmen wir an, dass zusammengesetzte Entscheidungen von links nach rechts geprüft werden und dass die Prüfung beendet wird, wenn der Wahrheitswert der Gesamtentscheidung bekannt ist. Man bezeichnet das als unvollständige Evaluation von Entscheidungen. Testfall 1 führt dann zu folgender Situation: Der Wert 1 der Variable u ergibt für die erste Teilentscheidung der ODER-Verknüpfung den Wahrheitswert falsch. Daher bestimmt die zweite Teilentscheidung der ODER-Verknüpfung den Wahrheitswert der ODER-Verknüpfung. Die Wahl des Wertes 4 für die Variable x ergibt eingesetzt in die erste Teilentscheidung (x > 5) ebenfalls den Wahrheitswert falsch. Die Verknüpfung der ersten beiden Entscheidungen besitzt ebenfalls den Wahrheitswert falsch. Aufgrund der darauf folgenden UND-Verknüpfung ist unabhängig von den Wahrheitswerten der anderen Teilentscheidungen zu diesem Zeitpunkt bereits bekannt, dass die Gesamtentscheidung den Wahrheitswert falsch besitzen wird. In vielen Fällen werden die Wahrheitswerte der verbleibenden – weiter rechts stehenden – Teilentscheidungen nicht mehr geprüft. Unabhängig davon, ob sie geprüft werden, maskiert der Wahrheitswert falsch für die erste Teilentscheidung in einer UND-Verknüpfung die Wahrheitswerte aller weiteren Teilentscheidungen. Dieser Testfall ist daher „blind“ gegenüber Fehlern in den verbleibenden Teilentscheidungen. Testfall 2 verursacht die folgende Situation: Die Wahl des Wertes 0 für die Variable u führt dazu, dass die erste Teilentscheidung (u == 0) den Wahrheitswert wahr besitzt. Aufgrund der ODER-Verknüpfung der ersten beiden Teilentscheidungen ist sichergestellt, dass das Ergebnis der ersten ODER-Verknüpfung wahr ist. Die zweite Teilentscheidung muss nicht geprüft werden. Die Prüfung kann direkt mit der ersten Teilentscheidung der zweiten ODER-Verknüpfung fortgesetzt werden. Der Wahrheitswert der zweiten ODER-Verknüpfung bestimmt das Gesamtergebnis. Der Wert 5 der Variable y verursacht den Wahrheitswert wahr für die Teilentscheidung (y < 6). Diese Teilentscheidung ist mit der vierten Teilentscheidung ODER-verknüpft. Daher ist zu diesem Zeitpunkt sichergestellt, dass das Gesamtergebnis unabhängig vom Wahrheitswert der vierten Teilentscheidung wahr sein wird. Daher ist dieser Testfall „blind“ gegenüber Fehlern in der vierten Teilentscheidung. Die Testfälle 1 und 2 bewirken eine vollständige Zweigüberdeckung. Keiner der beiden Testfälle prüft die vierte Teilentscheidung. Grundsätzlich gilt bei einer Evaluation von Entscheidungen von links nach rechts, dass Teilentscheidungen um so schlechter geprüft werden, je

94

3 Kontrollflussorientierter, strukturorientierter Test

weiter rechts sie in einer zusammengesetzten Entscheidung stehen. Diese Eigenschaft des Zweigüberdeckungstests bezüglich der Prüfung zusammengesetzter Entscheidungen bewirkt, dass der Zweigüberdeckungstest für diese Problemstellung ungeeignet ist. Auch eine vollständige Evaluation von Entscheidung – die z. B. bei manchen Compilern gewählt werden kann – beseitigt dieses Problem nicht.

3.4.2

Einfacher Bedingungsüberdeckungstest

Das einfachste Verfahren des Bedingungsüberdeckungstests ((simple) condition coverage) fordert den Test aller atomaren Teilentscheidungen gegen wahr und falsch. Im allgemeinen Fall kann nicht garantiert werden, dass der einfache Bedingungsüberdeckungstest den Zweigüberdeckungstest subsumiert. Ob der Zweigüberdeckungstest subsumiert wird, bestimmt die Art, wie Entscheidungen evaluiert werden. Werden zusammengesetzte Entscheidungen vom Compiler so umgesetzt, dass sie bei der Ausführung der Software unvollständig evaluiert werden, so ist der Zweigüberdeckungstest im einfachen Bedingungsüberdeckungstest enthalten (bei UND-, ODERund NICHT-Verknüpfungen). Diese Vorgehensweise der Evaluierung von Entscheidungen ist der Standardfall. Da in diesem Fall zusammengesetzte Entscheidungen nur so lange geprüft werden, bis der Wahrheitswert der Gesamtentscheidung bekannt ist, bewirkt diese Form der Evaluation von Entscheidungen eine Reduzierung der Ausführungszeit.

Der einfache Bedingungsüberdeckungstest subsumiert den Zweigüberdeckungstest im Allgemeinen nicht.

Bei einer vollständigen Evaluation der Entscheidungen ist der Zweigüberdeckungstest nicht im einfachen Bedingungsüberdeckungstest enthalten. Einige Compiler bieten die Wahlmöglichkeit, ob Entscheidungen vollständig oder unvollständig evaluiert werden sollen. Da der Zweigüberdeckungstest als notwendige Testtechnik gilt, und es sicherlich nicht akzeptabel ist, falls die Erfüllung notwendiger Kriterien vom verwendeten Compiler oder dessen Einstellung abhängt, muss der einfache Bedingungsüberdeckungstest in der Regel als unzureichend gelten.

Die Entscheidung (((u == 0) || (x > 5)) && ((y < 6) || (z == 0))) soll abkürzend als ((A || B) && (C || D)) geschrieben werden. Wir wollen annehmen, dass zwischen den Werten der Variablen u, x, y und z keine Abhängigkeiten existieren. Dann können die Teilentscheidungen A, B, C und D unabhängig voneinander wahr und falsch werden. Tab. 3.1 stellt die 16 Wahrheitswertekombinationen dar, die bei einer vollständigen Evaluation von Entscheidungen möglich sind. Ein einfacher Bedingungsüberdeckungstest kann z. B. mit den zwei Testfällen 6 und 11 erreicht werden. Die vier Teilentscheidungen A bis D werden jeweils gegen wahr und falsch geprüft. Die Teilentscheidun-

3.4 Bedingungsüberdeckungstest

BEISPIEL

95

gen (A || B) und (C || D) und die Entscheidung ((A || B)&&(C || D)) sind jedoch in beiden Fällen wahr. Eine Zweigüberdeckung erreichen diese Testfälle nicht. A

B

C

D

1

f

f

f

f

2

f

f

f

w

3

f

f

w

f

4

f

f

w

w

5

f

w

f

f

6

f

w

f

w

7

f

w

w

f

8

f

w

w

w

9

w

f

f

f

10

w

f

f

w

11

w

f

w

f

12

w

f

w

w

13

w

w

f

f

14

w

w

f

w

15

w

w

w

f

16

w

w

w

w

A || B

C || D

(A || B) && (C || D)

w

w

w

w

w

w

Tabelle 3.1 Einfacher Bedingungsüberdeckungstest (simple) condition coverage

Wären für den Test die Fälle 1 und 16 entsprechend Tab. 3.1 ausgewählt worden, so hätte man eine vollständige Zweigüberdeckung erreicht. Wie das Beispiel zeigt, gibt es aber Testfälle, die den einfachen Bedingungsüberdeckungstest erfüllen ohne eine Zweigüberdeckung zu gewährleisten. Der einfache Bedingungsüberdeckungstest stellt bei einer vollständigen Evaluation der Entscheidungen die Zweigüberdeckung nicht sicher. Bei einer unvollständigen Evaluation von Entscheidungen existieren statt der 16 Wahrheitswertekombinationen nur 7 Kombinationsmöglichkeiten. Diese sind in Tab. 3.2 angegeben. So werden z. B. die Fälle 1 bis 4 nach Tab. 3.1 auf den Fall I nach Tab. 3.2 abgebildet, weil nach der Evaluation der Teilentscheidungen A und B zu falsch fest-

96

3 Kontrollflussorientierter, strukturorientierter Test

steht, dass die Gesamtentscheidung ebenfalls den Wahrheitswert falsch besitzt. Eine Prüfung der Teilentscheidungen C und D ist daher in dieser Situation nicht notwendig. Testfälle

A

B

C D

A || B

C || D

(A || B) && (C || D)

I

1, 2, 3, 4

f

f

-

-

f

-

f

II

5

f

w

f

f

w

f

f

III

6

f

w

f

w

w

w

w

IV

7, 8

f

w w

-

w

w

w

V

9, 13

w

-

f

f

w

f

f

VI

10, 14

w

-

f

w

w

w

w

VII

11,12,15,16

w

-

w

-

w

w

w

Tabelle 3.2 Wahrheitswertekombination bei unvollständiger Evaluation von Entscheidungen

Wie Tab. 3.2 zeigt führt der Testfall 11, der nach Tab. 3.2 zusammen mit Testfall 6 bei der vollständigen Evaluation von Entscheidungen eine einfache Bedingungsüberdeckung ergibt, ebenfalls zu anderen Wahrheitswerten. Er wird entsprechend Tab. 3.2 nach Zeile VII abgearbeitet. Nach Ausführung der zwei Testfälle sind die Teilentscheidungen A und C jeweils gegen wahr und falsch getestet. Die Teilentscheidungen B und D sind jedoch nur gegen wahr getestet. Im Unterschied zur vollständigen Evaluation von Entscheidungen bewirken die beiden Testfälle keinen vollständigen einfachen Bedingungsüberdeckungstest. Um das zu erreichen, müssen weitere Testfälle durchgeführt werden. Die Teilentscheidung B kann nur durch Wahl des Testfalls I gegen falsch geprüft werden. Um D gegen falsch zu prüfen, muss entweder Testfall II oder V ausgeführt werden. Die Testfälle I, II, III und VII nach Tab. 3.3 stellen eine einfache Bedingungsüberdeckung sicher. Tab. 3.3 zeigt, dass diese Testfälle darüber hinaus eine vollständige Zweigüberdeckung sicherstellen. Sie verursachen beide Wahrheitswerte der Gesamtentscheidung. Dieser Zusammenhang gilt grundsätzlich: Bei einer unvollständigen Evaluation von Entscheidungen subsumiert der einfache Bedingungsüberdeckungstest den Zweigüberdeckungstest. Der einfache Bedingungsüberdeckungstest besitzt den Vorteil, dass die Anzahl der notwendigen Testfälle einen linearen Zusammenhang zu der Anzahl der atomaren Teilentscheidungen besitzt. Nachteilig ist, dass der Zweigüberdeckungstest nur für den Spezialfall der unvollständigen Evaluation von Entscheidungen sichergestellt wird.

3.4 Bedingungsüberdeckungstest

Der einfache Bedingungsüberdeckungstest subsumiert den Zweigüberdeckungstest, falls Entscheidungen unvollständig evaluiert werden (für UND-, ODER- und NICHT-Verknüpfungen).

97

A

B

C D

A || B

C || D

(A || B) && (C || D)

I

f

f

-

-

f

-

f

II

f

w

f

f

w

f

f

III

f

w

f

w

w

w

w

IV

f

w w

-

w

w

w

V

w

-

f

f

w

f

f

VI

w

-

f

w

w

w

w

VII

w

-

w

-

w

w

w

Tabelle 3.3 Einfache Bedingungsüberdeckung bei unvollständiger Evaluation von Entscheidungen

BEISPIEL

Die Operation ZaehleZchn enthält zwei Entscheidungen: a. ((Zchn >= ’A’) && (Zchn = ‘A‘

w

w

w

w

w

f

w

w

Zchn = ‘A‘

w

Zchn = ‘A‘

w

w

w

w

w

w

f

w

w

Zchn 5) { if ((x < 2) || (x > 6) && (x < 9)) { invariant

falsch

if (x > 5) { if ((false || (x > 6) && (x < 9)) {

invariant

falsch

if (x > 5) { if ((x > 6) && (x < 9)) {

Abbildung 3.5 Invariante Teilentscheidung

Aufgrund der Entscheidung (x > 5) des äußeren Auswahlkonstrukts ergibt die eingeschachtelte Entscheidung (x < 2) stets den Wahrheitswert falsch. Diese Entscheidung kann durch die boolesche Konstante false ersetzt werden und letztlich aufgrund der ODER-Verknüpfung gestrichen werden.

Einerseits subsumiert der minimale Mehrfach-Bedingungsüberdeckungstest den Zweigüberdeckungstest. Er beachtet die logische Struktur von Entscheidungen und identifiziert invariante Teilentscheidungen. Andererseits ist er insbesondere bei der vollständigen Evaluation von Entscheidungen nur eingeschränkt in der Lage, fehlerhafte logische Verknüpfungsoperatoren zu erkennen.

3.4 Bedingungsüberdeckungstest

Der minimale Mehrfach-Bedingungsüberdeckungstest subsumiert den Zweigüberdeckungstest.

105

3.4.5

Es entsteht ein linearer Testaufwand bezogen auf die Anzahl der atomaren Teilentscheidungen.

Modifizierter Bedingungs-/Entscheidungsüberdeckungstest

Der modifizierte Bedingungs-/Entscheidungsüberdeckungstest (modified condition/decision coverage) verlangt Testfälle, die demonstrieren, dass jede atomare Teilentscheidung den Wahrheitswert der Gesamtentscheidung unabhängig von den anderen Teilentscheidungen beeinflussen kann. Die Anwendung dieser Technik wird vom Standard RTCA DO-178 B für flugkritische Software (Level A) in der Avionik gefordert /RTCA DO-178B 92/. Grundsätzlich zielt die Technik auf einen möglichst umfassenden Test der Logik von zusammengesetzten Entscheidungen mit einem vertretbaren Testaufwand. Der Zusammenhang zwischen der Anzahl der atomaren Teilentscheidungen einer Entscheidung und der Anzahl der erforderlichen Testfälle ist linear. Für den Test einer Entscheidung mit n Teilentscheidungen sind mindestens n+1 Testfälle erforderlich. Tab. 3.10 stellt ein Beispiel für Testfälle eines modifizierten Bedingungs-/ Entscheidungsüberdeckungstests bei vollständiger Evaluation von Entscheidungen dar. Links neben der Tabelle ist angedeutet, welches Testfallpaar welche atomare Entscheidung testet. Die Testfälle 2 und 6 weisen identische Wahrheitswerte für die Teilentscheidungen A, C und D auf. Sie unterscheiden sich in den Wahrheitswerten der Teilentscheidung B. In Testfall 2 besitzt B den Wahrheitswert falsch. In Testfall 6 ist B wahr. Außerdem liefert Testfall 2 das Gesamtergebnis falsch, während in Testfall 6 die Gesamtentscheidung den Wert wahr besitzt. Damit ist nachgewiesen, das die atomare Teilentscheidung B unabhängig von den anderen atomaren Teilentscheidungen den Wahrheitswert der Gesamtentscheidung beeinflusst. Eine entsprechende Situation liegt für die Testfälle 2 und 10 bezogen auf A, 9 und 10 bezogen auf D und 9 und 11 bezogen auf C vor. Die Wahrheitswerte der jeweils anderen drei atomaren Teilentscheidungen sind jeweils fest. Die Wahrheitswerte der jeweils betrachteten Teilentscheidung und der Gesamtentscheidung ändern sich. Tab. 3.10 enthält fünf Testfälle. Nach der Regel, dass n+1 Testfälle für den Test einer Entscheidung notwendig sind, die n atomare Teilentscheidungen enthält, ist ein vollständiger Test mit weniger als fünf Testfällen nicht möglich, denn die Beispielentscheidung enthält vier atomare Teilentscheidungen.

Geänderte Regeln für die unvollständige Evaluation von Entscheidungen

106

Bei einer unvollständigen Evaluation von Entscheidungen ist es notwendig, die Anforderung abzuschwächen, die Wahrheitswerte der jeweils nicht getesteten atomaren Teilentscheidungen beizubehalten, während sich die Wahrheitswerte der jeweils getesteten atomaren Teilentscheidung und der Gesamtentscheidung verändern. Pro atomarer Teilentscheidung ist die Existenz eines Testfallpaares gefordert, das >

bezüglich dieser Teilentscheidung beide Wahrheitswerte abdeckt und

>

bezüglich der Gesamtentscheidung beide Wahrheitswerte abdeckt und

3 Kontrollflussorientierter, strukturorientierter Test

B

A

D C

A

B

C

D

A || B

C || D

(A || B) && (C || D)

1

f

f

f

f

2

f

f

f

w

f

w

f

3

f

f

w

f

4

f

f

w

w

5

f

w

f

f

6

f

w

f

w

w

w

w

7

f

w

w

f

8

f

w

w

w

9

w

f

f

f

w

f

f

10

w

f

f

w

w

w

w

11

w

f

w

f

w

w

w

12

w

f

w

w

13

w

w

f

f

14

w

w

f

w

15

w

w

w

f

16

w

w

w

w

Tabelle 3.10 Modified condition/decision coverage (vollständige Evaluation von Entscheidungen)

>

für alle anderen atomaren Teilentscheidungen identische Wahrheitswerte aufweist oder an diesen Stellen nicht evaluiert wurde.

Tab 3.11 stellt fünf Testfälle dar, die bei einer unvollständigen Evaluation von Entscheidungen einen modifizierten Bedingungs-/Entscheidungsüberdeckungstest bewirken. Links neben der Tabelle ist angedeutet, welches Testfallpaar welche atomare Teilentscheidung testet. Die Testfälle I und VII testen die atomare Teilentscheidung A. Sie weisen für die Teilentscheidung A und die Gesamtentscheidung unterschiedliche Wahrheitswerte auf und besitzen bei den verbleibenden atomaren Teilentscheidungen nur Wahrheitswerte, falls diese bei dem jeweils anderen Testfall nicht evaluiert wurden. Dieser Sachverhalt gilt analog für die verbleibenden Teilentscheidungen. Ein vollständig durchgeführter modifizierter Bedingungs-/Entscheidungsüberdeckungstest bewirkt einen Zweigüberdeckungstest auf der Objektcodeebene. Auf der Objektcodeebene sind ausschließlich einfache – d. h. atomare – Entscheidungen vorhanden. Abb. 3.6 stellt die Struktur

3.4 Bedingungsüberdeckungstest

107

A

B

C D

A || B

C || D

(A || B) && (C || D)

I

f

f

-

-

f

-

f

II

f

w

f

f

w

f

f

III

f

w

f

w

w

w

w

IV

f

w w

-

w

w

w

V

w

-

f

f

w

f

f

VI

w

-

f

w

w

w

w

VII

w

-

w

-

w

w

w

B D C

A

Tabelle 3.11 Modified condition/decision coverage (unvollständige Evaluation von Entscheidungen)

der Beispielentscheidung in Form eines Programmablaufplans dar. Die Pfade, die die Testfälle nach Tab. 3.11 in dieser Struktur durchlaufen, sind eingezeichnet. In der Abbildung ist zu erkennen, dass pro atomarer Teilentscheidung zwei Pfade vorhanden sind, von denen je einer den wahrund der andere den falsch-Fall bezogen auf die atomare Teilentscheidung und die Gesamtentscheidung testet und die sonst keine Unterschiede mit Ausnahme von nicht evaluierten Teilentscheidungen besitzen. So verzweigt Testfall I an den Teilentscheidungen A und B jeweils in den falsch-Zweig und liefert als Gesamtergebnis ebenfalls falsch. Die Teilentscheidungen C und D werden nicht evaluiert. Testfall VII verzweigt an der Teilentscheidung A in den wahr-Zweig, umgeht die Teilentscheidung B und verzweigt an der Teilentscheidung C in den wahr-Zweig. Das Gesamtergebnis ist wahr. Die Teilentscheidung D wird nicht evaluiert. Wie man an Abb. 3.6 erkennen kann, ist der modifizierte Bedingungs-/Entscheidungsüberdeckungstest keineswegs identisch mit einem Zweigüberdeckungstest auf der Objektcodeebene, denn dieser kann bereits mit vier Testfällen erreicht werden. Abb. 3.7 zeigt ein entsprechendes Beispiel. Die Testfälle sind in Tab. 3.7 dargestellt. Einerseits erfüllen Sie lediglich für die Teilentscheidung A die Forderungen des modifizierten Bedingungs-/Entscheidungsüberdeckungstests. Die anderen atomaren Teilentscheidungen (B, C und D) sind nicht ausreichend getestet. Andererseits bewirken die Testfälle nach Tab. 3.7 einen vollständigen minimalen Mehrfach-Bedingungsüberdeckungstest. Die hier exemplarisch gezeigten Zusammenhänge gelten generell:

108

3 Kontrollflussorientierter, strukturorientierter Test

Abbildung 3.6 Modifizierter Bedingungs-/Entscheidungsüberdeckungstest auf Objektcodeebene

>

Der modifizierte Bedingungs-/Entscheidungsüberdeckungstest subsumiert den minimalen Mehrfach-Bedingungsüberdeckungstest.

>

Bei der unvollständigen Evaluation von Entscheidungen entsprechen der Zweigüberdeckungstest auf der Objektcodeebene und der minimale Mehrfach-Bedingungsüberdeckungstest auf Quellcodeebene einander.

Für gekoppelte Teilentscheidungen sind Erweiterungen des modifizierten Bedingungs-/Entscheidungsüberdeckungstests vorgeschlagen worden /Chilenski, Miller 94/. Diese sind erforderlich, weil bestimmte Wahrheitswertekombinationen unter Umständen nicht erzeugt werden können. Ein Beispiel für eine Entscheidung mit gekoppelten Teilentscheidungen ist ((Zchn == ’A’) || (Zchn == ’E’) || (Zchn == ’I’) || (Zchn == ’O’) || (Zchn == ’U’)) der Operation ZaehleZchn. Es ist nicht möglich, den Wahrheitswert einer Teilentscheidung vollständig unabhängig von den Werten der anderen Teilentscheidungen zu verändern, weil sich alle Teilentscheidungen auf den Wert derselben Variable beziehen. Die Änderung des Wahrheitswerts einer Teilentscheidung kann, muss aber nicht notwendig Einfluss auf die Wahrheitswerte der anderen Teilentscheidungen haben. Man bezeichnet derartige atomare Teilentscheidungen als schwach gekoppelt. In dem angegebenen Beispiel ist es nicht möglich, zu erreichen, dass mehr als eine Teilentscheidung gleichzeitig wahr ist. Das kann zu Schwierigkeiten bei der Erzeugung der für einen vollständigen modifizierten Bedingungs-/Entscheidungsüberdeckungstest erfor-

3.4 Bedingungsüberdeckungstest

MERKE

Gekoppelte Teilentscheidungen

Schwach gekoppelte Teilentscheidungen

109

Abbildung 3.7 Minimaler Mehrfach-Bedingungsüberdeckungstest auf Objektcodeebene

derlichen Testfälle führen. Oft ist der Test aber ungeachtet der gekoppelten Bedingungen durchführbar. Tab. 3.12 zeigt die möglichen Testfälle bei einer vollständigen Evaluation der Entscheidung. Aufgrund der Kopplung der atomaren Teilentscheidungen existieren nur 6 der 32 Wahrheitswertekombinationen. Tab. 3.12 zeigt ebenfalls, dass die Durchführung dieser 6 Testfälle einen vollständigen modifizierten Bedingungs-/Entscheidungsüberdeckungstest ergibt. Jeder atomaren Teilentscheidung ist das jeweils testende Testfallpaar zugeordnet. Tab. 3.13 zeigt die herstellbaren Testsituationen bei einer unvollständigen Evaluation der Entscheidung. Auch hier ist der Test der angegebe(Zchn == ‘A‘) || (Zchn == ‘E‘) || 1) Zchn == ‘A‘ 2) Zchn == ‘E‘ 3) Zchn == ‘I‘ 4) Zchn == ‘O‘ 5) Zchn == ‘U‘ (Zchn == ‘I‘) || (Zchn == ‘O‘) || (Zchn == ‘U‘) w

f

f

f

f

w

f

w

f

f

f

w

f

f

w

f

f

w

f

f

f

w

f

w

f

f

f

f

w

w

f

f

f

f

f

f

1 2 3 4 5

Tabelle 3.12 Modifizierter Bedingungs-/Entscheidungsüberdeckungstest (vollständige Evaluation von Entscheidungen)

110

3 Kontrollflussorientierter, strukturorientierter Test

(Zchn == ‘A‘) || (Zchn == ‘E‘) || 1) Zchn == ‘A‘ 2) Zchn == ‘E‘ 3) Zchn == ‘I‘ 4) Zchn == ‘O‘ 5) Zchn == ‘U‘ (Zchn == ‘I‘) || (Zchn == ‘O‘) || (Zchn == ‘U‘) w

-

-

-

-

w

f

w

-

-

-

w

f

f

w

-

-

w

f

f

f

w

-

w

f

f

f

f

w

w

f

f

f

f

f

f

1 2 3 4 5

Tabelle 3.13 Modifizierter Bedingungs-/Entscheidungsüberdeckungstest (unvollständige Evaluation von Entscheidungen)

nen sechs Fälle ausreichend für einen vollständigen modifizierten Bedingungs-/Entscheidungsüberdeckungstest. Neben den beschriebenen schwach gekoppelten atomaren Teilentscheidungen gibt es so genannte stark gekoppelte atomare Teilentscheidungen. Diese ändern ihren Wahrheitswert stets, falls der Wahrheitswert einer der gekoppelten Teilentscheidungen sich verändert.

In der Entscheidung (A && (!B)) || ((!A) && B) sind die atomaren Teilentscheidungen A und (!A) sowie B und (!B) stark gekoppelt. Wenn A wahr ist, so ist (!A) falsch und umgekehrt. Testsituationen, in denen A und (!A) gleichzeitig wahr oder falsch sind, sind daher nicht erzeugbar.

Stark gekoppelte Teilentscheidungen

BEISPIEL

Für die Durchführung eines modifizierten Bedingungs-/Entscheidungsüberdeckungstest für stark gekoppelte atomare Teilentscheidungen schlagen /Chilenski, Miller 94/ entsprechende Erweiterungen des Verfahrens vor.

3.4.6

Mehrfach-Bedingungsüberdeckungstest

Der Mehrfach-Bedingungsüberdeckungstest (multiple condition coverage) fordert den Test aller Wahrheitswertekombinationen der atomaren Teilentscheidungen. Diese Vorgehensweise ergibt ohne Zweifel einen sehr umfassenden Test von zusammengesetzten Entscheidungen. Darüber hinaus ist bei der Berücksichtigung aller Kombinationsmöglichkeiten sichergestellt, dass unabhängig von der Verknüpfungslogik zusammengesetzter Entscheidungen für die Gesamtentscheidung beide Wahrheitswerte berücksichtigt werden. Der Mehrfach-Bedingungsüberdeckungstest subsumiert daher in jedem Fall den Zweigüberdeckungstest und alle

3.4 Bedingungsüberdeckungstest

Der Mehrfach-Bedingungsüberdeckungstest ist die umfassenste Bedingungsüberdeckungstesttechnik.

111

anderen Bedingungsüberdeckungstesttechniken. Nachteilig ist sein hoher Testaufwand. Bei einer Entscheidung, die aus n Teilentscheidungen zusammengesetzt ist, sind stets 2n Testfälle notwendig. Man bezeichnet dies als exponentielles Wachstum des Testaufwands. Der Zusammenhang zwischen der Anzahl atomarer Teilentscheidungen und der benötigten Anzahl der Testfälle ist in Tab. 3.14 angegeben. Ein derartiges exponentielles Wachstum der Anzahl der Testfälle – und damit des Testaufwands – ist in der Regel nicht akzeptabel. Tab. 3.15 zeigt die für einen vollständigen Mehrfach-Bedingungsüberdeckungstest der Entscheidung ((A && B) || (C && D)) notwendigen Testfälle. Da die Entscheidung aus 4 atomaren Teilentscheidungen aufgebaut ist, enthält die Tabelle 24 – also 16 – Testfälle. Bei einer unvollständigen Evaluation von Entscheidungen existieren nicht alle 16 Testfälle. Es sind nur die in Tab. 3.16 angegebenen sieben Situationen herstellbar. Grundsätzlich können natürlich Testdaten für die 16 Wahrheitswertekombinationen erzeugt werden. Es besteht aber keine Möglichkeit, mit einem Testwerkzeug – bei einer unvollständigen Evaluation von Entscheidungen – andere als die in Tab. 3.16 angegebenen sieben Situationen zu registrieren. Eine ggf. mögliche Umschaltung des Compilers auf eine vollständige Evaluation von Entscheidungen sollte nicht genutzt werden, da der Testling möglichst wenig Differenzen zur später freigegebenen und ausgelieferten Software aufweisen sollte. Falls dort eine unvollständige Evaluation von Entscheidungen vorgesehen ist, so sollte das beim Testling nicht anders sein. Darüber hinaus kommt es vor, dass bestimmte Wahrheitswertekombinationen aufgrund gekoppelter Teilentscheidungen nicht herstellbar sind. Von den 32 (25) Wahrheitswertekombinationen der Entscheidung ((Zchn == ’A’) || (Zchn == ’E’) || (Zchn == ’I’) || (Zchn == ’O’) || (Zchn == ’U’)) der Operation ZaehleZchn sind nur sechs herstellbar (Tab. 3.17). Dies weist nicht auf einen Fehler in der Programmlogik hin, sondern ist nur natürlich im Sinne der Eigenschaften der in der Entscheidung verwendeten Variable. Dies erschwert die Definition eines aussagekräftigen Testmaßes. Die Zielsetzung von Testmaßen ist, eine quantitative Aussage über den Grad des Tests zu gewinnen. Üblicherweise wird hier der Quotient aus der Anzahl der getesteten Objekte (Anweisungen, Zweige, atomare Teilentscheidungen) und der Anzahl der als testbar vorausgesetzten vorhan-

Tabelle 3.14 Testfallanzahl beim Mehrfach-Bedingungsüberdeckungstest

112

3 Kontrollflussorientierter, strukturorientierter Test

A

B

C

D

A || B

C || D

(A || B) && (C || D)

1

f

f

f

f

f

f

f

2

f

f

f

w

f

w

f

3

f

f

w

f

f

w

f

4

f

f

w

w

f

w

f

5

f

w

f

f

w

f

f

6

f

w

f

w

w

w

w

7

f

w

w

f

w

w

w

8

f

w

w

w

w

w

w

9

w

f

f

f

w

f

f

10

w

f

f

w

w

w

w

11

w

f

w

f

w

w

w

12

w

f

w

w

w

w

w

13

w

w

f

f

w

f

f

14

w

w

f

w

w

w

w

15

w

w

w

f

w

w

w

16

w

w

w

w

w

w

w

Tabelle 3.15 Mehrfach-Bedingungsüberdeckungstest (vollständige Evaluation von Entscheidungen)

A

B

C D

A || B

C || D

(A || B) && (C || D)

I

f

f

-

-

f

-

f

II

f

w

f

f

w

f

f

III

f

w

f

w

w

w

w

IV

f

w w

-

w

w

w

V

w

-

f

f

w

f

f

VI

w

-

f

w

w

w

w

VII

w

-

w

-

w

w

w

Tabelle 3.16 Mehrfach-Bedingungsüberdeckungstest (unvollständige Evaluation von Entscheidungen)

3.4 Bedingungsüberdeckungstest

113

Zchn

‘A‘ ‘E‘

‘I‘ ‘O‘ ‘U‘ alle anderen Zeichen

?

?

?

Zchn == ‘A‘

w

f

f

f

f

f

w

...

w

Zchn == ‘E‘

f

w

f

f

f

f

w

...

w

Zchn == ‘I‘

f

f

w

f

f

f

f

...

w

Zchn == ‘O‘

f

f

f

w

f

f

f

...

w

Zchn == ‘U‘

f

f

f

f

w

f

f

...

w

Entscheidung b) w

w

w

w

w

f

w

...

w

6 Möglichkeiten (herstellbar)

26 Möglichkeiten (nicht herstellbar)

32 Möglichkeiten

Tabelle 3.17 Mehrfach-Bedingungsüberdeckungstest (mögliche Testfälle)

denen Objekte gebildet. Da beim Mehrfach-Bedingungsüberdeckungstest oft ein Teil der benötigten Tests nicht durchführbar ist, verbietet sich ein einfaches Maß der beschriebenen Form.

3.4.7

PROBLEM: Compiler können zusammengesetzte Entscheidungen unterschiedlich umsetzen.

Problematiken

Die Art der Evaluation von Entscheidungen hat maßgeblichen Einfluss auf die möglichen Testfälle der Bedingungsüberdeckungstests. Grundsätzlich ist es ein erheblicher Unterschied, ob Entscheidungen vollständig oder unvollständig geprüft werden. Darüber hinaus existieren vielfältige Möglichkeiten zur unvollständigen Prüfung von Entscheidungen. In den oben angeführten Beispielen wurde implizit eine unvollständige Evaluierung von links nach rechts angenommen. Das ist aber keineswegs die einzige Möglichkeit. So können z. B. optimierende Compiler aus Effizienzgründen zusammengesetzte Entscheidung erheblich umgestalten. Da Mikroprozessoren nicht die Möglichkeit besitzen, komplizierte Entscheidungen zu evaluieren, werden diese vom Compiler in geschachtelte Strukturen mit atomaren Entscheidungen umgesetzt. Auf diesem Weg entstehen im Objektcode zu den atomaren Teilentscheidungen Zweige, die zur Registrierung von Bedingungsüberdeckungen dienen können. Entsprechende Werkzeuge fügen an diesen Stellen Anweisungen ein, die während der Testdurchführung registrieren, falls der Zweig durchlaufen wird. Das Hinzufügen dieser Anweisungen bezeichnet man als Instrumentierung. Im Objektcode kann die erreichte Bedingungsüberdeckung daher auf einfache Weise registriert werden. Bei der hier angenommenen unvollständigen Entscheidungsevaluation von links nach rechts wird die logische UND-Verknüpfung der booleschen Ausdrücke vom Compiler zu

114

3 Kontrollflussorientierter, strukturorientierter Test

einer Struktur im Objektcode umgesetzt, deren Form durch die angegebene Quellcodedarstellung im Beispiel beschrieben ist.

if (BooleVar && BooleProc(x)) Anweisung1; else Anweisung2;

BEISPIEL

⇓ if BooleVar { if BooleProc(x) Anweisung1; else Anweisung2; } else Anweisung2;

Es ergeben sich zwei Probleme: >

Falls BooleVar bereits den Wahrheitswert falsch ergibt, so wird BooleProc(x) aufgrund der Schachtelungsstruktur nicht mehr evaluiert. Diese Vorgehensweise ist korrekt, da nur der Wahrheitswert der Gesamtentscheidung ermittelt werden muss und bereits feststeht, dass diese den Wahrheitswert falsch besitzt. Der Mehrfach-Bedingungsüberdeckungstest kann daher auch im Objektcode nicht immer realisiert werden, da Teilentscheidungen häufig nicht evaluiert werden. Es existiert keine Möglichkeit zur Registrierung bestimmter Wahrheitswertekombinationen atomarer Teilentscheidungen.

>

Eine explizite Evaluierung von Teilentscheidungen verbietet sich, da Boolesche Ausdrücke auch Funktionsaufrufe enthalten können. Wird deren geplante Aufruffolge geändert, so sind fehlerhafte Reaktionen im Falle gedächtnisbehafteter Funktionen die Folge. Ferner existiert die Gefahr, dass z. B. durch Indexfehler bei Feldern Laufzeitfehler auftreten. In jedem Falle verhält sich die instrumentierte Software anders als die nicht instrumentierte Fassung, was nicht akzeptabel ist.

Zur Lösung der Problematik sind mehrere Ansätze denkbar: >

Eine Möglichkeit ist die Umsetzung von Kontrollkonstrukten mit zusammengesetzten Entscheidungen in Schachtelstrukturen elementarer Entscheidungen auf Quellcodeebene, die anschließend instrumentiert werden können. Dies verursacht eine weitgehende Änderung der Kontrollstruktur des Prüflings. Außerdem setzt das Verfahren voraus, dass die Art der Evaluation von Entscheidungen durch den Compiler bekannt ist.

>

Eine weitere Möglichkeit besteht darin, nur jene booleschen Ausdrücke zu evaluieren, die auch in der nicht-instrumentierten Fas-

3.4 Bedingungsüberdeckungstest

Lösungsansätze für die Registrierung der Bedingungsüberdeckung

115

sung des Testlings evaluiert würden. Die Wahrheitswerte der Ausdrücke können zusätzlichen booleschen Variablen zugewiesen werden. Diese Variablen werden analog zu den Entscheidungen des Originalprogramms benutzt, um den weiteren Kontrollfluss zu steuern. Dies lässt die Kontrollkonstrukte weitgehend in ihrem ursprünglichen Zustand. Annahmen über die Art der Umsetzung komplizierter Entscheidungen in Schachtelstrukturen atomarer Teilentscheidungen auf der Objektcodeebene sind weiterhin notwendig. >

BEISPIEL

Eine bessere Möglichkeit zur Lösung des Problems ist die direkte Instrumentierung innerhalb der Entscheidungen mit Hilfe einer booleschen Funktion. Diese Form der Instrumentierung erfordert keine Annahmen über die Art der Umsetzung komplizierter Entscheidungen in Schachtelstrukturen atomarer Teilentscheidungen auf der Objektcodeebene. Sie lässt die Kontrollstruktur vollständig unbeeinflusst. Es sind keine zusätzlichen booleschen Variablen erforderlich, und die Entscheidungen müssen nur geringfügig modifiziert werden. Jede atomare und nicht atomare Teilentscheidung wird durch einen Aufruf einer booleschen Funktion ersetzt, die als aktuellen Parameter die Teilentscheidung besitzt. Die Funktion registriert den Wahrheitswert ihres aktuellen Parameters und gibt ihn als Funktionswert zurück. Die Struktur der Entscheidung bleibt unverändert. Deshalb übersetzt der Compiler die instrumentierte Version analog zur nicht instrumentierten Version der Entscheidung. Die Evaluation und Registrierung des Wahrheitswertes von Teilentscheidungen erfolgt zur Laufzeit völlig äquivalent zur nicht instrumentierten Version des Programms.

if ((Zchn == ’A’) || (Zchn == ’E’) || (Zchn == ’I’) || (Zchn == ’O’) || (Zchn == ’U’)) ... wird durch die Instrumentierung umgeformt zu: if registriere (((registriere (Zchn == ’A’, 2)) || (registriere (Zchn == ’E’, 3)) || (registriere (Zchn == ’I’, 4)) || (registriere (Zchn == ’O’, 5)) || (registriere (Zchn == ’U’, 6)) ), 1)... Die Funktion registriere (boolean, int) evaluiert den ihr übergebenen booleschen Parameter. Der Wahrheitswert wird z. B. in einer Tabelle erfasst. Die Tabellenposition, die zu einer bestimmten Teilentscheidung gehört, wird durch den Integerparameter festgelegt. Anschließend wird der Wahrheitswert des booleschen Parameters als Wert der Funktion registriere zurückgegeben.

116

3 Kontrollflussorientierter, strukturorientierter Test

3.4.8

Bewertung des Bedingungsüberdeckungstests

Die Bedingungsüberdeckungstests sind insbesondere dann als Testtechniken interessant, wenn eine komplizierte Verarbeitungslogik vorliegt, die zu kompliziert aufgebauten Entscheidungen führt. Im Hinblick auf den besten Kompromiss aus Leistungsfähigkeit und Testaufwand empfehlen sich der minimale Mehrfach-Bedingungsüberdeckungstest und der modifizierte Bedingungs-/Entscheidungsüberdeckungstest. Die Verwendung von Bedingungsüberdeckungstests ist in manchen kritischen Fällen verbindlich.

3.5 3.5.1

Der Bedingungsüberdeckungstest ist für den Test von komplizierter Verarbeitungslogik geeignet.

Techniken für den Test von Schleifen Eigenschaften und Ziele

Schleifen verursachen oft eine extrem hohe Anzahl von Programmpfaden. Die Ausführung dieser Pfade – ein so genannter Pfadüberdeckungstest (siehe Abschnitt 3.6) – ist in diesem Fall nicht möglich. Die im Folgenden beschriebenen Verfahren strukturierter Pfadtest und Grenze-Inneres-Überdeckung (boundary interior coverage) bieten eine Lösung dieses Problems. Sie unterteilen die Pfade in „Äquivalenzklassen“ und verlangen nur die Ausführung geeigneter Stellvertreter aus diesen Klassen von Pfaden. Die zwei Techniken sind sehr ähnlich. Der boundary interior-Test ist ein Spezialfall des strukturierten Pfadtests. Einerseits sind die Techniken in der Primärliteratur nicht hinreichend präzis beschrieben, so dass bei komplizierten Schleifenstrukturen nicht vollständig klar ist, welche Forderungen zu erfüllen sind. Andererseits ist das Ziel dieser Techniken die Definition eines mit vertretbarem Aufwand durchführbaren Testkriteriums für Schleifen, das bestimmte Regeln einhält. So wird man verlangen, dass als Nebenbedingung ein vollständiger Zweigüberdeckungstest erreicht wird, denn wir suchen eine Testtechnik, die zwischen dem Zweigüberdeckungstest und dem Pfadüberdeckungstest angeordnet ist. Je nach zugrundegelegter Definition der Verfahren existieren Schleifenstrukturen, für die eine der genannten Anforderungen nicht erfüllt ist. Daher werde ich eine Technik vorstellen, die ich für besonders geeignet halte. Heuristiken für den Test von Schleifen sind in /Beizer 90/ zu finden. Eine präzise Definition des strukturierten Pfadtests und des boundary interior-Tests ist in /Riedemann 97/ enthalten.

3.5 Techniken für den Test von Schleifen

PROBLEM: Explosion der Pfadanzahl durch Schleifen

117

Schleifen verursachen oft, aber nicht immer, eine sehr hohe Anzahl von Pfaden.

3.5.2

Strukturierter Pfadtest und boundary interiorPfadtest

3.5.2.1

Beschreibung

Die Anzahl der Pfade eines Software-Moduls ist in Gegenwart von Schleifen oft extrem hoch. Dies gilt jedoch nicht für jede Art von Schleifen. So stellen Zählschleifen mit konstanter Wiederholungsanzahl in dieser Hinsicht kein Problem dar. Falls 32767 der größtmögliche Wert einer Variable des Typs int ist, so besitzt die Operation ZaehleZchn 232768 -1 Pfade. Das sind etwa 1, 41 · 109864 Pfade. Könnte man durch eine umfassende Automatisierung 1000 Pfade pro Sekunde testen, so würde der Pfadüberdeckungstest dennoch rund 4, 5 · 109853 Jahre dauern. Da Schleifen die Verursacher dieses Problems sind, ist es sinnvoll, Beschränkungen für den Test jener Pfade zu definieren, die Schleifen durchlaufen. Dies geschieht, indem Pfade ab einer bestimmten Anzahl von Schleifendurchläufen zu Klassen zusammengefasst werden, die durch Auswahl eines Testpfades der Klasse als hinreichend getestet gelten. Howden gibt dazu die folgenden Definitionen an:

Definitionen aus der Literatur

/Howden 75/: In the boundary-interior approach to testing, it is assumed that a complete set of tests must test alternative paths through the top level of a program, alternative paths through loops, and alternative boundary tests of loops. A boundary test of a loop is a test which causes the loop to be entered but not iterated. An interior test causes a loop to be entered and then iterated at least once. Experience indicates that both the boundary and interior conditions of a loop should be tested. The boundary-interior method separates paths into separate classes if they differ other than in traversals of loops. If two paths P1 and P2 are the same except in traversals of loops they are placed in separate classes if 1) one is a boundary and the other an interior test of a loop; 2) they enter or leave a loop along different loop entrance or loop exit

branches; 3) they are boundary tests of a loop and follow different paths through the

loop; 4) they are interior tests of a loop and follow different paths through the

loop on their first iteration of the loop. /Howden 78a/: In the structured testing approach all paths through a functional module which require less than or equal to k (usually k = 2) iterations of loops are tested at least once. Variations in this rule are necessary in special cases

118

3 Kontrollflussorientierter, strukturorientierter Test

where this would leave parts of a module untested because of complicated loop indexing operations and dependencies between loop bounds. /Howden 78b/: Each path through a functional module which executes loops less than k times is tested at least once. /Tai 80/: Since the number of distinct paths is usually very large or infinite, a limited number of paths are selected by restricting the number of iterations of each loop in a path ( called structured testing). Grundsätzlich werden beim strukturierten Pfadtest nur Pfade bis zur k-ten Ausführung des Schleifenrumpfs unterschieden. Wir geben mit k nicht die Anzahl der Schleifenwiederholungen sondern die Ausführungsanzahl des Schleifenrumpfs an. Die Definitionen der Techniken in der Primärliteratur sind an dieser Stelle nicht vollständig eindeutig. Der strukturierte Pfadtest mit k=2 wird als Grenze-Inneres-Überdeckung (boundary interior coverage) bezeichnet. Die boundary interior coverage unterscheidet die drei Fälle keine Schleifenausführung, eine Schleifenausführung und mindestens zwei Schleifenausführungen. Das ist aufgrund der möglichen Abhängigkeiten zwischen Variablen vor, in und hinter der Schleife besonders sinnvoll. Eine ausführliche Begründung für die Unterscheidung eben dieser Fälle wird in dem Abschnitt zur Datenflussanomalieanalyse in Kapitel 8 gegeben. Bei der Datenflussanomalieanalyse müssen für Schleifen die gleichen drei Fälle betrachtet werden, für die die boundary interior coverage hier einen dynamischen Test fordert. Beim boundary interior-Test entstehen in Bezug auf eine betrachtete Schleife des zu testenden Software-Moduls drei Klassen von Pfaden. Die erste Klasse enthält die Pfade, die die Schleife nicht ausführen. Diese Klasse ist bei nicht abweisenden Schleifen leer, da der Rumpf dieser Schleifen mindestens einmal ausgeführt wird. Ein Beispiel für den Umgang mit derartigen Schleifen ist in /Riedemann 97/ enthalten.

Der strukturierter Pfadtest mit k=2 ist identisch zum boundary interior-Test.

Der boundary interiorTest bildet drei Pfadklassen.

Die zweite Klasse enthält alle Pfade, die die Schleife zwar betreten, sie jedoch nicht wiederholen. Die dritte Klasse umfasst alle Pfade, die den Schleifenrumpf mindestens zweimal ausführen. Nach /Howden 75/ werden die Testfälle für diejenigen Pfade, die die Schleife betreten, ohne sie zu wiederholen, als Grenztests (boundary tests) bezeichnet. Die Testfälle, die mindestens eine weitere Ausführung des Schleifenrumpfes verursachen, werden als interior tests bezeichnet.

Im Folgenden sind die für den boundary interior-Test der Operation ZaehleZchn benötigten Testfälle angegeben. Die angegebenen Testpfade beziehen sich auf Abb. 3.1.

3.5 Techniken für den Test von Schleifen

BEISPIEL

119

1. Testfall für den Pfad außerhalb der Schleife: Die Ausführung mit Gesamtzahl = int_max bewirkt die Nichtausführung des Schleifenrumpfes. Der getestete Pfad ist: nstart , n1 , n2 , n f inal 2. Boundary-Testfälle: a

Die Ausführung mit Gesamtzahl = 0 und Eingabe der Zeichenfolge A1 bewirkt das Betreten des Schleifenrumpfes, die Ausführung des wahr-Zweiges der Selektion und anschließend einen Schleifenabbruch. Der getestete Pfad ist: nstart , n1 , n2 , n3 , n4 , n5 , n2 , n f inal

b

Die Ausführung mit Gesamtzahl = 0 und Eingabe der Zeichenfolge B1 bewirkt das Betreten des Schleifenrumpfes, die Ausführung des falsch-Zweiges der Selektion und anschließend einen Schleifenabbruch. Testpfad: nstart , n1 , n2 , n3 , n5 , n2 , n f inal

3. Interior-Testfälle: a

Die Ausführung mit Gesamtzahl = 0 und Eingabe der Zeichenfolge EIN1 bewirkt eine dreimalige Ausführung des Schleifenrumpfes. Bei den ersten zwei Ausführungen wird der wahr-Zweig der Selektion durchlaufen. Der dritte Durchlauf ist ohne Bedeutung für den Test. Testpfad: nstart , n1 , n2 , n3 , n4 , n5 , n2 , n3 , n4 , n5 , n2 , n3 , n5 , n2 , n f inal

b

Die Ausführung mit Gesamtzahl = 0 und Eingabe der Zeichenfolge AH! bewirken eine zweimalige Ausführung des Schleifenrumpfes. Bei der ersten Ausführung wird der wahr-Zweig der Selektion durchlaufen. Beim zweiten Durchlauf wird der falsch-Zweig der Selektion ausgeführt. Das Rufzeichen bricht den Wiederholungsvorgang ab, was für interior-Tests nach der zweiten Ausführung des Schleifenrumpfes gestattet ist. Testpfad: nstart , n1 , n2 , n3 , n4 ,n5 , n2 , n3 , n5 , n2 , n f inal

c

Die Ausführung mit Gesamtzahl = 0 und Eingabe der Zeichenfolge HA! bewirkt eine zweimalige Ausführung des Schleifenrumpfes. Bei der ersten Ausführung wird der falsch-Zweig der Selektion durchlaufen. Beim zweiten Durchlauf wird der wahr-Zweiges der Selektion ausgeführt. Das Rufzeichen bricht den Wiederholungsvorgang ab. Testpfad: nstart , n1 , n2 , n3 , n5 , n2 , n3 , n4 , n5 , n2 , n f inal

d

Die Ausführung mit Gesamtzahl = 0 und Eingabe der Zeichenfolge HH! bewirkt eine zweimalige Ausführung des Schleifenrumpfes. Bei beiden Ausführungen wird der falsch-Zweig der Selektion durchlaufen. Das Rufzeichen bricht den Wiederholungsvorgang ab. Testpfad: nstart , n1 , n2 , n3 , n5 , n2 , n3 , n5 , n2 , n f inal

Die angegebenen sieben Testfälle sind hinreichend für den Test der Schleife nach dem boundary interior-Kriterium.

120

3 Kontrollflussorientierter, strukturorientierter Test

n1

n2

n3

n4

n5

n6

n7

n8

Abbildung 3.8 Kontrollflussgraph

Ein reales Software-Modul besteht in der Regel nicht aus einer einzelnen Schleife, sondern aus mehreren Kontrollkonstrukten, die sequenziell oder verschachtelt auftreten. Insbesondere die Verschachtelung von Schleifen kann die Anzahl der zu berücksichtigenden Fälle schnell unhandhabbar werden lassen (siehe /Riedemann 97/). Aber auch sequenzielle Strukturen verursachen einen Anstieg des Testaufwands. In Abb. 3.8 ist ein Ausschnitt eines Kontrollflussgraphen angegeben, bei dem einer Struktur, die analog zur Operation ZaehleZchn aufgebaut ist, eine Selektion vorangestellt ist. Die Pfade durch diesen Kontrollflussgraphen besitzen die folgende Form: n1 [n2 ] n3 n4 (n5 [n6 ] n7 n4 )i n8 mit i ≥ 0. Eckige Klammern kennzeichnen hier optionale Bestandteile. Hochstellungen kennzeichnen eine Wiederholung. Wendet man die in /Howden 75/ angegebenen Regeln an, so kann man zu den in Tab. 3.18 angegebenen Klassen von Pfaden gelangen, von denen jeweils mindestens einer für den Test auszuwählen ist. Mit A sind die Pfade bezeichnet, die außerhalb der Schleife mit der Knotensequenz n1 n2 n3 beginnen. Mit B sind die Pfade bezeichnet, die vor der Schleife mit n1 n3 beginnen. Nach der Regel „The boundary-interior method separates paths into separate classes if they differ other than in traversals of loops“ sind derartige Pfade in unterschiedlichen Klassen anzuordnen.

3.5 Techniken für den Test von Schleifen

121

Kategorie

Bezeichnung Pfad

ohne Schleifenausführung

A0 B0

n1 n2 n3 n4 n8 n1 n3 n4 n8

boundary-Tests

A1a A1b B1a B1b

n1 n2 n3 n4 n5 n6 n7 n4 n8 n1 n2 n3 n4 n5 n7 n4 n8 n1 n3 n4 n5 n6 n7 n4 n8 n1 n3 n4 n5 n7 n4 n8

interior-Tests

A2c A2d A2e A2f B2c B2d B2e B2f

n1 n2 n3 n4 n5 n6 n7 n4 n5 n6 n7 n4 (n5 [n6] n7 n4)i n8 n1 n2 n3 n4 n5 n6 n7 n4 n5 n7 n4 (n5 [n6] n7 n4)i n8 n1 n2 n3 n4 n5 n7 n4 n5 n6 n7 n4 (n5 [n6] n7 n4)i n8 n1 n2 n3 n4 n5 n7 n4 n5 n7 n4 (n5 [n6] n7 n4)i n8 n1 n3 n4 n5 n6 n7 n4 n5 n6 n7 n4 (n5 [n6] n7 n4)i n8 n1 n3 n4 n5 n6 n7 n4 n5 n7 n4 (n5 [n6] n7 n4)i n8 n1 n3 n4 n5 n7 n4 n5 n6 n7 n4 (n5 [n6] n7 n4)i n8 n1 n3 n4 n5 n7 n4 n5 n7 n4 (n5 [n6] n7 n4)i n8 mit i ³ 0

Tabelle 3.18 Pfadklassen

Die tiefgestellte Indices 0, 1 oder 2 bei den Bezeichnungen in Tab. 3.18 unterscheidet Pfade nach der Anzahl der Ausführungen des Schleifenrumpfes in keine, genau eine und mindestens 2 Schleifenrumpfausführungen. Der tiefgestellte Index a bis f unterscheidet die zum boundary-Test gehörenden Pfade entsprechend der durchlaufenen Teilpfade bei der Ausführung des Schleifenrumpfs bzw. die zum interior-Test gehörenden Pfade entsprechend der durchlaufenen Teilpfade bei den ersten zwei Ausführungen des Schleifenrumpfs. Weitere Wiederholungen der Schleife werden nicht beachtet. PROBLEM: Nicht ausführbare Pfade

Ein weiteres Problem des boundary interior-Tests entsteht durch nicht ausführbare Pfade. In Abb. 3.9 ist der Ausschnitt des Kontrollflussgraphen zu der folgenden Schleife angegeben: ... i = 0; while (i < n) { if (i < 4) do_this; else do_that; i = i + 1; }

...

122

3 Kontrollflussorientierter, strukturorientierter Test

...

n1

i = 0;

n2

while (i < n) { if (i < 4)

n3

n4

do_this;

else

n5

do_that;

i = i + 1;

n6 } n7

...

Abbildung 3.9 Kontrollflussgraph mit Schleife

Tab. 3.19 listet die 7 Pfadklassen auf, zu denen jeweils mindestens ein Testfall für den boundary interior-Test zu wählen ist. Die in Tab. 3.19 in kursiver Schrift notierten Pfade sind nicht ausführbar. Bei den ersten vier Ausführungen des Schleifenrumpfes wird der wahr-Zweig der Selektion durchlaufen; anschließend ausschließlich der falsch-Zweig. Da bei interior-Tests aber nur die ersten beiden Schleifendurchläufe betrachtet werden, gehören alle ausführbaren Pfade der gleichen interior-Pfadklasse an. Wegen des bei interior-Testpfaden möglichen Abbruchs der Ausführung nach dem zweiten Schleifendurchlauf, ist in diesem Fall nicht einmal eine vollständige Zweigüberdeckung sichergestellt. Der falsch-Zweig der Selektion wird erstmals beim fünften Schleifendurchlauf ausgeführt. Die Definition einer schleifentestenden Technik, die den Zweigüberdeckungstest nicht zwangsläufig sicherstellt, ist kaum sinnvoll. Darüber hinaus besitzen der boundary interior-Test und der strukturierte Pfadtest die bereits oben geschilderten Probleme im Falle umfangreicher zu testender Kontrollstrukturen. Es existieren einige heuristische Vorschläge für den Test von Schleifen, die im Sinne von Daumenregeln angewendet werden (siehe z. B. /Beizer 90/). Ich schlage im Folgenden eine modifizierte boundary interior-Testtechnik vor, die >

einen relativ geringen Aufwand verursacht,

3.5 Techniken für den Test von Schleifen

123

Kategorie

Pfad

ohne Schleifen- n1 n2 n7 ausführung

boundary-Tests

n1 n2 n3 n4 n6 n2 n7 n1 n2 n3 n5 n6 n2 n7

interior-Tests

n1 n2 n3 n4 n6 n2 n3 n4 n6 n2 (n3 n4 n6 n2 / n3 n5 n6 n2)j n7 n1 n2 n3 n4 n6 n2 n3 n5 n6 n2 (n3 n4 n6 n2 / n3 n5 n6 n2)j n7 n1 n2 n3 n5 n6 n2 n3 n4 n6 n2 (n3 n4 n6 n2 / n3 n5 n6 n2)j n7 n1 n2 n3 n5 n6 n2 n3 n5 n6 n2 (n3 n4 n6 n2 / n3 n5 n6 n2)j n7

Tabelle 3.19 Ausführbare und nicht ausführbare Pfadklassen

>

die Zweigüberdeckung subsumiert,

>

den starken Testfallanstieg durch verschachtelte Schleifen und die Einbettung von Schleifen in andere Kontrollkonstrukte vermeidet und

>

gut mit Heuristiken kombiniert werden kann.

3.5.2.2

Modifizierte boundary interior-Testtechnik

Mein modifizierter boundary interior-Test

Im Folgenden möchte ich eine modifizierte boundary interior-Testtechnik vorschlagen, die ich für besonders geeignet halte:

Regeln für Pfade außerhalb von Schleifen

1. Forderung für Testfälle unter Vernachlässigung von Schleifen:

Regeln für Pfade innerhalb von Schleifen

2. Forderungen für Testfälle unter Beachtung von Schleifen:

Es sind alle ausführbaren Pfade zu testen, die abweisende Schleifen nicht betreten und nicht-abweisende Schleifen nicht wiederholen.

>

Für jede abweisende Schleife sind alle ausführbaren Teilpfade zu testen, die –

–

>

124

den Schleifenrumpf genau einmal ausführen und sich nicht ausschließlich im Durchlauf eingeschachtelter Schleifen unterscheiden. Pfade, die ausschließlich Differenzen außerhalb der betrachteten abweisenden Schleife aufweisen, müssen nicht unterschieden werden.

Für jede abweisende und jede nicht-abweisende Schleife sind alle ausführbaren Teilpfade zu testen, die

3 Kontrollflussorientierter, strukturorientierter Test

–

–

>

den Schleifenrumpf mindestens zweimal ausführen und sich bei den ersten zwei Ausführungen des Schleifenrumpfs nicht ausschließlich im Durchlauf eingeschachtelter Schleifen unterscheiden. Pfade, die ausschließlich Differenzen außerhalb der betrachteten Schleife oder innerhalb der Schleife ab dem dritten Durchlauf aufweisen, müssen nicht unterschieden werden.

Die genannten Regeln sind für jede Schleife getrennt anzuwenden.

3. Falls Zweige nicht getestet sind, so sind entsprechende zusätzliche

Testfälle erforderlich. Die erste Forderung gewährleistet einen so genannten Pfadüberdeckungstest unter Auslassung von Schleifen. Dieser kann in der Regel für einigermaßen vernünftig entworfene Module mit vertretbarem Aufwand geleistet werden. Die unter 2. aufgelisteten Forderungen entsprechen im Wesentlichen denen des boundary interior-Tests für den Umgang mit Schleifen. Durch die Betrachtung jeweils einer einzelnen Schleife und die Nichtbeachtung der sie umgebenden Kontrollstrukturen sowie die Vernachlässigung von Pfaden, die durch eingeschachtelte Schleifen entstehen, wird eine Reduzierung der Testfälle erreicht. Die dritte Forderung stellt unabhängig von der Ausführbarkeit bestimmter Pfade die Zweigüberdeckung sicher. Meine modifizierte boundary interior-Testtechnik strebt eine Reduktion des Testaufwands durch eine modulare Betrachtung der zu testenden Software an. Für die Bereiche außerhalb von Schleifen werden getrennt von dem Komplexitätszuwachs durch Schleifen Testfälle gefordert. Jede Schleife wird einzeln betrachtet, wobei auch eingeschachtelte Schleifen ignoriert werden. Das bedeutet jedoch nicht, dass jede Schleife auch einzeln getestet werden muss, wie das folgende Beispiel (Abb. 3.10) verdeutlicht. Und schließlich wird durch eine dementsprechende explizite Forderung der Zweigüberdeckungstest sichergestellt.

Eigenschaften des modifizierten boundary interior-Tests

In Abb. 3.10 ist ein relativ komplizierter Ausschnitt eines Kontrollflussgraphen angegeben. Er stellt eine Sequenz aus einer Selektion, einer nicht-abweisenden Schleife und einer abweisenden Schleife dar. In die abweisende Schleife ist eine Sequenz aus einer Selektion und einer abweisenden Schleife eingeschachtelt. In Tab. 3.20 sind die für einen modifizierten boundary interior-Test zu durchlaufenden Pfade als Sequenz der Knotennummern aus Abb. 3.10 angegeben. Durch einen senkrechten Strich sind Alternativen getrennt; d. h. (n3 | n4 ) bedeutet, dass an dieser Stelle des Pfades genau eine der Alternativen n3 oder n4 stehen muss. Ein hochgestellter Index kennzeichnet Wiederholungen; d. h. (n5 n6 )i ; i ≥ 0 bedeutet, dass die Sequenz (n5 n6 ) an dieser Stelle beliebig oft stehen kann und auch verschwinden kann. Die jeweils relevanten Ausschnitte

3.5 Techniken für den Test von Schleifen

125

der Pfade sind in Tab. 3.20 in fetter Schrift hervorgehoben. Die Abb. 3.11 bis 3.14 stellen sie grafisch dar. Man kann in den Abbildungen erkennen, dass es möglich ist, Pfade zusammenzufassen. Für den Test sind nur die jeweils fett hervorgehobenen Teile der Pfade relevant. Die nicht hervorgehobenen Teile der Pfade können beliebig ausgeprägt werden. Es bietet sich daher an, diese entsprechend der Forderungen anderer Testpfade zu nutzen. So können z. B. die Teilpfade nach Abb. 3.12 c und Abb. 3.12 d zusammengefasst werden. Dies reduziert den Testaufwand, da mehrere geforderte Tests mit einem Testfall durchgeführt werden können. Es ist jedoch nicht sichergestellt, dass dieser Pfad, der die nicht-abweisende Schleife wiederholt und anschließend den Rumpf der abweisenden Schleife nach Abb. 3.12 d genau einmal ausführt, überhaupt ausgeführt werden kann. Anhand der Abb. 3.11 bis 3.14 ist aber leicht zu erkennen, dass alternative Kombinationsmöglichkeiten existieren. Der Teiltestpfad nach Abb. 3.12 c kann mit allen Teiltestpfaden der Abb. 3.12 d bis Abb. 3.14 k

Abbildung 3.10 Kontrollflussgraph mit Schleifen

126

3 Kontrollflussorientierter, strukturorientierter Test

Pfade unter Vernachlässigung von Schleifen

a) n1 n2 n3 n5 n6 n7 n14 b) n1 n2 n4 n5 n6 n7 n14

nicht-abweisende Schleife I

c) n1 n2 (n3 | n4) (n5 n6)i ...; i ³ 2

abweisende Schleife I: genau ein Durchlauf

d) n1 n2 (n3 | n4) (n5 n6)i n7 n8 n9 n11 (n12 n11 )j n13 n7 n14; i ³ 1; j³ 0 e) n1 n2 (n3 | n4) (n5 n6)i n7 n8 n10 n11 (n12 n11 )j n13 n7 n14; i ³ 1; j³ 0

abweisende Schleife I: mindestens zwei Durchläufe

f) n1 n2 (n3 | n4) (n5 n6)i n7 n8 n9 n11 (n12 n11 )j n13 n7 n8 n9 n11 (n12 n11 )k ... n7 n14; i ³ 1; j, k ³ 0 g) n1 n2 (n3 | n4) (n5 n6)i n7 n8 n9 n11 (n12 n11 )j n13 n7 n8 n10 n11 (n12 n11 )k ... n7 n14; i ³ 1; j, k ³ 0 h) n1 n2 (n3 | n4) (n5 n6)i n7 n8 n10 n11 (n12 n11 )j n13 n7 n8 n9 n11 (n12 n11 )k ... n7 n14; i ³ 1; j, k ³ 0 i) n1 n2 (n3 | n4) (n5 n6)i n7 n8 n10 n11 (n12 n11 )j n13 n7 n8 n10 n11 (n12 n11 )k ... n7 n14; i ³ 1; j, k ³ 0

abweisende Schleife II: genau ein Durchlauf

j) n1 n2 (n3 | n4) (n5 n6)i (n7 n8 (n9 | n10) n11 (n12 n11 )k n13)j n7 n8 (n9 | n10) n11 n12 n11 n13 (n7 n8 (n9 | n10) n11 (n12 n11 )l n13)m n7 n14; i ³ 1; k, j, l, m ³ 0

abweisende Schleife II: zwei Durchläufe

k) n1 n2 (n3 | n4) (n5 n6)i (n7 n8 (n9 | n10) n11 (n12 n11 )k n13)j n7 n8 (n9 | n10) n11 (n12 n11)l n13 (n7 n8 (n9 | n10) n11 (n12 n11 )m n13)p n7 n14; i ³ 1; k, j, m, p ³ 0; l ³ 2

Tabelle 3.20 Testpfade des modifizierten boundary interior-Tests

kombiniert werden. Durch derartige Kombinationen, z. B. Abb. 3.12 c mit Abb. 3.12 d, Abb. 3.13 h mit Abb. 3.14 j und Abb. 3.13 i mit Abb. 3.14 k kann eine Reduzierung auf acht Testfälle erreicht werden. Falls aufgrund nicht ausführbarer Teiltestpfade Zweige nicht ausgeführt werden, so sind zusätzliche Testpfade zu wählen, um die vollständige Zweigüberdeckung zu erreichen. /Beizer 90/ schlägt vor, beim Test von Schleifen auch die maximale Anzahl von Schleifendurchläufen zu testen sowie den Versuch zu unternehmen, die maximale Anzahl von Durchläufen zu überschreiten. Ich halte das für sinnvoll. Anders als eine kleine Anzahl von Schleifenwiederholungen wird eine große Wiederholungsanzahl durch den boundary interior-Test nicht zwingend geeignet berücksichtigt, da interior-Tests nach dem zweiten Schleifendurchlauf abgebrochen werden können. Die Wahl einer hohen Anzahl von Wiederholungen ist in interior-Tests aber durchaus möglich. Ich empfehle dringend, dies zu berücksichtigen.

Grenzwerte für Schleifen beachten

Mein modifizierter boundary interior-Test kann sehr einfach zu einem modifizierten strukturierten Pfadtest (mit Parameter k) verallgemeinert werden, indem die oben angegebenen Forderungen von k=2 auf Werte größer als 2 übertragen werden.

3.5 Techniken für den Test von Schleifen

127

3.5.2.3

Bewertung

Eine vergleichende Studie /Howden 78a, Howden 78b, Howden 78c/ anhand von sechs Programmen in Algol, Cobol, PL/1, Fortran und PL360 mit insgesamt 28 Fehlern hat für den strukturierten Pfadtest eine Quote von 12 entdeckten Fehlern ergeben. Dies ist gegenüber dem Zweigüberdeckungstest eine um den Faktor zwei höhere Erfolgsquote. 18 Fehler sind mit Hilfe des Pfadüberdeckungstests erkannt worden. Während der Zweigüberdeckungstest nur in einem der sechs Programme zur Entdeckung aller Fehler geführt hat, sind mit Hilfe des strukturierten Pfadtests alle Fehler in drei Programmen erkannt worden. Miller /Infotech Vol.1 79/ gibt für den strukturierten Pfadtest eine Erfolgsquote von 65 % an. Da der boundary interior-Test ein Spezialfall des strukturierten Pfadtests ist, ist eine ähnliche Leistungsfähigkeit zu erwarten.

128

3 Kontrollflussorientierter, strukturorientierter Test

a)

Abbildung 3.11 Testpfad des modifizierten boundary interior-Tests

3.5 Techniken für den Test von Schleifen

129

b)

c)

mindestens einmal

d)

e)

genau einmal

genau einmal

Abbildung 3.12 Testpfad des modifizierten boundary interior-Tests (Fortsetzung) 130

3 Kontrollflussorientierter, strukturorientierter Test

f)

g)

mindestens zweimal

1.

h)

2.

i)

mindestens zweimal

2.

1.

Abbildung 3.13 Testpfad des modifizierten boundary interior-Tests (Fortsetzung)

3.5 Techniken für den Test von Schleifen

131

j)

k)

genau einmal

mindestens zweimal

Abbildung 3.14 Testpfad des modifizierten boundary interior-Tests (Fortsetzung)

Der LCSAJ-Test ist ursprünglich für nichtlineare Programmiersprachen konzipiert worden.

3.5.3

LCSAJ-Test

3.5.3.1

Eigenschaften und Ziele des LCSAJ-Tests

Das Testverfahren zur Überdeckung linearer Codesequenzen nimmt eine Stellung zwischen dem Zweigüberdeckungstest und dem Pfadüberdeckungstest ein. In der ursprünglichen Form ist es sinnvoll einsetzbar für den Test von Programmen, deren Programmiersprache umfassenden Gebrauch von Sprüngen macht (z. B. Fortran oder Basic). Mit der schwindenden Bedeutung derartiger Programmiersprachen verringern sich auch die Anwendungsmöglichkeiten des LCSAJ-Tests. Eine lineare Codesequenz (LCSAJ – Linear Code Sequence And Jump) ist eine Folge von Anweisungen, die sequentiell ausgeführt wird und durch einen Sprung auf eine andere Anweisung als die folgende beendet wird /Woodward et al. 80/. Eine LCSAJ wird eindeutig durch ein Tripel, bestehend aus der ersten und der letzten Anweisung der LCSAJ, sowie dem Sprungziel festgelegt. LCSAJs sind dicht am Programmtext orientiert, während sich die Mehrzahl der Testtechniken auf den Kontrollflussgraphen stützt. Zu einem Kontrollflussgraphen existieren in der Regel

132

3 Kontrollflussorientierter, strukturorientierter Test

mehrere mögliche textuelle Umsetzungen des Software-Moduls mit unterschiedlichen LCSAJs. Die vollständige Überdeckung aller LCSAJs stellt eine vollständige Zweigüberdeckung sicher. Auch in fehlerfreien Software-Modulen können nicht ausführbare LCSAJs vorkommen /Hedley, Hennell 85/. Dieses Verhalten entsteht durch die Kombination mehrerer Zweige zu einer linearen Codesequenz, die im Programmablauf nicht auftritt. Da LCSAJs Teilpfade aus einer variablen Anzahl – im Allgemeinen größer als eins – von Zweigen sind, ergibt sich diese Analogie zur Problematik der nicht ausführbaren Pfade des Pfadüberdeckungstests. Das Ziel des Testverfahrens ist die Überdeckung aller möglichen LCSAJs eines Programms.

Da der LCSAJ-basierte Test zunächst für Sprachen ohne notwendig linearen Kontrollfluss entwickelt worden ist, wird hier ein Beispiel anhand eines Fortran-Unterprogramms angegeben, das zwei Werte entsprechend ihrer Größe ordnet und prüft, ob die Werte gleich groß sind.

BEISPIEL

Die in Abb. 3.15 angegebene Fortran-Routine enthält fünf mögliche LCSAJs: 1. Beginn in Zeile 1 2. Beginn in Zeile 1 3. Beginn in Zeile 1 4. Beginn in Zeile 5 5. Beginn in Zeile 8

Ende in Zeile 4 Ende in Zeile 2 Ende in Zeile 2 Ende in Zeile 9 Ende in Zeile 9

Exit Sprung nach Zeile 5 Sprung nach Zeile 8 Exit Exit

Eine Überdeckung aller fünf LCSAJs ist mit drei Testfällen möglich, von denen einer die LCSAJ 1, einer die LCSAJs 2 und 4 und der verbleibende die LCSAJs 3 und 5 überdeckt.

Abbildung 3.15 Fortran-Routine mit LCSAJs

Testfall 1: Min = Max = 100 ⇒ LCSAJ: 1 Testfall 2: Min = 100, Max = 50 ⇒ LCSAJs: 2, 4 Testfall 3: Min = 50, Max = 100 ⇒ LCSAJs: 3, 5

3.5 Techniken für den Test von Schleifen

133

Als Maß für die erreichte Überdeckung kann der Quotient aus der Anzahl der mindestens einmal ausgeführten LCSAJs und der Gesamtanzahl der LCSAJs benutzt werden /Woodward et al. 80/.

3.5.3.2 Test von LCSAJ-Kombinationen

Erweiterungen

Basierend auf der Überdeckung linearer Codesequenzen kann eine Familie hierarchischer Testverfahren und zugehöriger Überdeckungsmaße definiert werden, indem gefordert wird, dass alle Teilpfade, die aus n LCSAJs bestehen, und alle vollständigen Pfade, die bis zu n LCSAJs enthalten, getestet werden /Woodward et al. 80/. Die zugehörige Überdeckungsrate ist der Quotient der Anzahl der ausgeführten Pfade und der Anzahl der vorhandenen Pfade entsprechend des gewählten Kriteriums. Das Überdeckungsmaß TERm (Test Effectiveness Ratio) misst die Überdeckung aller Subpfade, die aus m-2 LCSAJs bestehen und aller vollständigen Pfade, die bis zu m-2 LCSAJs enthalten. Allgemein gilt: T ERm =

Anzahl der ausgeführten Subpfade aus m - 2 LCSAJs +Anzahl der ausgeführten vollständigen Pfade bis zu m - 2 LCSAJs Anzahl der Subpfade aus m - 2 LCSAJs +Anzahl der vollständigen Pfade bis zu m - 2 LCSAJs

Die Anweisungs- und die Zweigüberdeckung können per Definition in die Hierarchie der TER-Masse integriert werden: T ER2 =

Anzahl der ausgeführten Anweisungen Anzahl der Anweisungen

T ER2 =

Anzahl der ausgeführten Zweige Anzahl der Zweige

Für die so definierten Maße gilt: TERm = 1 ⇒ TERm−1 = 1 ⇒ . . . ⇒ TER3 = 1 ⇒ TER2 = 1 ⇒ TER1 = 1 Eine vollständige Überdeckung der Pfade aus m LCSAJs stellt eine vollständige Überdeckung der Pfade aus weniger als m LCSAJs sicher. Enthält ein Programm keinen Pfad, der länger als m LCSAJs ist, so entspricht der TERm+2 -Test dem Pfadtest. Anwendung des LCSAJ-Tests auf lineare Sprachen durch Definition des „Sprungs im weiteren Sinne“

134

Die beschriebene Form des Tests ist zunächst nicht für Sprachen geeignet, die sich linearer Sprachkonstrukte bedienen und auf Sprünge weitgehend verzichten, wie Pascal, ADA, C oder Java. Eine Erweiterung der Anwendbarkeit des Tests von LCSAJs auf in diesen Sprachen implementierte Programme, ist durch Verallgemeinerung des Sprungbegriffs möglich /Hennell et al. 77/.

3 Kontrollflussorientierter, strukturorientierter Test

>

Ein Sprung im weiteren Sinne ist ein Kontrolltransfer von einer Programmzeile m zu einer Zeile n, mit n = m, unter der Voraussetzung, dass zwischen den zwei Zeilen ausführbarer Code existiert.

Das Fortran-Unterprogramm kann als C++-Operation folgendermaßen realisiert werden:

BEISPIEL

bool MinMaxTest::MinMax (int& Min, int& Max) { int Hilf; if (Min == Max) return (false); else if (Min > Max) { Hilf = Min; Min = Max; Max = Hilf; } return (true); }

Die C++-Operation MinMax enthält fünf mögliche LCSAJs: 1. Beginn in Zeile 1 2. Beginn in Zeile 1 3. Beginn in Zeile 6 4. Beginn in Zeile 11 5. Beginn in Zeile 6

Ende in Zeile 5 Ende in Zeile 4 Ende in Zeile 6 Ende in Zeile 12 Ende in Zeile 12

Exit Sprung nach Zeile 6 Sprung nach Zeile 11 Exit Exit

Testfall 1: Min = Max = 100 ⇒ LCSAJ: 1 Testfall 2: Min = 100, Max = 50 ⇒ LCSAJs: 2, 5 Testfall 3: Min = 50, Max = 100 ⇒ LCSAJs: 2, 3, 4 Die Operation ZaehleZchn enthält acht LCSAJs: 1 2 3

void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl) { char Zchn;

4 5

cin >> Zchn; while (( Zchn >= ’A’ ) && ( Zchn > Zchn; } }

6 7 8

9 10 11 12

3.5 Techniken für den Test von Schleifen

135

1. Beginn in Zeile 1, 2. Beginn in Zeile 11, 3. Beginn in Zeile 1, 4. Beginn in Zeile 5, 5. Beginn in Zeile 5, 6. Beginn in Zeile 10, 7. Beginn in Zeile 5, 8. Beginn in Zeile 1,

Ende in Zeile 5, Ende in Zeile 12, Ende in Zeile 11, Ende in Zeile 11, Ende in Zeile 8, Ende in Zeile 11, Ende in Zeile 5, Ende in Zeile 8,

Sprung nach Zeile 11 Exit Sprung nach Zeile 5 Sprung nach Zeile 5 Sprung nach Zeile 10 Sprung nach Zeile 5 Sprung nach Zeile 11 Sprung nach Zeile 10

Testfall 1: Aufruf mit Gesamtzahl = 0, Zchn = ’1’ ⇒ LCSAJs: 1, 2 Testfall 2: Aufruf mit Gesamtzahl = 0, Zchn = ’A’, ’E’, ’B’, ’1’ ⇒ LCSAJs: 3, 4, 5, 6, 7, 2 Testfall 3: Aufruf mit Gesamtzahl = 0, Zchn = ’B’, ’1’ ⇒ LCSAJs: 8, 6, 7, 2

3.5.3.3

Bewertung des LCSAJ-Tests

Die Studie von /Girgis, Woodward 86/ hat für den Test von Fortran-Programmen den LCSAJ-basierten Test als leistungsfähigstes Kriterium unter den verglichenen Verfahren ermittelt. Insgesamt sind 85 % der Fehler gefunden worden (Zweigüberdeckung: 34 %). Die Kontrollflussfehler sind vollständig entdeckt worden und 80 % der Berechnungsfehler sind identifiziert worden.

3.6 3.6.1 Der Pfadüberdeckungstest ist gründlich, aber oft nicht durchführbar.

Pfadüberdeckungstest Eigenschaften und Ziele des Pfadüberdeckungstests

Der Pfadüberdeckungstest (path coverage) ist eine umfassende kontrollflussorientierte Testtechnik. Umfassender ist allein der so genannte erschöpfende Test. Dieser verlangt die Prüfung aller möglichen Eingaben in allen Betriebssituationen. Er ist im Allgemeinen nicht durchführbar. Allerdings ist auch ein vollständiger Pfadüberdeckungstest in der Regel nicht sinnvoll durchführbar. Der Pfadüberdeckungstest fordert die Ausführung aller unterschiedlichen Pfade des zu testenden Software-Moduls. Ein Pfad p ist eine Sequenz von Knoten (nstart , n1 ,. . . , nm , n f inal ) des Kontrollflussgraphen. Zwei Pfade sind nur dann identisch, falls die Sequenzen ihrer Knoten identisch sind. Der Pfadüberdeckungstests subsumiert die in diesem Kapitel beschriebenen Testtechniken mit Ausnahme der Bedingungsüberdeckungstests. Der Pfadüberdeckungstest ist für reale Software-Module oft nicht durchführbar, da sie eine unendlich hohe Anzahl von Pfaden besitzen können /Howden 76/, /Howden 81/, /Tai 80/. Aber auch wenn die Pfadanzahl endlich ist, ist sie oft zu hoch für eine wirtschaftliche Testdurchführung.

136

3 Kontrollflussorientierter, strukturorientierter Test

Eine hohe Pfadanzahl wird in der Regel von Schleifen verursacht, die keine feste Wiederholungsanzahl besitzen. Jede Wiederholung erzeugt einen neuen Pfad durch Hinzufügung des Teilpfads des Schleifenkörpers. Daher existieren die bereits dargestellten Verfahren, die Beschränkungen für den Test von Schleifen vorsehen

Die Pfade der Operation ZaehleZchn beginnen mit dem Teilpfad p = (nstart , n1 ). Darauf folgen i (i ≥ 0) Subpfade q, gefolgt vom Subpfad r = (n2 , n f inal ). Jeder der i Subpfade q kann entweder die Form (n2 , n3 , n4 , n5 ) oder die Form (n2 , n3 , n5 ) besitzen.

BEISPIEL

In ZaehleZchn ist die Anzahl der Schleifendurchläufe durch den Wert der Variablen Gesamtzahl begrenzt. Gesamtzahl wird bei jeder Ausführung des Schleifenrumpfs um 1 erhöht. Wenn Gesamtzahl den Wert der Konstanten INT_MAX erreicht, so wird die Schleifenausführung beendet. Falls INT_MAX den Wert 32767 besitzt, so kann der Schleifenrumpf maximal 32767-mal durchlaufen werden, bevor abgebrochen wird. Für diese Schleife kann eine maximale Anzahl von Durchläufen angegeben werden, die sicher nicht überschritten wird. Daher ist die betrachtete Schleife im Vergleich zu Schleifen, die eine unbeschränkte Anzahl von Wiederholungen zulassen, als eher harmlos einzuordnen. Auf die Frage nach der Anzahl der Testpfade erhält man ein überraschendes Ergebnis. Es gibt genau einen Pfad, der die Schleife nicht ausführt. Zwei unterschiedliche Pfade führen die Schleife einmal aus. Zwei Schleifendurchläufe können auf vier verschiedene Weisen – d. h. mit vier unterschiedlichen Pfaden – durchgeführt werden. Zu drei Schleifendurchläufen existieren 8 Pfade; allgemein: Zu n Schleifendurchläufen gehören 2n Pfade. Die Pfadanzahl der Operation ZaehleZchn ist daher: 1 + 2 + 4 + 8 + .... + 232767 . Diese Summe ist eine so genannte endliche geometrische Reihe, deren Wert sehr einfach bestimmt werden kann; er beträgt 232768 -1. Dies entspricht etwa 1, 41 · 109864 Pfaden. Die erforderliche Testdauer bei einem Tag und Nacht pausenlos durchlaufenden Test und einer zugrundegelegten Testintensität von 1000 Pfaden pro Sekunde würde 4, 5 · 109853 Jahre dauern. Zum Vergleich: Das Alter der Erde wird mit etwas mehr als 4, 5 · 109 Jahren angegeben. Ein vollständiger Pfadüberdeckungstest der Operation ZaehleZchn ist daher absolut ausgeschlossen. Neben der zu hohen Pfadanzahl, die die Unpraktikabilität des Pfadtests verursacht, ist ein weiteres Problem die Nichtausführbarkeit eines Teils der anhand des Kontrollflussgraphen konstruierbaren Pfade. Die Bewertung, ob ein Pfad ausführbar ist, ist im Allgemeinen schwierig.

3.6.2

Bewertung des Pfadüberdeckungstests

Der Pfadüberdeckungstest besitzt aufgrund seiner sehr eingeschränkten Durchführbarkeit keine praktische Bedeutung.

3.6 Pfadüberdeckungstest

Der Pfadüberdeckungstest ist unpraktikabel.

137

In einer vergleichenden Studie /Howden 78a, Howden 78b, Howden 78c/ hat der Pfadtest zur Erkennung von 18 von 28 Fehlern geführt. Dies ist eine um den Faktor drei höhere Erfolgsquote als die des Zweigüberdeckungstests und noch um fünfzig Prozent höher als die Quote des strukturierten Pfadtests. Der Pfadtest besitzt unter den verglichenen Verfahren die höchste Erfolgsquote und wird nur durch den kombinierten Einsatz anderer Verfahren übertroffen.

3.7

Bewertung des kontrollflussorientierten Tests

Kontrollflussorientiertes Testen ist unverzichtbar.

Die kontrollflussorientierten Testtechniken sind sehr wichtig; so wichtig, dass die Frage nach ihrer Leistungsfähigkeit zum Teil hinter andere Motivationen zu ihrer Verwendung zurücktritt. Der Zweigüberdeckungstest ist ein allgemein akzeptiertes Minimalkriterium des strukturorientierten SoftwareTests, so dass ein Test, der keine vollständige Zweigüberdeckung erreicht, als nicht hinreichend angesehen werden mag. Neben diesem eher als „common sense“ anzusehenden Sachverhalt existieren in einigen Anwendungsbereichen explizite Forderungen, bestimmte Testtechniken einzusetzen. Im strukturorientierten Test sind das fast immer Forderungen nach bestimmten kontrollflussorientierten Techniken.

Es sind viele kontrollflussorientierte Testwerkzeuge verfügbar.

Der Testwerkzeugmarkt hat den fundamentalen Charakter der kontrollflussorientierten Testtechniken ebenfalls erkannt. Die Abdeckung mit Testwerkzeugen ist gut. Ein akzeptierter Modultest von Software besteht heute aus einer funktions- und einer strukturorientierten Technik. Die strukturorientierte Technik ist aus pragmatischen Gründen in der Regel eine kontrollflussorientierte Technik. Ich empfehle Ihnen, die Punkte der folgenden Checkliste für Ihren Test zu überprüfen:

CHECKLISTE

> > > >

>

138

Falls Sie bisher keinen Zweigüberdeckungstest durchführen, so sollten Sie das möglichst bald ändern. Kaufen Sie kein Anweisungsüberdeckungstestwerkzeug. Der Anweisungsüberdeckungstest gilt als zu schwach. Beachten Sie bei der Auswahl die Subsumptionshierarchie der Testtechniken (Abb. 3.16). Prüfen Sie, ob es für Ihren Anwendungsbereich Standards gibt, die Forderungen im Bereich des kontrollflussorientierten Tests enthalten. Für Avionik existiert z. B die Norm RTCA DO 178 B. Falls Ihr Quellcode typischerweise viele Entscheidungen enthält, die aus Teilentscheidungen zusammengesetzt sind, so sollten Sie über die Verwendung von Bedingungsüberdeckungstests nachdenken. Der modifizierte Bedingungs-/Entscheidungsüberdeckungstest ist ein guter Kompromiss aus Testaufwand und Ergebnisqualität.

3 Kontrollflussorientierter, strukturorientierter Test

>

Falls viele Schleifen mit variabler Wiederholungsanzahl vorkommen, so sollten Sie die Verwendung entsprechender Testtechniken erwägen. Ich empfehle Ihnen meinen modifizierten boundary interior-Test. Es gibt einige Testwerkzeuge, die eine LCSAJ-Abdeckung messen.

>

Über eine Anwendung des Pfadüberdeckungstests müssen Sie nicht grübeln. Für die meisten realen Softwaremodule ist er schlicht nicht durchführbar.

Pfadüberdeckungstest

Mehrfach-Bedingungsüberdeckungstest

Modifizierter Bedingungs-/Entscheidungsüberdeckungstest Strukturierter Pfadtest (k ³ 2)

LCSAJ-Test

Modifizierter boundary interior-Test

Minimaler MehrfachBedingungsüberdeckungstest

Boundary interior-Test Bedingungs-/Entscheidungsüberdeckungstest Zweigüberdeckungstest

Anweisungsüberdeckungstest

Einfacher Bedingungsüberdeckungstest

Abbildung 3.16 Subsumptionshierarchie der kontollflussorientierten Testtechniken

3.7 Bewertung des kontrollflussorientierten Tests

139

“This page left intentionally blank.”

4 Datenflussorientierter, strukturorientierter Test In diesem Kapitel werden dynamische Testtechniken beschrieben, die wie die in Kapitel 3 dargestellten Techniken die Vollständigkeit des Tests anhand der Abdeckung des Software-Quellcodes beurteilen. Im Unterschied zu den kontrollflussorientierten Techniken des Kapitels 3 nutzen die hier beschriebenen Techniken den Datenfluss zur Beurteilung der Vollständigkeit einer Menge von Testfällen. Die datenflussorientierten Testverfahren verwenden die Zugriffe auf Variablen. Jedes Software-Modul enthält Daten, die verarbeitet werden, und Kontrollstrukturen, die die Verarbeitung steuern. Im Unterschied zu den kontrollflussorientierten Testtechniken rücken die datenflussorientierten Testtechniken das Hantieren mit Daten in den Testmittelpunkt. Dies ist besonders dann sinnvoll, wenn die zur Software-Entwicklung verwendete Methodik den Daten eine zentrale Bedeutung beimisst. Das ist insbesondere bei den verbreiteten objektorientierten Entwicklungsmethoden und Programmiersprachen erfüllt. In der Objektorientierung werden Operationen um gemeinsam genutzte Daten – die Attribute – gruppiert. Das entstehende Gebilde bezeichnet man als Klasse, seine Instanzen als Objekte. Es ist anzunehmen, dass ein datenflussorientiert durchgeführter Test von Klassen erheblich bessere Aussagen liefert als ein kontrollflussorientierter Klassentest. Leider existiert kaum Werkzeugunterstützung für datenflussorientierte Testtechniken. Dies gilt im Wesentlichen auch für Testwerkzeuge, die auf objektorientierte Software-Entwicklungen zielen. Die praktische Nutzbarkeit datenflussorientierter Testtechniken ist daher stark eingeschränkt.

Übersicht 4.1

Eigenschaften und Ziele des datenflussorientierten Tests . . . . 142

4.2

Defs/Uses-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

4.3

Required k-Tuples Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

4.4

Datenkontext-Überdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

4.5

Bewertung des datenflussorientierten Tests . . . . . . . . . . . . . . . . 177 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

141

4.1

Eigenschaften und Ziele des datenflussorientierten Tests

Da die datenflussorientierten Testtechniken der Gruppe der strukturorientierten Testtechniken angehören, besitzen sie alle entsprechenden Vorund Nachteile. Die Testvollständigkeit wird anhand der Abdeckung von Datenzugriffen mit Testfällen bewertet. Die Beurteilung der Korrektheit der erzeugten Ausgabewerte geschieht gegen die Spezifikation. Wie alle strukturorientierten Testtechniken definieren auch die datenflussorientierten Testtechniken keine direkten Regeln zur Testfallerzeugung. Dieser Freiheitsgrad kann dazu genutzt werden, die Testfälle mit funktionsorientierten Testtechniken zu erzeugen und den datenflussorientierten Test lediglich zur Messung der Testvollständigkeit zu verwenden. Aufgrund der Datenzentriertheit in der objektorientierten Software-Entwicklung sind datenflussorientierte Testtechniken insbesondere für den objektorientierten Modultest – das Testen von Klassen – geeignet Datenflussorientierte Testtechniken besitzen aber auch eine sehr große Bedeutung für den Integrationstest. Die Grundlage für datenflussorientiertes Testen bildet eine erweiterte Variante des Kontrollflussgraphen (siehe 8.3.2.1). Dieser mit so genannten Datenflussattributen versehene Kontrollflussgraph wird im Folgenden erläutert. Nachdem eine Variable im Speicher angelegt ist, können bis zu ihrer Vernichtung – z. B. am Programmende – nur zwei Dinge mit ihr geschehen:

Achtung: Definition = Deklaration

c-use p-use

>

Sie kann schreibend zugegriffen werden, d. h., ihr Wert wird gegebenenfalls verändert.

>

Sie kann lesend zugegriffen werden, d. h., ihr Wert wird nicht verändert.

Schreibende Zugriffe bezeichnet man auch als Definition. Lesende Zugriffe bezeichnet man als Referenz (engl. reference, kurz: r) oder als Benutzung (engl. use, kurz: u). In der Programmierung gibt es zwei mögliche Ursachen für lesende Zugriffe auf Variablen. Entweder dient der gelesene Variablenwert als Eingabedatum einer Berechnung oder zur Ermittlung eines Wahrheitswertes in einer Entscheidung. Die erstgenannte Form des Zugriffs bezeichnet man als berechnende Benutzung (engl. computational-use, kurz: c-use). Die letztgenannte Form des lesenden Zugriffs bezeichnet man als prädikative Benutzung (engl. predicate-use, kurz: p-use). Jeder Variablenzugriff kann daher in eine der drei Kategorien

142

>

definition (def)

>

computational use (c-use) oder

>

predicate use (p-use)

4 Datenflussorientierter, strukturorientierter Test

eingeordnet werden. Wertzuweisungen an Variablen und berechnende Benutzungen (c-uses) von Variablen werden den Knoten des Kontrollflussgraphen zugeordnet. Einem Knoten wird eine Definition (def) bezüglich einer Variablen zugeordnet, falls eine Anweisung, die durch den Knoten dargestellt wird, eine Wertzuweisung der betrachteten Variablen vornimmt. Dies gilt analog für c-uses. >

Die Anweisung y := f(x1 , . . . ,xn ) enthält c-uses der Variablen x1 , . . . ,xn , gefolgt von einer Definition (def) der Variablen y.

>

Eine Eingabeanweisung bezüglich x1 , . . . ,xn enthält Definitionen der Variablen x1 , . . . ,xn .

>

Eine Ausgabeanweisung bezüglich x1 , . . . ,xn enthält c-uses der Variablen x1 , . . . ,xn .

>

Die Anweisung if p(x1 , . . . ,xn ) ... enthält prädikative Benutzungen (p-uses) der Variablen x1 , . . . ,xn .

Da Entscheidungen den Kontrollfluss des Programms bestimmen, werden die entsprechenden p-uses in der Darstellung der Defs/Uses-Kriterien nach Rapps und Weyuker den Kanten des Kontrollflussgraphen zugeordnet. Ist die letzte Anweisung eines Knotens eine Entscheidung, in der die Variablen x1 bis xn verwendet werden, so werden allen von diesem Knoten ausgehenden Kanten des Kontrollflussgraphen prädikative Benutzungen p-uses von x1 bis xn zugeordnet. Die Zuordnung von p-uses zu Kanten stellt bei einigen Testverfahren sicher, dass die Zweigüberdeckung als akzeptiertes Minimalkriterium erreicht wird. Eine Zuordnung von p-uses zu Knoten, wie sie durch das im Folgenden noch dargestellte Required k-Tuples Kriterium vorgenommen wird, ist prinzipiell auch im Rahmen der Defs/Uses-Kriterien möglich /Clarke et al. 85/, verursacht jedoch eine kompliziertere Notation der Testtechniken. Defs, c-uses und p-uses werden als Datenflussattribute bezeichnet. Der um diese Attribute erweiterte Kontrollflussgraph heißt datenflussattributierter Kontrollflussgraph. Er kann automatisch durch ein Werkzeug aus einem gegebenen Quellcode erzeugt werden, da bei einem Datenzugriff anhand der Syntax einwandfrei festgestellt werden kann, um welches Datenflussattribut es sich handelt. Die hier betrachteten Module besitzen im Allgemeinen eine Parameterschnittstelle, über die Daten in das Modul eingegeben bzw. an die Umgebung ausgegeben werden können. Dieser Datenfluss muss ebenfalls durch entsprechende Erweiterungen des Kontrollflussgraphen beschrieben werden. Man führt zu diesem Zweck zusätzliche Knoten nin und nout in die Datenflussdarstellung des Kontrollflussgraphen ein. Sie beschreiben einen Informationsimport bzw. einen Informationsexport über Schnittstellenparameter oder globale Variablen. Dem Knoten nin werden Definitionen aller importierten – d. h. vorbelegten – Variablen zugeordnet. Dem Knoten nout werden c-uses aller exportierten Variablen

4.1 Eigenschaften und Ziele des datenflussorientierten Tests

Importknoten Exportknoten

143

nstart

def (Gesamtzahl) def (VokalAnzahl)

nin

void ZaehleZchn (int &VokalAnzahl, int & Gesamtzahl) {

def (Zchn)

p-use (Zchn) p-use (Gesamtzahl) c-use (Gesamtzahl) def (Gesamtzahl)

n1

char Zchn; cin >> Zchn;

n2

while ((Zchn >=‘A‘) && (Zchn > Zchn;

n6

} c-use (VokalAnzahl) c-use (Gesamtzahl)

nout

}

nfinal

Abbildung 4.1 Kontrollflussgraph – Datenflussdarstellung

– d. h. mit gültigen Wert herausgegebenen – Variablen zugeordnet. Im Grunde ist dies die Verwendung eines „Ersatzschaltbildes“. Man zieht quasi die außerhalb des betrachteten Moduls liegenden Definitionen und uses von Variablen in das Modul hinein, so dass ein abgeschlossenes Gebilde ohne Schnittstellen erzeugt wird. Abb. 4.1 zeigt den mit Datenflussattributen versehenen Kontrollflussgraphen der Operation ZaehleZchn.

4.2

Defs/Uses-Test

Die Defs/Uses-Kriterien definieren Testvollständigkeitskriterien auf der Basis von Variablenzugriffen. Sie verwenden die Abdeckung der defs, c-uses und p-uses durch Testfälle als Testendekriterien.

144

4 Datenflussorientierter, strukturorientierter Test

void MinMax (int& Min, int& Max) { int Hilf;

BEISPIEL

if (Min > Max) { Hilf = Min; Min = Max; Max = Hilf; } }

Der mit Datenflussattributen versehene Kontrollflussgraph der Operation MinMax ist in Abb. 4.2 dargestellt.

Abbildung 4.2 Kontrollflussgraph zu MinMax

Ein berechnender Variablenzugriff (c-use) ist global, falls keine Definition der Variablen im gleichen Block vorausgeht. Andernfalls ist er lokal. Die c-uses bezüglich Min und Max in Knoten n2 des Kontrollflussgraphen nach Abb. 4.2 sind global, da die letzte unmittelbar vorangehende Definition in Knoten nin geschieht. Der berechnende Variablenzugriff auf Hilf ist – wegen der im gleichen Block vorangestellten Definition – lokal. Ein Pfad p = (nin , . . . , nm ), der keine Definitionen einer Variablen x in nin , . . . , nm enthält, heißt definitionsfrei (def-clear wrt x) bezüglich x. Die Definition einer Variablen x in Knoten ni erreicht eine berechnende Benutzung von x in Knoten n j , falls ein Subpfad (ni )·p·(n j ) existiert, und p definitionsfrei bezüglich x ist. Die Definition einer Variablen x in Knoten ni erreicht eine prädikative Benutzung von x in Kante (n j , nk ), falls ein Sub-

4.2 Defs/Uses-Test

Globaler vs. lokaler Variablenzugriff

def-clear wrt x: definition-clear with respect to x

145

Vergleiche Kapitel 8: du-Datenflussanomalie

Die Menge def (ni )

BEISPIEL

Die Menge dcu(x, ni )

Die Menge dpu(x, ni )

BEISPIEL

pfad (ni )·p·(n j , nk ) existiert und p·(n j ) definitionsfrei bezüglich x ist. Die Definition einer Variablen x ist global, falls sie die letzte Definition von x in Knoten ni ist und mindestens ein definitionsfreier Pfad bezüglich x von Knoten ni zu einem Knoten n j , der einen globalen berechnenden Zugriff auf x enthält, oder zu einer Kante, die einen prädikativen Zugriff auf x enthält, existiert. Eine Definition ist lokal, falls ein lokaler berechnender Zugriff existiert, der auf die Definition folgt, und zwischen Definition und Zugriff keine weitere Definition existiert. Definitionen, die weder lokal noch global sind, werden nicht benutzt und weisen auf einen Programmfehler hin. Zur Verdeutlichung der Vorgehensweise der Testverfahren ist es notwendig, jedem Knoten ni des Kontrollflussgraphen die Menge der in ihm global definierten Variablen (def (ni )) und globalen berechnenden Zugriffe (c-use(ni )) zuzuordnen. Jeder Kante (ni , n j ) wird die Menge der Variablen zugeordnet, für die ein prädikativer Zugriff erfolgt (p-use(ni , n j )).

Für das Beispiel nach Abb. 4.2 gilt: Knoten ni nin n1 n2 nout

def (ni ) {Min, Max} {} {Min, Max} {}

Kanten (n1 ,n2 ) (n1 ,nout )

p-use {Min, Max} {Min, Max}

c-use(ni ) {} {} {Min, Max} {Min, Max}

Für einen Knoten ni und eine Variable x mit x ∈ def (ni ) ist dcu(x, ni ) die Menge aller Knoten n j , für die x ∈ c-use(n j ) ist und für die ein definitionsfreier Pfad bezüglich x von Knoten ni nach Knoten n j existiert. Die Menge dpu(x, ni ) ist die Menge aller Kanten (n j , nk ), für die x ∈ p-use(n j ,nk ) und für die ein definitionsfreier Pfad bezüglich x von ni nach (n j , nk ) existiert.

Für das Beispiel nach Abb. 4.2 gilt: Variable x Min Min Max Max

Knoten ni nin n2 nin n2

dcu(x,ni ) {n2 ,nout } {nout } {n2 ,nout } {nout }

dpu(x,ni ) {(n1 ,n2 ),(n1 ,nout )} {} {(n1 ,n2 ),(n1 ,nout )} {}

Auf Basis des mit Datenflussattributen versehenen Kontrollflussgraphen können Testtechniken definiert werden.

146

4 Datenflussorientierter, strukturorientierter Test

>

Das all defs-Kriterium verlangt eine Menge von Testpfaden, so dass für jeden Knoten ni und jede Variable x ∈ def (ni ) mindestens ein definitionsfreier Pfad bezüglich x von ni zu einem Element von dcu(x,ni ) oder dpu(x,ni ) enthalten ist. Das Kriterium verlangt, dass die Testfälle so beschaffen sind, dass zu jeder Definition (all defs) aller Variablen mindestens ein c-use oder ein p-use getestet wird. Das Beispielprogramm enthält in den Knoten nin und n2 Definitionen der Variablen Min und Max. Der Testpfad (nstart , nin , n1 , n2 , nout , n f inal ) testet das Programm im Sinne des all defs-Kriteriums hinreichend, da die Definitionen in Knoten nin durch die Verwendung im Prädikat der Kante (n1 , n2 ) und durch die Berechnung in Knoten n2 getestet werden und die Definitionen in Knoten n2 durch die Ausgabeanweisungen in Knoten nout abgedeckt sind. Die Kante (n1 , nout ) wird nicht ausgeführt. Das all defs-Kriterium subsumiert weder die Zweigüberdeckung noch die Anweisungsüberdeckung.

all defs-Kriterium

>

Das all p-uses-Kriterium ist erfüllt, falls für jeden Knoten ni und jede Variable x ∈ def (ni ) ein definitionsfreier Pfad bezüglich x von ni zu allen Elementen von dpu(x, ni ) in den getesteten Pfaden enthalten ist. Es muss jede Kombination jeder Variablendefinition mit jeder p-use, die diese Definition benutzt, getestet werden. Zur Erfüllung dieses Kriteriums müssen im Beispielprogramm die Pfade (nstart , nin , n1 , nout , n f inal ) und (nstart , nin , n1 , n2 , nout , n f inal ) durchlaufen werden, um die p-uses der Kanten (n1 ,n2 ) und (n1 ,nout ) zu testen. Das all p-uses-Kriterium enthält die Zweigüberdeckung.

all p-uses-Kriterium

>

Das all c-uses-Kriterium fordert die Ausführung mindestens eines definitionsfreien Pfades bezüglich x von ni zu jedem Element von dcu(x, ni ) für jeden Knoten ni und jede Variable x ∈ def(ni ). Das all c-uses-Kriterium subsumiert kein anderes Defs/Uses-Kriterium und enthält nicht die Zweigüberdeckung.

all c-uses-Kriterium

>

Eine Anzahl Testfälle erfüllt das all c-uses/some p-uses-Kriterium, falls für jeden Knoten ni und jede Variable x ∈ def (ni ) ein definitionsfreier Pfad bezüglich x von ni zu jedem Element von dcu(x, ni ) erzeugt wird oder, falls dcu(x,ni ) leer ist, mindestens ein definitionsfreier Pfad bezüglich x von ni zu einem Element von dpu(x,ni ) vorhanden ist. Alle berechnenden Variablenbenutzungen müssen bezüglich jeder Definition der Variable getestet werden. Existiert zu einer Definition kein berechnender Variablenzugriff, so muss sie in mindestens einem Pfadprädikat benutzt werden. Das Verfahren testet besonders gründlich berechnende Variablenzugriffe (c-uses). Das all c-uses/some p-uses-Kriterium fordert für den Test des Beispielprogramms die Pfade (nstart , nin , n1 , n2 , nout , n f inal ) und (nstart , nin , n1 , nout , n f inal ). Die Definitionen in Knoten nin und n2 machen den Test der berechnenden Zugriffe in Knoten n2 und nout notwendig. Da die Existenz von berechnenden Zugriffen zu einer Definition den Test von prädikativen Zugriffen unnötig werden lässt, die

all c-uses/some p-uses-Kriterium

4.2 Defs/Uses-Test

147

prädikativen Zugriffe jedoch mit den Zweigen identifiziert werden, enthält das Kriterium im allgemeinen Fall nicht den Zweigüberdeckungstest. Das all c-uses/some p-uses-Kriterium subsumiert das all defs-Kriterium. all c-uses/some p-uses-Kriterium

>

Zu dem all c-uses/some p-uses-Kriterium kann als spiegelbildliches Verfahren das all p-uses/some c-uses-Kriterium gebildet werden, das einen definitionsfreien Pfad von jeder Definition zu jedem prädikativen Zugriff fordert und, falls nicht vorhanden, einen entsprechenden Pfad zu einem berechnenden Zugriff vorsieht. Prädikative Variablenzugriffe werden durch diese Vorgehensweise besonders intensiv getestet. Das all p-uses/some c-uses-Kriterium subsumiert das all p-uses-Kriterium und das all defs-Kriterium, sowie den Zweigüberdeckungstest. Das Beispielprogramm ist durch Ausführung der Pfade (nstart , nin , n1 , n2 , nout , n f inal ) und (nstart , nin , n1 , nout , n f inal ) hinreichend getestet. Die Definitionen in Knoten nin führen zum Test der prädikativen Zugriffe in den Zweigen (n1 ,n2 ) und (n1 ,nout ). Zu den Definitionen in Knoten n2 existiert kein prädikativer Zugriff. Aus diesem Grund wird der Test des berechnenden Zugriffs in Knoten nout notwendig.

all uses-Kriterium

>

Durch Kombination der zwei zuvor dargestellten Verfahren erhält man das all uses-Kriterium, das das all p-uses/some c-uses-Kriterium und das all c-uses/some p-uses-Kriterium subsumiert. Die Forderung besteht darin, für alle Definitionen alle prädikativen und alle berechnenden Variablenzugriffe, die von einer Definition erreicht werden, zu testen. Formal formuliert muss ein definitionsfreier Pfad bezüglich x von Knoten ni zu allen Elementen von dcu(x, ni ) und dpu(x, ni ), für jeden Knoten ni und jede Variable x ∈ def (ni ), enthalten sein.

>

Ein du-Pfad ist ein Pfad p=(ni ,..n j , nk ) mit einer globalen Definition von x in ni für den gilt:

all du-path-Kriterium

148

–

p ist definitionsfrei bezüglich x, und nk enthält eine berechnende Benutzung von x, und alle Knoten ni . . . nk sind verschieden oder alle Knoten ni . . . n j sind verschieden und ni =nk oder

–

p’=(ni ,. . . n j ) ist definitionsfrei bezüglich x, und (n j ,nk ) enthält eine prädikative Benutzung von x, und alle Knoten ni ...n j sind verschieden.

Erweitert man die Forderung des all uses-Kriteriums derart, dass alle du-Pfade bezüglich aller Definitionen aller Variablen getestet werden müssen, so erhält man das all du-paths-Kriterium. Die Beschränkung auf du-Pfade nach der angegebenen Definition dient, analog zum boundary interior-Pfadtest und zum strukturierten Pfadtest, zur Begrenzung der

4 Datenflussorientierter, strukturorientierter Test

Testpfadanzahl. Es ist zu beachten, dass vollständige Testpfade im Unterschied zu den du-Pfaden mehrere Schleifendurchläufe enthalten können /Bieman, Schultz 89/. Die Hierarchie und Subsumptionsrelationen der Defs/Uses-Kriterien und weiterer Testverfahren sind in Abb. 4.3 dargestellt.

Für die Operation ZaehleZchn nach Abb. 4.1 gilt: Knoten nin n1 n2 n3 n4 n5 n6 nout

def {Gesamtzahl,VokalAnzahl} {Zchn} {} {Gesamtzahl} {} {VokalAnzahl} {Zchn} {}

Kanten (n2 , n3 ) (n2 , nout ) (n4 , n5 ) (n4 , n6 )

p-use {Zchn,Gesamtzahl} {Zchn,Gesamtzahl} {Zchn} {Zchn}

BEISPIEL

c-use {} {} {} {Gesamtzahl} {} {VokalAnzahl} {} {Gesamtzahl,VokalAnzahl}

Die Mengen der Kanten mit prädikativen Zugriffen auf eine Variable x, die von einer Definition der Variable x in einem Knoten ni erreicht werden, sind für die Operation ZaehleZchn nach Abb. 4.1 in Tab. 4.1 dargestellt. Tab. 4.2 stellt die Mengen der von einer Definition der Variable x in Knoten ni erreichten Knoten mit berechnendem Zugriff auf x dar. Im Folgenden werden für die unterschiedlichen Defs/Uses-Kriterien Testpfade bezogen auf die Operation ZaehleZchn angegeben. In den Abbildungen sind die Definitionen und Benutzungen der Variablen den Knoten der Pfade zugeordnet. Aus Gründen der Übersichtlichkeit werden sie nur dann aufgeführt, falls sie für den Test relevant sind. Die gebildeten Definitions-Benutzungs-Paare werden durch einen Pfeil von der Definition zur Benutzung gekennzeichnet, der für c-uses durchgezogen und für p-uses unterbrochen dargestellt ist. Knoten mit berechnender Variablenbenutzung und Kanten mit prädikativer Variablenbenutzung sind fett hervorgehoben. Das all defs-Kriterium fordert für die Operation ZaehleZchn Testpfade, die mindestens einen definitionsfreien Teilpfad von jeder der sechs Variablendefinitionen zu einer Benutzung der Variable enthalten. Abb. 4.4 gibt einen Testpfad an, der diese Forderung erfüllt. Testpfad: nstart , nin , n1 , n2 , n3 , n4 , n5 , n6 , n2 , nout , n f inal Testfall:

4.2 Defs/Uses-Test

149

Pfadüberdeckung all paths

DatenkontextÜberdeckung geordnet

all du-paths

DatenkontextÜberdeckung einfach

all uses

all c-uses/ some p-uses

all p-uses/ some c-uses

all c-uses

all defs

Required k-Tupels-Test

all p-uses

Zweigüberdeckung all edges

Anweisungsüberdeckung all nodes

Abbildung 4.3 Subsumptionsrelationen der datenflussorientierten Tests

Aufruf von ZaehleZchn mit: Gesamtzahl = 0 Eingelesene Zeichen: Zchn = ’A’, ’1’ Der Testpfad enthält die Kante (n4 , n6 ) nicht. Das all defs-Kriterium subsumiert daher offensichtlich nicht die Zweigüberdeckung. Das all p-uses-Kriterium verlangt Testpfade, die Subpfade von jeder Definition zu allen erreichten Kanten mit prädikativer Benutzung enthalten. Die Abb. 4.5 und 4.6 zeigen drei Testpfade, die diese Forderung erfüllen. Testpfade: 1. nstart , nin , n1 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n6 , n2 , nout , n f inal 2. nstart , nin , n1 , n2 , nout , n f inal 3. nstart , nin , n1 , n2 , n3 , n4 , n6 , n2 , nout , n f inal

Testfälle: Aufruf von ZaehleZchn mit Gesamtzahl = 0 1. Eingelesene Zeichen: Zchn = ’A’, ’E’, ’B’, ’1’ 2. Eingelesene Zeichen: Zchn = ’a’ 3. Eingelesene Zeichen: Zchn = ’C’, ’2’

150

4 Datenflussorientierter, strukturorientierter Test

Variable x

Zchn

Gesamtzahl

VokalAnzahl

nin

-

{(n2, n3), (n2, nout)}

{}

n1

{(n2, n3), (n2, nout), (n4, n5), (n4, n6)}

-

-

n2

-

-

-

n3

-

{(n2, n3), (n2, nout)}

-

n4

-

-

-

n5 n6

{(n2, n3), (n2, nout), (n4, n5), (n4, n6)}

-

{} -

nout

-

-

-

Zchn

Gesamtzahl

VokalAnzahl

nin

-

{n3, nout}

{n5, nout}

n1

{}

-

-

n2

-

-

-

n3

-

{n3, nout}

-

n4

-

-

-

n5

-

-

{n5, nout}

n6

{}

-

-

nout

-

-

-

Knoten i

Tabelle 4.1 dpu(x,i) der Operation ZaehleZchn

Variable x

Knoten i

Tabelle 4.2 dcu(x,i) der Operation ZaehleZchn

Ein vollständiger Test entsprechend des all p-uses-Kriteriums garantiert eine vollständige Zweigüberdeckung. Der all p-uses-Test subsumiert jedoch nicht das all defs-Kriterium, da nicht notwendig zu allen Definitionen eine prädikative Benutzung existiert. Die Beispieloperation ZaehleZchn enthält zu der Variable VokalAnzahl ausschließlich berechnende Zugriffe, so dass für den Test der Definitionen von VokalAnzahl nach dem

4.2 Defs/Uses-Test

151

Beispiel für das all defs-Kriterium

Abbildung 4.4 ZaehleZchn: all defs-Kriterium

all p-uses-Kriterium keine Forderungen existieren. Daher existieren im allgemeinen Testfälle die das all p-uses-Kriterium erfüllen, aber keinen vollständigen all defs-Test bewirken /Rapps, Weyuker 85/. Das all p-uses/some c-uses-Kriterium kann im Beispiel mit den gleichen Testpfaden erfüllt werden, wie das all p-uses-Kriterium. Im Unterschied zum all p-uses-Test müssen zu den Definitionen von VokalAnzahl zwingend berechnende Benutzungen (c-uses) getestet werden (Abb. 4.7 und 4.8). Das all c-uses/some p-uses-Kriterium fordert die prädikative Benutzung von Zchn, da keine berechnenden Benutzungen der Variable Zchn existieren. Abb. 4.9 stellt die Testpfade nach dem all c-uses/some p-uses-Kriterium dar. Testpfade: 1. nstart , nin , n1 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n5 , n6 , n2 , nout , n f inal 2. nstart , nin , n1 , n2 , nout , n f inal

152

4 Datenflussorientierter, strukturorientierter Test

nstart nin

def (Gesamtzahl)

n1

def (Zchn)

Beispiel für das all p-uses-Kriterium

n2 p-use (Zchn), p-use (Gesamtzahl) def (Gesamtzahl)

n3 n4

p-use (Zchn) n5 def (Zchn)

n6 n2

p-use (Zchn), p-use (Gesamtzahl) n3 n4 p-use (Zchn) n5 def (Zchn)

n6 n2

def (Gesamtzahl)

n3 n4

p-use (Zchn) def (Zchn)

n6 n2

p-use (Zchn), p-use (Gesamtzahl) nout nfinal Legende: prädikative Benutzung (p-use) ni p-use (...)

getestete prädikative Benutzung

nj

Abbildung 4.5 ZaehleZchn: all p-uses-Kriterium 4.2 Defs/Uses-Test

153

nstart

Beispiel für das all p-uses-Kriterium (Fortsetzung)

nin

def (Gesamtzahl)

n1

def (Zchn)

n2 p-use (Zchn), p-use (Gesamtzahl) nout nfinal

nstart nin n1

def (Zchn)

n2 n3 n4 p-use (Zchn) n6 n2 Legende:

nout nfinal

prädikative Benutzung (p-use) ni p-use (...)

getestete prädikative Benutzung

nj

Abbildung 4.6 ZaehleZchn: all p-uses-Kriterium (Fortsetzung)

Testfälle: Aufruf von ZaehleZchn mit: Gesamtzahl = 0 1. Eingelesene Zeichen: Zchn = ’A’, ’E’, ’1’ 2. Eingelesene Zeichen: Zchn = ’a’

Die Testpfade enthalten nicht die Kante (n4 , n6 ). Das all c-uses/some p-uses-Kriterium subsumiert den Zweigüberdeckungstest im Allgemeinen nicht.

154

4 Datenflussorientierter, strukturorientierter Test

Das all uses-Kriterium kann mit den Testpfaden nach Abb. 4.10 und 4.11 erfüllt werden. Das all du-paths-Kriterium fordert folgende Testpfade und Testfälle: Testpfade: 1. nstart , nin , n1 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n6 , n2 , nout , n f inal 2. nstart , nin , n1 , n2 , nout , n f inal 3. nstart , nin , n1 , n2 , n3 , n4 , n6 , n2 , n3 , n4 , n5 , n6 , n2 , nout , n f inal

Testfälle: Aufruf von ZaehleZchn mit Gesamtzahl = 0 1. Eingelesene Zeichen: Zchn = ’A’, ’E’, ’B’, ’1’ 2. Eingelesene Zeichen: Zchn = ’a’ 3. Eingelesene Zeichen: Zchn = ’C’, ’I’, ’2’

Durch die Verzweigung im Schleifenrumpf der Operation ZaehleZchn entstehen innerhalb der Schleife zwei mögliche Teilpfade. Ein Teilpfad enthält den Knoten n5 . Der andere Teilpfad enthält n5 nicht. Die entstehenden du-Pfade verursachen einen mehrfachen Test einiger Definition-Benutzungs-Paare. In Abb. 4.12 und 4.13 sind die betroffenen Paare, die einen Teilpfad enthalten, der Knoten n5 enthält, mit 1, a, A und I gekennzeichnet. Die Subpfade, die Knoten n5 nicht enthalten, tragen die Markierungen 2, b, B, II. Die Paare 1 und 2, a und b, A und B und I und II enthalten jeweils gleiche Definition-Benutzungs-Kombinationen und unterscheiden sich lediglich durch die ausgeführten Teilpfade entsprechend des all du-paths-Kriteriums.

4.2 Defs/Uses-Test

155

nstart

Beispiel für das all p-uses/some c-uses-Kriterium

nin

def (Gesamtzahl), def (VokalAnzahl)

n1

def (Zchn)

n2 p-use (Zchn), p-use (Gesamtzahl) def (Gesamtzahl)

n3 n4 n5

p-use (Zchn) c-use (VokalAnzahl), def (VokalAnzahl)

n6

def (Zchn)

n2 p-use (Zchn), p-use (Gesamtzahl) n3 n4 n5

p-use (Zchn) c-use (VokalAnzahl)

n6

def (Zchn)

n2 def (Gesamtzahl)

n3 n4

p-use (Zchn) def (Zchn)

n6 n2

p-use (Zchn), p-use (Gesamtzahl) nout nfinal Legende: berechnende Benutzung (c-use) prädikative Benutzung (p-use)

ni p-use (...)

getestete prädikative Benutzung

c-use (...)

getestete berechnende Benutzung

nj ni

Abbildung 4.7 ZaehleZchn: all p-uses/some c-uses-Kriterium 156

4 Datenflussorientierter, strukturorientierter Test

nstart nin

def (Gesamtzahl)

n1

def (Zchn)

Beispiel für das all p-uses/some c-usesKriterium (Fortsetzung)

n2 p-use (Zchn), p-use (Gesamtzahl) nout nfinal

nstart nin def (Zchn)

n1 n2 n3 n4

p-use (Zchn) n6 n2 nout nfinal Legende: berechnende Benutzung (c-use) prädikative Benutzung (p-use)

ni p-use (...)

Getestete prädikative Benutzung

c-use (...)

getestete berechnende Benutzung

nj ni

Abbildung 4.8 ZaehleZchn: all p-uses/some c-uses-Kriterium (Fortsetzung)

4.2 Defs/Uses-Test

157

Beispiel für das all c-uses/some p-uses-Kriterium

Abbildung 4.9 ZaehleZchn: all c-uses/some p-uses-Kriterium

158

4 Datenflussorientierter, strukturorientierter Test

Beispiel für das all uses-Kriterium

Abbildung 4.10 ZaehleZchn: all uses-Kriterium

4.2 Defs/Uses-Test

159

Beispiel für das all uses-Kriterium (Fortsetzung)

Abbildung 4.11 ZaehleZchn: all uses-Kriterium (Fortsetzung)

160

4 Datenflussorientierter, strukturorientierter Test

Beispiel für das all du-paths-Kriterium

Abbildung 4.12 ZaehleZchn: all du-paths-Kriterium

4.2 Defs/Uses-Test

161

nstart

Beispiel für das all du-paths-Kriterium (Fortsetzung)

nin

def (Gesamtzahl), def (VokalAnzahl)

n1

def (Zchn)

n2 nout

p-use (Zchn), p-use (Gesamtzahl) c-use (Gesamtzahl), c-use (VokalAnzahl)

nfinal

Legende: berechnende Benutzung (c-use) prädikative Benutzung (p-use)

ni p-use (...)

getestete prädikative Benutzung

c-use (...)

getestete berechnende Benutzung

nj

nstart

ni

nin n1

def (Zchn)

n2 def (Gesamtzahl) n3 b

2

n4 p-use (Zchn) n6 n2 n3

p-use (Gesamtzahl) c-use (Gesamtzahl), def (Gesamtzahl)

n4 n5

A

I

n6 n2 nout

p-use (Gesamtzahl) c-use (Gesamtzahl)

nfinal

Abbildung 4.13 ZaehleZchn: all du-paths-Kriterium (Fortsetzung)

162

4 Datenflussorientierter, strukturorientierter Test

4.3

Required k-Tuples Test

Der Required k-Tuples Test ist eine Teilmenge des Required Elements Tests /Ntafos 81, Ntafos 84, Ntafos 88/, /Clarke et al. 85/, der genaugenommen keinen Test im eigentlichen Sinne darstellt, sondern einen Formalismus zur Beschreibung von Testverfahren bildet, mit dem sich alle strukturorientierten Testtechniken beschreiben lassen. Geforderte Elemente (Required Elements) haben die Form {S;F}. S ist die strukturelle Komponente, die festlegt, welche Strukturelemente (Zweige, Anweisungen, etc.) getestet werden sollen. F ist die funktionale Komponente. Sie beschreibt die Bedingungen, welche die Testfälle für S erfüllen müssen.

Required Elements

Das Required k-Tuples Kriterium beschreibt eine Klasse von datenflussorientierten Testverfahren, die durch Variieren der Konstanten k – mit k ≥ 2 – entstehen. Der Required k+1-Tuples Test enthält den Required k-Tuples Test. In der hier dargestellten Form subsumiert der Required k-Tuples Test den all defs-Test und den Zweigüberdeckungstest.

Der Parameter k gibt die „Länge“ der so genannten k-dr-Interaktion an.

Der Required k-Tuples Test unterscheidet ebenso wie die Defs/Uses-Kriterien Variablenzugriffe nach definierendem (d) Zugriff und referenzierendem (r) Zugriff. Referenzierende Zugriffe können prädikativ (p-use) oder berechnend (c-use) sein. Im Rahmen des Required k-Tuples Tests werden auch die prädikativen Variablenreferenzen den Knoten des Kontrollflussgraphen zugeordnet.

Definierender Zugriff (d) Referenzierender Zugriff (r)

Die Basis des Verfahrens ist die Version des Kontrollflussgraphen, der lineare Anweisungssequenzen (Segmente) zu jeweils einem Knoten zusammenfasst. Der Required k-Tuples Test verlangt jedoch eine geringfügige Modifikation. Falls innerhalb einer Anweisungssequenz – eines Segments – eine Datenflussinteraktion der Form Definition – Referenz – eine so genannte dr-Interaktion – enthalten ist, so wird das Segment an dieser Stelle aufgetrennt. Die zwei entstehenden Teilsegmente enthalten diese dr-Interaktion nicht mehr. Im Kontrollflussgraph wird der entsprechende Knoten durch zwei durch eine Kante verbundene Knoten ersetzt. Außerdem werden im Unterschied zur üblichen Datenflussform des Kontrollflussgraphen dem Knoten nin Definitionen aller Variablen zugeordnet. Entsprechend werden dem Knoten nout Referenzen aller Variablen zugeordnet. Beide Knoten sind nicht nur dann vorhanden, falls Information importiert oder exportiert wird, sondern sind in jedem Fall Bestandteil des Kontrollflussgraphen. Eine k-dr-Interaktion [(d1 (x1 ), u2 (x1 ),. . . , dk−1 (xk−1 ), uk (xk−1 )] ist eine alternierende Sequenz aus k-1 Variablendefinitionen und k-1 Variablenreferenzen in k unterschiedlichen Knoten des Kontrollflussgraphen. Die Referenz der Variable xi wird von der in der k-dr-Interaktion vorangehenden Definition erreicht. Die Variable wird nicht erneut definiert und auch nicht undefiniert (z. B. durch ungültig werden von lokalen Variablen bei

4.3 Required k-Tuples Test

163

Verlassen einer Prozedur). Diese alternierende Sequenz von Variablendefinitionen und Variablenreferenz entspricht einem Teilpfad, der als Interaktionen-Subpfad bezüglich der betrachteten k-dr-Interaktion bezeichnet wird. Testvollständigkeit nach dem Required k-Tuples Kriterium

Ein Satz von Pfaden P bzw. ein Satz von entsprechenden Testfällen erfüllt das Required k-Tuples Kriterium bezüglich eines Kontrollflussgraphen und damit der zugehörigen Software, falls für jede l-dr-Interaktion im Kontrollflussgraphen, mit 2 ≤ l ≤ k, gilt: >

Für alle unmittelbaren Nachfolgeknoten m des Knotens ni in dem die letzte Referenz der l-dr-Interaktion enthalten ist, enthält P einen Subpfad p·(m), für den p Interaktionen-Subpfad bezüglich der l-dr-Interaktion ist. Diese Forderung stellt die Zweigüberdeckung sicher.

>

Falls die erste Definition oder die letzte Referenz einer l-dr-Interaktion in einer innersten Schleife auftritt, so muss P Subpfade enthalten, die sowohl die l-dr-Interaktion abdecken, als auch eine minimale Anzahl Schleifenausführungen, sowie eine größere Anzahl Schleifenausführungen bewirken. Diese Forderung stellt in Analogie zum boundary interior-Pfadtest bzw. zum strukturierten Pfadtest eine gewisse Testaktivität für Schleifen sicher. Ein cl(complete loop)-Subpfad bezüglich einer Schleife ist ein Subpfad (m)·p·(n), mit einem nichtleeren Subpfad p, der vollständig innerhalb der Schleife liegt und den Knoten n und m, die außerhalb der Schleife liegen. –

–

Falls der Knoten ni , dem die erste Definition der l-dr-Interaktion zugeordnet ist, Bestandteil einer Schleife ist, so müssen Subpfade p=p1 ·(ni )·p2 ·p3 und p’=p1 ’·(ni )·p2 ’·p3 ’ getestet werden, so dass (ni ).·p2 ·p3 und (ni )·p2 ’·p3 ’ mit InteraktionenSubpfaden bezüglich der l-dr-Interaktion beginnen. p1 ·(ni )·p2 muss ein cl-Subpfad der Schleife sein, die ni unmittelbar enthält und eine minimale Anzahl Schleifendurchläufe umfasst. p1 ’·(ni )·p2 ’ muss ebenfalls ein cl-Subpfad der Schleife sein und mindestens einen weiteren zusätzlichen Schleifendurchlauf enthalten. Falls der Knoten ni , dem die letzte Referenz der l-dr-Interaktion zugeordnet ist, Bestandteil einer Schleife ist, so müssen Subpfade p=p1 ·p2 ·(ni )·p3 und p’=p1 ’·p2 ’·(ni )·p3 ’ getestet werden, so dass p1 ·p2 ·(ni ) und p1 ’·p2 ’·(ni ) mit Interaktionen-Subpfaden bezüglich der l-dr-Interaktion enden. p2 ·(ni )·p3 muss ein cl-Subpfad der Schleife sein, die ni unmittelbar enthält und eine minimale Anzahl Schleifendurchläufe umfasst. p2 ’·(ni )·p3 ’ muss ebenfalls ein cl-Subpfad der Schleife sein und mindestens einen weiteren zusätzlichen Schleifendurchlauf enthalten.

Die Beachtung aller l-dr-Interaktionen für 2 ≤ l ≤ k ist eine Erweiterung des ursprünglichen Verfahrens, das nur k-dr-Interaktionen berücksichtigt hat /Clarke et al. 85/. Da für jedes Programm ein festes n existiert, so

164

4 Datenflussorientierter, strukturorientierter Test

dass keine k-dr-Interaktionen mit k>n existieren, stellt die vorgenommene Erweiterung die Subsumption des Required k-Tuples Kriteriums durch das Required k+1-Tuples Kriterium sicher. Dies gilt für die ursprüngliche Definition nicht. Die hier verwendete Definition der k-dr-Interaktion entspricht der ursprünglichen Definition nach /Ntafos 84/. Sie verlangt, dass die k Knoten der k-dr-Interaktion unterschiedlich sind. Als Konsequenz dieser Beschränkung subsumiert der Required k-Tuples Test aus der Gruppe der Defs/Uses-Kriterien ausschließlich den all p-uses-Test. In der Definition der k-dr-Interaktion nach /Clarke et al. 86/ können der erste und der letzte Knoten identisch sein. /Ntafos 88/ verzichtet vollständig auf die Forderung nach Unterschiedlichkeit der an der k-dr-Interaktion beteiligten Knoten. Durch diese Erweiterungen subsumiert diese Form des Required k-Tuples Tests das all uses-Kriterium aus der Gruppe der Defs/Uses-Tests.

Um den direkten Vergleich der Testpfade mit den Testpfaden anderer Testtechniken zu erleichtern, wird – entgegen der o. a. Vorgehensweise – für die Operation ZaehleZchn im Rahmen des Required k-Tuples Tests der Kontrollflussgraph auf Anweisungsebene (Abb. 4.1) verwendet.

BEISPIEL

Für die Operation ZaehleZchn können folgende Zweitupel gebildet werden (d= Definition, r = Referenz): 1. [d1 (Zchn),r2 (Zchn)] 2. [d1 (Zchn),r4 (Zchn)] 3. [d6 (Zchn),r2 (Zchn)] 4. [d6 (Zchn),r4 (Zchn)] 5. [d1 (Zchn),rout (Zchn)] 6. [d6 (Zchn),rout (Zchn)] 7. [din (Gesamtzahl),r2 (Gesamtzahl)] 8. [din (Gesamtzahl),r3 (Gesamtzahl)] 9. [din (Gesamtzahl),rout (Gesamtzahl)] 10. [d3 (Gesamtzahl),r2 (Gesamtzahl)] 11. [d3 (Gesamtzahl),rout (Gesamtzahl)] 12. [din (VokalAnzahl),r5 (VokalAnzahl)] 13. [din (VokalAnzahl),rout (VokalAnzahl)] 14. [d5 (VokalAnzahl),rout (VokalAnzahl)] Folgende 3-Tuple können gebildet werden: 15. [din (VokalAnzahl),r5 (VokalAnzahl),d5 (VokalAnzahl), rout (VokalAnzahl)] 16. [din (Gesamtzahl),r3 (Gesamtzahl),d3 (Gesamtzahl), rout (Gesamtzahl)]

4.3 Required k-Tuples Test

165

17. [din (Gesamtzahl),r3 (Gesamtzahl),d3 (Gesamtzahl), r2 (Gesamtzahl)] Entsprechend des Required 2-Tuples Kriteriums werden für die 2-dr-Interaktionen folgende Subpfade erzeugt: 1a. n1 ,n2 ,n3 1b. n1 ,n2 ,nout 2a. n1 ,n2 ,n3 ,n4 ,n5 2b. n1 ,n2 ,n3 ,n4 ,n6 3a. n6 ,n2 ,n3 3b. n6 ,n2 ,nout 4a. n6 ,n2 ,n3 ,n4 ,n5 4b. n6 ,n2 ,n3 ,n4 ,n6 5. n1 , n2 ,nout ,n f inal 6. n6 ,n2 ,nout ,n f inal 7a. nin , n1 ,n2 ,n3 7b. nin , n1 ,n2 ,nout 8. nin , n1 ,n2 ,n3 ,n4 9. nin , n1 ,n2 ,nout ,n f inal 10a. n3 ,n4 ,(n5 ,) n6 ,n2 ,n3 10b. n3 ,n4 ,(n5 ,) n6 ,n2 ,nout 11. n3 ,n4 ,(n5 ,) n6 ,n2 ,nout ,n f inal 12. nin , n1 ,n2 , n3 ,n4 ,n5 ,n6 13. nin , n1 ,n2 ,n n3 ,n4 ,n f inal 14. n5 , n6 ,n2 ,nout ,n f inal Da einige der 2-dr-Interaktionen erste Definitionen und/oder letzte Referenzen innerhalb der Schleife besitzen, sind für diese Interaktionen Subpfade mit minimaler Anzahl und größerer Anzahl von Schleifendurchläufen zu bilden. So besitzt die 2-dr-Interaktion [d6 (Zchn),r4 (Zchn)] die erste Definition von Zchn in Knoten 6. Dies fordert den Test der Subpfade 1. n1 ,n2 ,n3 ,n4 ,(n5 ,)n6 ,n2 ,n3 ,n4 ,(n5 ,)n6 ,n2 ,nout und 2. n2 ,n3 ,n4 ,(n5 ,)n6 ,n2 ,n3 ,n4 ,(n5 ,)n6 ,n2 ,n3 . Der Testpfad 1 bewirkt die minimal mögliche Anzahl Schleifendurchläufe für den Test der 2-dr-Interaktion [d6 (Zchn),r4 (Zchn)]. Der Testpfad 2 enthält mindestens einen weiteren Schleifendurchlauf und bewirkt damit die Ausführung einer größeren Anzahl von Schleifendurchläufen. Zusätzlich tritt die letzte Referenz der 2-dr-Interaktion in der Schleife auf. Dies fordert ebenfalls die Ausführung der bereits dargestellten Subpfade.

166

4 Datenflussorientierter, strukturorientierter Test

Zur Abdeckung aller Subpfade für die 2-dr-Interaktionen und zur Erfüllung der Kriterien für den Test von Schleifen sind folgende Testpfade notwendig: 1. nstart , nin , n1 ,n2 ,n3 ,n4 , n5 , n6 , n2 , nout , n f inal 2. nstart , nin , n1 ,n2 ,n3 ,n4 , n6 , n2 , n3 ,n4 , n5 , n6 , n2 , nout , n f inal 3. nstart , nin , n1 ,n2 ,n3 ,n4 , n5 , n6 , n2 , n3 ,n4 , n6 , n2 , n3 ,n4 , n6 , n2 , nout , n f inal 4. nstart , nin , n1 ,n2 , nout , n f inal Die Testpfade können mit folgenden Testfällen ausgeführt werden: Aufruf von ZaehleZchn mit: Gesamtzahl = 0 1. Eingelesene Zeichen: Zchn = ’A’, ’1’ 2. Eingelesene Zeichen: Zchn = ’B’, ’A’, ’1’ 3. Eingelesene Zeichen: Zchn = ’A’, ’B’, ’C’, ’2’ 4. Eingelesene Zeichen: Zchn = ’a’ Die Testpfade sind mit den Subpfaden für die 2-dr-Interaktionen in Abb. 4.14 bis 4.17 dargestellt. Für die Interaktion [d6 (Zchn),r4 (Zchn)] sind zwei Subpfade mit minimaler und größerer Anzahl Schleifendurchläufe hervorgehoben. Aus Gründen der Übersichtlichkeit ist für die übrigen Interaktionen darauf verzichtet worden.

4.3 Required k-Tuples Test

167

nstart nin n1 7b n2

1b

9,13

nout

5

nfinal Abbildung 4.14 Required k-Tuples Test

nstart nin n1 7a n2

8

1a

n3

12

2a

n4 n5 10b n6 n2

11 3b

14 6

nout nfinal Abbildung 4.15 Required k-Tuples Test

168

4 Datenflussorientierter, strukturorientierter Test

nstart nin n1 n2 n3

2b

n4 n6 n2 n3

10a 3a 4a

n4 n5 n6 n2 nout

d6(Zchn), r4(Zchn) erste Definition in Schleife letzte Referenz in Schleife minimale Anzahl Schleifendurchläufe

nfinal Abbildung 4.16 Required k-Tuples Test

4.3 Required k-Tuples Test

169

nstart nin n1 n2 n3 n4 n5 n6 n2 n3

4b

n4 n6 n2 n3 n4

d6(Zchn), r4(Zchn) erste Definition in Schleife letzte Referenz in Schleife Anzahl Schleifendurchläufe nicht minimal

n6 n2 nout nfinal Abbildung 4.17 Required k-Tuples Test

170

4 Datenflussorientierter, strukturorientierter Test

4.4

Datenkontext-Überdeckung

Es existieren zwei unterschiedliche Techniken der Datenkontext-Überdeckung (context coverage). Eine Technik basiert auf Kontrollflussgraphen, die jede einzelne Anweisung als Knoten darstellen. Die andere Technik verwendet Kontrollflussgraphen, die Segmente zu einzelnen Knoten komprimieren /Laski, Korel 83/, /Laski 82/, /Clarke et al. 85, Clarke et al. 86/. Die Datenkontext-Überdeckung (Context Coverage) subsumiert das all defs-Kriterium. Sie subsumiert den Zweigüberdeckungstest nicht. Um dieses Problem abzustellen, sind entsprechende Erweiterungen vorgeschlagen worden /Clarke et al. 86/. Basierend auf der Kontrollflussgraphdarstellung kann der Begriff Datenkontext oder Definitionenkontext definiert werden. Für einen Knoten n des Kontrollflussgraphen, in dem die Variablen x1 , x2 ,. . . , xk referenziert werden – d. h. x1 , x2 ,. . . , xk ⊆ USED(n), wird der Begriff elementarer Datenkontext folgendermaßen definiert: Ein elementarer Datenkontext bezüglich Knoten n ist eine Menge von Definitionen ec(n) = { d1 (x1 ), d2 (x2 ), ... , dk (xk ) } mit der Eigenschaft:

Elementarer Datenkontext

Es existieren Subpfade p·(n) – so genannte Kontext-Subpfade für ec(n)– für die gilt: >

Für alle i, mit 1 ≤ i ≤ k, ist p = pi ·(ni )·qi

>

di (xi ) steht in Knoten ni

>

qi ist definitionsfrei bezüglich xi .

Ein elementarer Datenkontext eines Knotens ist eine Menge von Variablendefinitionen, die in dem Knoten referenziert werden und ihn erreichen, d. h. nicht vorher erneut definiert werden, unter der Voraussetzung, dass sie in genau einem Subpfad vorgenommen werden. Dieser Subpfad ist der Kontext-Subpfad. Die Menge aller elementaren Datenkontexte eines Knotens n bildet den Datenkontext DC(n) dieses Knotens. Synonym für Datenkontext wird auch der Begriff Definitionenkontext verwendet. Für einen Knoten n mit {x1 , x2 ,. . . , xk } ⊆ USED(n) wird der Begriff geordneter elementarer Datenkontext bezüglich Knoten n folgendermaßen definiert: Eine Sequenz oec(n) = {[ d1 (x1 ), d2 (x2 ),. . . , dk (xk ) ]} ist dann ein geordneter elementarer Datenkontext bezüglich Knoten n, falls Subpfade p·(n) – geordnete Kontext-Subpfade für oec(n) – existieren, für die gilt: >

Für alle i, mit 1 ≤ i ≤ k ist p = pi ·(ni )·qi .

>

di (xi ) steht in Knoten i.

>

Der Subpfad qi ist definitionsfrei bezüglich xi .

4.4 Datenkontext-Überdeckung

Geordneter elementarer Datenkontext

171

>

Testvollständigkeit der Datenkontext-Überdeckung

Für alle j, mit i ≤ j ≤ k, ist entweder ni = n j oder n j ist Knoten in qi .

Ein elementarer Datenkontext beschreibt eine Menge von Variablendefinitionen ohne die Definitionsreihenfolge zu berücksichtigen. Es kann folglich zu jedem elementaren Datenkontext mindestens ein geordneter elementarer Datenkontext angegeben werden. Sind mehrere Definitionsreihenfolgen zu einem elementaren Datenkontext möglich, so existiert eine entsprechende Anzahl geordneter elementarer Datenkontexte. Ein geordneter Datenkontext ODC(n) eines Knotens n ist die Menge aller geordneten elementaren Datenkontexte dieses Knotens. Auf dieser Basis werden die Testverfahren der Datenkontext-Überdeckung und der geordneten Datenkontext-Überdeckung definiert. Ein Satz von Pfaden P erfüllt das Datenkontext-Überdeckungs-Kriterium, falls P für alle Knoten n und für alle Datenkontexte DC(n) mindestens einen Kontext-Subpfad bezüglich DC(n) enthält. Entsprechend wird die geordnete Kontext-Überdeckung definiert:

Testvollständigkeit der geordneten Datenkontext-Überdeckung

Ein Satz von Pfaden P erfüllt das geordnete Datenkontext-Überdeckungs-Kriterium, falls P für alle Knoten n und für alle geordneten Datenkontexte ODC(n) mindestens einen geordneten Kontext-Subpfad bezüglich ODC(n) enthält. Die einfache Datenkontext-Überdeckung verlangt, dass alle existierenden Möglichkeiten den Programmvariablen Werte zuzuweisen, mindestens einmal geprüft werden. Kann der Wert, den eine Variable an einer bestimmten Stelle des Programms besitzt, an unterschiedlichen Stellen zugewiesen worden sein, so müssen alle diese unterschiedlichen Wertzuweisungen getestet werden. Die Reihenfolge der Wertzuweisungen bleibt unberücksichtigt. Die geordnete Datenkontext-Überdeckung verlangt zusätzlich zur Prüfung aller Möglichkeiten der Wertzuweisung die Beachtung der Zuweisungsreihenfolge. Verwendet man Kontrollflussgraphen, die Segmente zu einem einzelnen Knoten komprimieren (Abb. 8.2), so kann ein Segment als komplexe Anweisung betrachtet werden. Eine Variable ist Eingangsvariable eines Segments, wenn sie referenziert wird, ohne vorher in dem betrachteten Segment definiert worden zu sein. Alle innerhalb des Segments definierten Variablen sind Ausgangsvariablen. Ein Segment, das nur aus einer einzelnen Entscheidung besteht, besitzt nur Eingangsvariablen. Eingangs- und Ausgangsvariablen stellen die Analogie zu Variablenreferenz und Variablendefinition auf der Anweisungsebene dar. Sie dienen zur Festlegung analoger Datenkontexte und geordneter Datenkontexte, die durch die entsprechenden Testverfahren in gleicher Weise behandelt werden, wie die Datenkontexte des Kontrollflussgraphen auf Anweisungsebene. Die geordnete Datenkontext-Überdeckung subsumiert die Datenkontext-Überdeckung. Keines der beschriebenen Verfahren stellt jedoch den

172

4 Datenflussorientierter, strukturorientierter Test

Anweisungsüberdeckungstest und daher auch nicht den Zweigüberdeckungstest sicher. Der Grund für diese störende Eigenschaft ist die mögliche Existenz von Anweisungen, die keine Variablenreferenzen enthalten, und zu denen folglich auch kein Datenkontext vorhanden ist. Daher werden solche Anweisungen nicht notwendigerweise getestet. Ferner verlangt die angegebene Definition nicht, dass an Verzweigungsstellen beide Verzweigungsrichtungen durchlaufen werden. Eine Erweiterung der Verfahren verlangt aus diesem Grund zusätzlich die Überdeckung aller Knoten, die Nachfolger eines Knotens mit prädikativer Variablenreferenz sind /Clarke et al. 86/. Dies führt zur Zweigüberdeckung und damit auch zur Anweisungsüberdeckung. Die erweiterte Form der Datenkontext-Überdeckung subsumiert darüber hinaus das all uses-Kriterium aus der Gruppe der Defs/Uses-Tests.

Für die Operation ZaehleZchn können die folgenden elementaren Datenkontexte gebildet werden (d = Definition): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

Erweiterte Datenkontext-Überdeckung

BEISPIEL

ec1 (n2 ) = (d1 (Zchn),din (Gesamtzahl)) ec2 (n2 ) = (d6 (Zchn),d3 (Gesamtzahl)) ec1 (n3 ) = (din (Gesamtzahl)) ec2 (n3 ) = (d3 (Gesamtzahl)) ec1 (n4 ) = (d1 (Zchn)) ec2 (n4 ) = (d6 (Zchn)) ec1 (n5 ) = (din (VokalAnzahl)) ec2 (n5 ) = (d5 (VokalAnzahl)) ec1 (nout ) = (din (VokalAnzahl), din (Gesamtzahl)) ec2 (nout ) = (din (VokalAnzahl), d3 (Gesamtzahl)) ec3 (nout ) = (d5 (VokalAnzahl), d3 (Gesamtzahl))

Es existieren folgende Datenkontexte: 1. 2. 3. 4. 5.

DC (n2 ) = { ec1 (n2 ), ec2 (n2 ) } DC (n3 ) = { ec1 (n3 ), ec2 (n3 ) } DC (n4 ) = { ec1 (n4 ), ec2 (n4 ) } DC (n5 ) = { ec1 (n5 ), ec2 (n5 ) } DC (nout ) = { ec1 (nout ), ec2 (nout ), ec3 (nout ) }

Ein vollständiger Datenkontext-Überdeckungstest fordert die Ausführung folgender Testpfade: 1. nstart , nin , n1 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n5 , n6 , n2 , nout , n f inal 2. nstart , nin , n1 , n2 , n3 , n4 , n6 , n2 , nout , n f inal 3. nstart , nin , n1 , n2 , nout , n f inal Die Testpfade können mit folgenden Testfällen ausgeführt werden: Aufruf von ZaehleZchn mit: Gesamtzahl = 0

4.4 Datenkontext-Überdeckung

173

1. Eingelesene Zeichen: Zchn = ’A’, ’E’, ’1’ 2. Eingelesene Zeichen: Zchn = ’B’, ’1’ 3. Eingelesene Zeichen: Zchn = ’a’

In Abb. 4.18 und 4.19 sind die Testpfade zur Überdeckung der elementaren Datenkontexte dargestellt.

Abbildung 4.18 Datenkontext-Überdeckung

174

4 Datenflussorientierter, strukturorientierter Test

Abbildung 4.19 Datenkontext-Überdeckung

Für die Operation ZaehleZchn können die folgenden geordneten Datenkontexte gebildet werden: 1. ODC (n2 ) = { [din (Gesamtzahl),d1 (Zchn)],[d3 (Gesamtzahl), d6 (Zchn)] } 2. ODC (n3 ) = { [din (Gesamtzahl)], [d3 (Gesamtzahl)] } 3. ODC (n4 ) = { [din (Zchn)], [d6 (Zchn)] } 4. ODC (n5 ) = { [din (VokalAnzahl)], [d5 (VokalAnzahl)] } 5. ODC (nout ) = { [din (VokalAnzahl), din (Gesamtzahl)], [din (VokalAnzahl), d3 (Gesamtzahl)], [d3 (Gesamtzahl), d5 (VokalAnzahl)], [d5 (VokalAnzahl), d3 (Gesamtzahl)] } Zu den elementaren Datenkontexten der Knoten n2 , n3 , n4und n5 existiert jeweils genau ein geordneter elementarer Datenkontext. Die Reihenfolge der Definitionen ist in diesen Fällen fest. Zu den elementaren Datenkontexten des Knotens nout existieren in einem Fall zwei geordnete elementare Datenkontexte. Der elementare Datenkontext ec3 (nout ) = (d5 (VokalAnzahl),d3 (Gesamtzahl)) erzeugt die zwei geordneten elementaren Datenkontexte [d5 (VokalAnzahl),d3 (Gesamtzahl)] und [d3 (Gesamtzahl),d5 (VokalAnzahl)]. Die Überdeckung aller geordneten Datenkontexte fordert gegenüber der einfachen Datenkontext-Überdeckung einen zusätzlichen Testfall (Abb. 4.20). Folgende Testpfade sind notwendig: 1. nstart , nin , n1 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n5 , n6 , n2 , nout , n f inal

4.4 Datenkontext-Überdeckung

175

2. nstart , nin , n1 , n2 , n3 , n4 , n6 , n2 , nout , n f inal 3. nstart , nin , n1 , n2 , nout , n f inal 4. nstart , nin , n1 , n2 , n3 , n4 , n5 , n6 , n2 , n3 , n4 , n6 , n2 , nout , n f inal

nstart nin n1 n2 n3 n4 n5 n6 n2 n3 n4 n6 n2 nout nfinal Abbildung 4.20 Überdeckung geordneter Datenkontexte

Die Testpfade können mit folgenden Testfällen ausgeführt werden: Aufruf von ZaehleZchn mit: Gesamtzahl = 0 1. Eingelesene Zeichen: Zchn = ’A’, ’E’, ’1’ 2. Eingelesene Zeichen: Zchn = ’B’, ’1’ 3. Eingelesene Zeichen: Zchn = ’a’ 4. Eingelesene Zeichen: Zchn = ’A’, ’C’, ’3’

176

4 Datenflussorientierter, strukturorientierter Test

4.5

Bewertung des datenflussorientierten Tests

Die datenflussorientierten Testtechniken sind fast ausnahmslos später publiziert worden als die kontrollflussorientierten Testtechniken. Es ist zu erwarten, dass sie „moderner“ als die kontrollflussorientierten Techniken sind. Dennoch ist ihre Bedeutung für die Praxis sehr viel geringer als die der kontrollflussorientierten Testtechniken. Dies ist insbesondere an der unzureichenden Verfügbarkeit datenflussorientierter Testwerkzeuge erkennbar. Für den Defs/Uses-Test existieren einige wenige Testwerkzeuge. Der Required k-Tuples Test und die Datenkontextüberdeckung werden von Werkzeuganbietern kaum unterstützt. Eine Anwendung der recht komplizierten datenflussorientierten Testtechniken auf die in der Praxis oft umfangreiche Software kann ohne Werkzeugunterstützung nicht empfohlen werden. Daher besitzen die datenflussorientierten Testtechniken im Regelfall eine mangelhafte Praxiseignung. Leider unterstützen auch die Testwerkzeuge für die objektorientierte Software-Entwicklung überwiegend kontrollflussorientierte Testtechniken. Es ist zu vermuten, dass eine Ursache die einfachere Realisierbarkeit von Werkzeugen für kontrollflussorientierte Testtechniken ist.

Die praktische Bedeutung des datenflussorientierten Tests bleibt hinter der des kontrollflussorientierten Tests zurück.

Fachlich passen datenflussorientierte Testtechniken sehr viel besser zur objektorientierten Software-Entwicklung als kontrollflussorientierte Techniken. Objektorientierte Strukturen gruppieren Operationen um gemeinsam benutzte Daten – die Attribute. Die entstehenden Klassen besitzen in ihren Operationen oft eine einfache Kontrollstruktur. Die Komplexität der Abläufe innerhalb einer Klasse ergibt sich aus der Interaktion verschiedener Operationen über gemeinsam benutzte Attribute. Ein datenflussorientierter Testansatz berücksichtigt dieses. Eine kontrollflussorientierte Technik – z. B. der Zweigüberdeckungstest – ignoriert diese Situation nahezu vollständig. Einerseits empfehle ich die Verwendung von datenflussorientierten Testtechniken nur dann, wenn es gelingt, ein entsprechendes unterstützendes Werkzeug zu beschaffen. Andererseits kann der Grundgedanke der datenflussorientierten Testtechniken – die Nutzung von Datenzugriffen für den Test – auch bei der Generierung von Testfällen mit anderen Ansätzen mitbeachtet werden.

Datenflussorientiertes Testen ist geeignet für die objektorientierte Software-Entwicklung.

Datenflussorientierte Testwerkzeuge sind kaum verfügbar.

In der Studie von /Girgis, Woodward 86/ werden einige Defs/Uses-Kriterien (all defs-Kriterium, all p-uses-Kriterium und all c-uses-Kriterium) untereinander und mit anderen Testtechniken verglichen. Insgesamt führen die drei Datenflusstestverfahren, unter Einbeziehung der Analyse der Datenflussanomalien, zur Identifikation von 70 % der Fehler. Das leistungsfähigste datenflussorientierte Testverfahren ist das all c-uses-Kriterium mit 48 % Trefferquote, gefolgt vom all p-uses-Kriterium (34 %) und dem all defs-Test (24 %). Das all c-uses-Kriterium besitzt die erwartungsgemäß die besseren Leistungsdaten bei der Identifikation von Berechnungsfehlern, während das all p-uses-Kriterium Kontrollflussfehler verlässlicher entdeckt. Das all defs-Kriterium hat keinen der Kontrollflussfehler erkannt.

4.5 Bewertung des datenflussorientierten Tests

177

Die Punkte der folgenden Checkliste sollten geprüft werden:

CHECKLISTE

178

>

Falls Sie datenflussorientierte Testtechniken einsetzen möchten, prüfen Sie die Verfügbarkeit von Werkzeugen für Ihre Entwicklungsumgebung.

>

Falls Sie eine datenflussorientierte Testtechnik verwenden wollen, die den Zweigüberdeckungstest nicht subsumiert, so sollten Sie einen vollständigen Zweigüberdeckungstest gegebenenfalls durch ein zusätzliches Zweigüberdeckungstestwerkzeug explizit sicherstellen.

4 Datenflussorientierter, strukturorientierter Test

5 Spezielle dynamische Testtechniken Neben den funktionsorientierten und strukturorientierten Testtechniken existieren die so genannten diversifizierenden Testtechniken, die verschiedene Versionen einer Software gegeneinander testen. Diese Versionen können durch mehrfache Realisierung (n-Versionen-Programmierung), basierend auf einer Spezifikation, realisiert worden sein. Sie können aus einer Version der Software künstlich erzeugt worden sein, oder sie sind zeitlich nacheinander im Sinne von Versionen entstanden. Der so genannte Regressionstest prüft das Verhalten einer aktuellen Software-Version gegen das Verhalten der Vorläuferversion. Der Regressionstest besitzt eine hohe praktische Bedeutung. Einige weitere Techniken können keiner der bisher genannten Kategorien zugeordnet werden. Neben dem so genannten Pfadbereichstest werden stochastische Testtechniken und das im Wesentlichen auf Erfahrung beruhende Error guessing diskutiert. Bei der Verwendung von Zusicherungen handelt es sich nicht um eine Testtechnik im engeren Sinne. Zusicherungen sind ein in der Praxis sehr wichtiges Hilfsmittel zur Testunterstützung, die in Kombination mit jeder Testtechnik eingesetzt werden können und zur Offenbarung von Fehlverhalten dienen.

Übersicht 5.1

Diversifizierender Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

5.2

Bereichstest (Domain Testing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

5.3

Zufallstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

5.4

Error guessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

5.5

Verwendung von Zusicherungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

5.6

Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

179

5.1 5.1.1

Vorteil: Automatisierte Bewertung der Korrektheit der Testergebnisse

Diversifizierender Test Eigenschaften und Ziele des diversifizierenden Tests

Diversifizierende Testtechniken dienen im Unterschied zu den strukturorientierten und den funktionsorientierten Testtechniken nicht dazu, ein Testvollständigkeitskriterium zu definieren. Ein Ziel der diversifizierenden Testtechniken ist, die oft aufwändige und manchmal kaum mögliche Bewertung der Korrektheit der Testergebnisse gegen die Spezifikation zu vermeiden. Die diversifizierenden Testtechniken ersetzen den Vergleich von Testergebnissen mit der Spezifikation durch den Vergleich der Testergebnisse der diversitären Software. Es müssen daher nicht zwei Instanzen auf sehr unterschiedlichen Abstraktionsniveaus verglichen werden; ein konkretes Testergebnis und eine oft recht abstrakte Spezifikation. Vielmehr werden zwei konkrete Testergebnisse miteinander verglichen. Dies kann oft automatisch geschehen. Die Automatisierung dieses Vergleichs ist der wesentliche Vorteil der diversifizierenden Testtechniken. Die diversifizierenden Testtechniken verfolgen recht unterschiedliche Ziele. Der Back to Back-Test zielt auf eine weitgehende Testautomatisierung. Der Mutationen-Test ist keine Testtechnik im eigentlichen Sinne. Er bietet die Möglichkeit, die Leistungsfähigkeit von Testtechniken unter kontrollierten Bedingungen systematisch zu vergleichen. Der Regressionstest zielt auf die Erkennung von Folgefehlern nach Fehlerkorrekturen und nach Funktionserweiterungen in einer Versionsentwicklung.

5.1.2 Back to Back-Test 5.1.2.1 Der Back to Back-Test ersetzt das heterogene Redundanzprinzip.

180

Eigenschaften und Ziele des Back to Back-Tests

Die dem Back to Back-Test zugrunde liegende n-Versionen-Programmierung ist eine Software-Analogie des für Hardware bekannten Prinzips der so genannten heterogenen Redundanz. Hardware-Redundanz dient zur Erhöhung der Sicherheit und/oder Verfügbarkeit von Systemen. Durch zweifache Ausführung eines sicherheitskritischen Systems ist es möglich, Fehlverhalten eines Kanals durch Vergleich mit den Reaktionen des zweiten Kanals zu erkennen. Das System kann in solchen Fällen abgeschaltet werden, um unsichere Betriebssituationen zu vermeiden. In diesem Beispiel dient die Redundanz zur Erhöhung der Sicherheit. Das System besitzt jedoch eine geringere Verfügbarkeit als die einkanalige Lösung. Falls ein zweikanalig redundantes System nach Ausfall eines Kanals als einkanalig nicht-redundantes System weiterbetrieben wird, so erhöht das die Verfügbarkeit. Diese Lösung ist aber nicht sicherer als die einkanalige Variante. Natürlich kann man Systeme auch aus mehr als zwei Kanälen aufbauen. Eine dreikanalige Lösung ist natürlich teurer als eine zweikanalige Lösung. Ein dreikanaliges System kann allerdings

5 Spezielle dynamische Testtechniken

nach Ausfall eines Kanals als sicheres so genanntes 2-aus-2-System weiterbetrieben werden. In diesem Fall steigen Sicherheit und Verfügbarkeit an, allerdings auch zu erhöhten Kosten. Werden mehrkanalige Systeme aus gleichen Komponenten aufgebaut, so spricht man von homogener Redundanz. Diese Lösung birgt die Gefahr, dass Fehlverhalten in redundanten Kanälen aufgrund gleicher Ursachen auftreten. Um dies zu vermeiden, kann man mehrkanalige Systeme aus unterschiedlichen Komponenten aufbauen. Man spricht dann von heterogener Redundanz. Es ist direkt einsichtig, dass homogene Redundanz bei Software keinen zusätzlichen Schutz gegen Fehlverhalten bietet. Software enthält nur systematische Fehler. Zufälliges Versagen wie bei Hardware kommt nicht vor. Gegen systematische Fehler hilft nur das heterogene Redundanzprinzip, da es eine Chance bietet, dass die jeweils andere Software-Version den entsprechenden systematischen Fehler nicht enthält.

Homogene Redundanz vs. heterogene Redundanz

Es ist die Idee des Back to Back-Tests, mehrere Versionen einer Software, basierend auf einer Spezifikation, unabhängig voneinander zu realisieren. Anschließend werden die diversitären Versionen mit identischen Testdaten versorgt. Die Korrektheit der Ergebnisse wird durch Vergleich der Ausgaben und Reaktionen beurteilt (Abb. 5.1). Liefern alle Versionen identische Ausgaben, so gelten sie als korrekt. Gibt es Abweichungen, so müssen die Ursachen festgestellt und behoben werden. Das gestattet es, in sehr kurzer Zeit sehr viele Testfälle abzuarbeiten, da, mit Ausnahme jener Fälle, in denen ein Fehlverhalten aufgetreten ist, kein manueller Eingriff erforderlich ist.

Arbeitsweise des Back to Back-Tests

5.1.2.2

Beschreibung des Back to Back-Tests

Der Back to Back-Test testet mehrere Versionen einer Software gegeneinander (Back to Back). Die Versionen sind, basierend auf identischen Spezifikationen, von unabhängigen Personen realisiert worden. Die Unabhängigkeit der Programmierteams ist wichtig, um die Entstehung gleichartiger Fehler in unterschiedlichen Versionen möglichst zu verhindern. Man bezeichnet diese Form der Software-Entwicklung auch als n-Versionen-Programmierung. Mit Ausnahme von Software, die auf redundanter mehrkanaliger Hardware installiert wird, ist nach der Durchführung eines Back to Back-Tests die Installation nur einer Version des Programms vorgesehen. Die Entwicklung der diversitären Software-Versionen geschieht demzufolge allein zur Testdurchführung, da auf einkanaligen Systemen nur eine der Versionen eingesetzt werden kann. Bei mehrkanaligen Systemen bietet es sich an, die unterschiedlichen Software-Versionen auf den redundanten Hardwarekanälen zu installieren. So wird auch im laufenden System eine heterogene Software-Redundanz realisiert.

ACHTUNG: Die Unabhängigkeit der Programmierteams ist eine wichtige Voraussetzung.

Für die Entwicklung der diversitären Programmversionen fallen höhere Entwicklungskosten an. Da die Versionen mehrfach realisiert werden,

5.1 Diversifizierender Test

181

Bild der Spezifikation

Software

Bild der Spezifikation

Software

Abbildung 5.1 Prinzip des Back to Back-Tests

sind die Entwicklungskosten für n diversitäre Programme etwa um den Faktor n höher als für ein singuläres Programm. Als weitere Kosten entstehen Testeinbettungskosten. Back to Back-Testen ist ggf. wirtschaftlicher als andere Ansätze.

Ein Back to Back-Test kann unter ökonomischen Gesichtspunkten durchaus interessant sein, da durch die Möglichkeit zur weitgehend automatischen Testdurchführung eine Reduktion der Kosten pro Testfall eintritt. Fordert man z. B. eine Software mit hoher Zuverlässigkeit, so kann dies durch einen entsprechend umfassenden Test mit einer hohen Anzahl von Testfällen erreicht werden. In diesem Fall können die Mehrkosten für die Entwicklung der diversitären Programme durch die geringeren Testkosten ausgeglichen werden. Ein Back to Back-Test kann insbesondere bei der Forderung nach hoher Zuverlässigkeit einer Software günstiger sein, als eine konventionell entwickelte und getestete Software. Durch die Möglichkeit, die Korrektheit von Ausgaben aus der Identität der Ausgaben von diversitären Programmen abzuleiten, entfällt die Notwendigkeit, die Korrektheit anhand einer Spezifikation zu prüfen. Der Vergleich der Ausgaben kann automatisch vorgenommen werden. Eine Testdurchführung durch menschliche Tester ist, bei automatischer Generierung der Testfälle, nicht notwendig.

182

5 Spezielle dynamische Testtechniken

Abbildung 5.2 Blindheit des Back to Back-Tests gegenüber gemeinsamen Fehlern

Zwei diversitäre Programme, die gegeneinander getestet werden, erzeugen für einen Testfall entweder identische Ausgaben, die beide korrekt oder beide nicht korrekt sind, oder nicht identische Ausgaben, die beide nicht korrekt sind oder von denen eine nicht korrekt ist. Da die Korrektheit im Rahmen des Back to Back-Tests allein aufgrund der Identität der Ausgaben postuliert wird, kommt die Testeinrichtung für Ausgaben, die nur zufällig gleich und nicht korrekt sind, zu dem Ergebnis, dass eine korrekte Ausgabe vorliegt. Die Ursache sind Fehler, die in den diversitären Versionen identisch vorhanden sind. Sie können durch den Back to Back-Test nicht gefunden werden (Abb. 5.2). Die Annahme, dass die Fehler in diversitären Programmen korreliert sind, wird durch theoretische /Eckhardt, Lee 85/ und experimentelle /Knight, Leveson 86/ Untersuchungen bestätigt.

Nachteil: Gemeinsame Fehler diversitärer Software werden nicht erkannt.

Als Strategie zur Testdatenerzeugung sind im Rahmen eines Back to Back-Tests unterschiedliche Vorgehensweisen möglich. Die einfachste Möglichkeit ist sicherlich die Verwendung von aufgezeichneten, echten Daten. Derartige Testdaten bieten den Vorteil, dass ihre Häufigkeit das durchschnittliche, reale Nutzungsprofil annähert. Ein zufallsorientierter Ansatz ist ebenfalls möglich.

Möglichkeiten der Testdatenerzeugung

Da die diversitären Programme auf einer Spezifikation basieren, bietet sich auch der funktionsorientierte Test mit einer Testdatenerzeugung z. B. nach dem Äquivalenzklassenverfahren oder der Ursache-WirkungsAnalyse an. 5.1.2.3

Bewertung des Back to Back-Tests

Aufgrund des erhöhten Programmieraufwands für die Erstellung der diversitären Software-Versionen wird man den Back to Back-Test nicht für umfangreiche Software-Produkte in ihrer Gesamtheit verwenden. Er bietet sich für die Überprüfung kritischer Software-Komponenten an, die mit

5.1 Diversifizierender Test

Der Back to Back-Test ist besonders geeignet für die Prüfung kleiner, kritischer Softwaremodule. 183

Hilfe eines Entwurfs entsprechend der Kritikalität identifiziert worden sind. Darüber hinaus ist es erforderlich, dass die Ausgaben und Reaktionen der getesteten Software automatisch miteinander verglichen werden können. Dies wird bei Software, die einfache Ausgaben erzeugt, besser gelingen als bei Software, die komplexe Reaktionen z B. auf einer grafischen Benutzungsoberfläche hervorruft. Der Back to Back-Test wird daher häufig für kritische Komponenten eingebetteter Software verwendet. Sowohl die Eingaben als auch die Ausgaben der Software besitzen in diesem Anwendungsbereich oft Signalcharakter. Es handelt sich oft um Boolesche Werte (z. B. Taster betätigt vs. Taster nicht betätigt, Motor an vs. Motor aus). Eingebettete Software ist zudem oft durch hohe Sicherheits- und Zuverlässigkeitsanforderungen charakterisiert, deren Erreichung nur durch sehr intensive, umfangreiche Tests gewährleistet werden kann. Daher kann die durch die weitgehend automatische Testdurchführung des Back to Back-Tests erreichbare Kostenreduktion größer sein als der Kostenanstieg durch die Mehrfachrealisierung. Back to Back-Testen ist in dieser Situation auch aus wirtschaftlichen Gründen sinnvoll.

In bestimmten Testsituationen ist der Back to Back-Test die einzig sinnvolle Möglichkeit zur Testdurchführung.

Besonders interessant ist der Back to Back-Test in Software-Anwendungen, die eine einfache manuelle Bewertung der Korrektheit von Ausgaben nicht gestatten. Hier bietet der Back to Back-Test oft die einzige Möglichkeit zur Testdurchführung. Als Beispiel für eine derartige Anwendung sei hier eine diskrete Fourier-Transformation angeführt. Werden als Testdaten Abtastwerte eines Audiosignals verwendet, so erhält man ausgangsseitig entsprechende Amplituden im Frequenzbereich. Für die diskrete Fourier-Transformation kann zudem sehr leicht eine formale Spezifikation angegeben werden, so dass im Prinzip scheinbar alle Voraussetzungen für eine geeignete Testdurchführung erfüllt sind. Dennoch existiert keine einfache Möglichkeit zu entscheiden, ob die ausgangsseitigen Reaktionen zu den eingegebenen Testdaten passen. Der Versuch, die diskrete Fourier-Transformation mit dem Taschenrechner nachzuvollziehen, wäre sehr zeitaufwendig und würde potentiell auch zu vielen Fehlalarmen aufgrund von Tippfehlern führen. Die einzige einfache Lösungsmöglichkeit ist eine erneute Implementierung des Software-Moduls, die aber nicht von dem Programmierer des ursprünglichen Moduls durchgeführt werden darf, da sonst beide Versionen identische Fehler enthalten werden. Unter den geschilderten Rahmenbedingungen ergibt sich ein Back to Back-Test quasi von selbst als einzig mögliche Lösung. Man benötigt die zweite, unabhängig erstellte Instanz als Testreferenz. Der Back to Back-Test ist besonders für sicherheitskritische, eingebettete Software-Komponenten geeignet. Back to Back-Testen ist hauptsächlich eine Modultesttechnik. Besonders wichtig ist der Back to Back-Test für die Prüfung von heterogen realisierter Software für mehrkanalige Systeme.

184

5 Spezielle dynamische Testtechniken

5.1.3

Mutationen-Test

5.1.3.1

Eigenschaften und Ziele des Mutationen-Tests

Im Unterschied zum Back to Back-Test verlangt der Mutationen-Test keine geänderte Software-Erstellung. Der Mutationen-Test leitet diversitäre Software-Versionen aus einer Originalversion der Software her. Dies geschieht durch künstliches Einfügen kleiner, definierter Modifikationen – der so genannten Mutationen. Die Ausgangsversion der Software wird dabei als korrekt angesehen, während die mutierte Version einen genau bekannten Fehler enthält. Der Mutationen-Test bietet eine präzis definierte Basis für den Vergleich der Leistungsfähigkeit von Testtechniken. So kann z. B. für die Originalversion der Software ein vollständiger Testfallsatz entsprechend einer Testtechnik A gebildet werden so wie ein zweiter vollständiger Testfallsatz entsprechend einer Testtechnik B. Werden die so erzeugten zwei Testfallsätze über die Originalversion und alle entsprechend einer bestimmten Mutationstransformation gebildeten mutierten Versionen ausgeführt, so ist zu erwarten, dass bei einer gewissen Anzahl der mutierten Versionen andere Reaktionen erzeugt werden als bei der Originalversion (Abb. 5.3). Der entsprechende Testfall hätte, falls es sich bei dem eingefügten Fehler um einen realen Fehler gehandelt hätte, diese fehlerhafte Version erkannt. Man sagt auch, der Mutant würde „getötet“ (killing a mutant). Bei einer größeren Anzahl derartiger Experimente erhält man Daten zur Leistungsfähigkeit von Testtechniken. Der Prozentsatz der erkannten Mutanten korrespondiert direkt mit der Fähigkeit der entsprechenden Testtechnik zur Erkennung solcher Fehler, die der Mutationstransformation entsprechen. Daher ist der Mutationen-Test eigentlich keine Testtechnik sondern ein Instrument für den Vergleich der Leistungsfähigkeit von Testtechniken. 5.1.3.2

Beim Mutationen-Test werden künstliche Fehler eingefügt.

Beschreibung des Mutationen-Tests

Der Mutationen-Test basiert auf der Annahme, dass erfahrene SoftwareEntwickler fast korrekte Programme erstellen. Die Programme weichen in ihrem Verhalten nur relativ geringfügig von dem vorgesehenen Verhalten ab. Diese Differenz zwischen Ist- und Sollzustand ist im Wesentlichen die Manifestation einer Anzahl einfacher Fehler, wie Definitionen oder Referenzen falscher Variablen, die Verwendung unkorrekter Operationen oder einfache Fehler in arithmetischen Ausdrücken. Es wird erwartet, dass komplexe Fehler auf bestimmte Art und Weise an einfache Fehler gekoppelt sind /Offutt 89/. Man bezeichnet diesen empirischen Satz als Kopplungseffekt (coupling effect): Testdaten, die in der Lage sind, ein nur mit einfachen Fehlern behaftetes Programm von einem korrekten Programm zu unterscheiden, können implizit auch ein mit komplexeren Fehlern behaftetes Programm als fehlerhaft identifizieren.

5.1 Diversifizierender Test

185

Bild der Spezifikation

Abbildung 5.3 Prinzip des Mutationentests

Die einfachen Fehler verbinden sich zu komplexen Fehlern. Ein typischer Programmierfehler im Rahmen des Mutationen-Tests ist z. B. die Vertauschung eines relationalen Operators in einer Entscheidung des Programmiercodes. Der Mutationen-Test benutzt einfache Fehlertypen, die auf die Programmstruktur bezogen sind. Der Mutationen-Test erzeugt durch Anwendung von Mutations-Transformationen aus einem Programm P eine Menge von mutierten Programmen P’, die anschließend gegen das Programm P getestet werden. Typische Mutations-Transformationen sind: >

186

Referenz einer anderen Variablen

5 Spezielle dynamische Testtechniken

>

Definition einer anderen Variablen

>

Verfälschung arithmetischer Ausdrücke um multiplikative oder additive Konstanten oder Veränderung von Koeffizienten

>

Änderung arithmetischer Relationen um additive Konstanten oder Verfälschung der Relation

>

Verfälschung boolescher Ausdrücke

Die Mutations-Transformationen erzeugen aus dem zu testenden Programm um einfache Fehler veränderte Versionen. Diese Mutanten sollen Programme mit ihren typischen Fehlern nachbilden. Eine Variante des Mutationen-Tests ist der Perturbationen-Test, der eine Modifikation von Anweisungen durch bestimmte Klassen von Fehlerfunktionen vorsieht /Zeil 83/, /Zeil 89/.

Perturbationen-Test

Starker Mutationen-Test (strong mutation test) Man unterscheidet den schwachen und den starken Mutationen-Test. Der starke Mutationen-Test bewertet die Leistungsfähigkeit von Testfällen, anhand abweichender Ausgaben eines Mutanten P’ und des Originals P. P’ ist aus P durch Anwendung einer einzelnen Mutations-Transformation hervorgegangen. Aufgrund des Kopplungseffekts wird erwartet, dass ein Testfall, der einen durch Anwendung einer einzelnen Mutations-Transformation entstandenen Mutanten identifiziert, auch durch wiederholte Anwendung von Transformationen entstandene Mutanten erkennen wird. Ein Testfall erkennt einen Mutanten, falls die Ausgaben von P und P’ unterschiedlich sind. Für eine Menge von Testfällen und eine Anzahl von Mutanten wird folgende Situation eintreten:

Kopplungseffekt

Starker Mutationen-Test: Original und Mutanten müssen unterschiedliche Ausgaben erzeugen.

1. Die Testfälle erzeugen für einen Teil Pi der Mutanten andere Aus-

gaben als das Original P. In diesem Fall sind die entsprechenden Mutanten identifiziert. 2. Die Testfälle erzeugen für einen Teil P j der Mutanten zum Original

P identische Ausgaben. Die Mutanten P j sind unerkannt geblieben. Ein Mutant kann aus zwei Gründen unerkannt bleiben: 1. Die Testfälle sind nicht geeignet gewählt, um den durch die Mutation

hervorgerufenen Fehler zu erkennen. 2. Der Mutant und das Originalprogramm sind äquivalent, so dass kei-

ne Testfälle existieren, die den Mutanten identifizieren. Testfälle, die alle Mutanten töten oder nur zu P äquivalente Mutanten überleben lassen, sind adäquat für den Test von P.

5.1 Diversifizierender Test

Definition: Adäquanz von Testfällen

187

Schwacher Mutationen-Test (weak mutation test) Schwacher Mutationen-Test: Die mutierten Komponenten müssen andere Ergebnisse liefern als das Original.

Der schwache Mutationen-Test ist eine eingeschränkte Version des starken Mutationen-Tests /Howden 82/. Unter der Voraussetzung, dass P ein Programm und C eine so genannte einfache Komponente des Programms ist, die durch Anwendung einer Mutations-Transformation zu der mutierten Komponente C’ des Mutanten P’ wird, fordert der schwache Mutationen-Test die Definition von Testfällen T derart, dass für einen Testfall aus T die Komponente C ausgeführt wird und einen anderen Wert als C’ erzeugt.

Definition: Einfache Komponente

Einfache Komponenten sind üblicherweise elementare Programmelemente wie Variablenzugriffe oder arithmetische oder Boolesche Ausdrücke, also jene Betrachtungseinheiten, auf welche die beschriebenen Mutations-Transformationen anwendbar sind. Die Einschränkung des schwachen Mutationen-Tests gegenüber dem starken Mutationen-Test besteht in der Möglichkeit, dass ein Mutant P’ dessen Komponente C’ einen zu C aus P unterschiedlichen Wert liefert, dennoch zu P identische Ausgaben liefert. Während es für die Erkennung von Mutanten beim schwachen Mutationen-Test ausreicht, dass das mutierte Programmelement sich anders verhält als das entsprechende Element des Originals, muss sich der fehlerhafte Zustand beim starken Mutationen-Test zu einer Ausgabe fortpflanzen.

BEISPIEL

Möchte man die Mutationstransformation zur Verfälschung der relationalen Operatoren anwenden, so sind zunächst entsprechende einfache Komponenten C zu identifizieren, auf welche die Mutationstransformation angewendet werden kann. Relationale Operatoren sind Operatoren wie z. B. oder =. Sie kommen in den Entscheidungen eines Programms vor. Die entsprechenden einfachen Komponenten der Operation ZaehleZchn sind: 1. Zchn ≥ ’A’ 2. Zchn ≤ ’Z’ 3. Gesamtzahl < INT_MAX 4. Zchn = ’A’ 5. Zchn = ’E’ 6. Zchn = ’I’ 7. Zchn = ’O’ 8. Zchn = ’U’ Die mutierten Komponenten C’ entstehen durch Vertauschung des relationalen Operators. Die möglichen Operatoren sind: =, ≤, ≥, , =

188

5 Spezielle dynamische Testtechniken

Aus der Komponente 1 können die fünf unterschiedlichen in Tab. 5.1 angegebenen mutierten Komponenten C’ erzeugt werden. Die angegebenen Testdaten sind jeweils geeignet, die mutierten Komponenten vom Original zu unterscheiden.

Tabelle 5.1 Mutierte Komponenten und Testfälle

Die mutierten Komponenten erzeugen mit den angegebenen Werten für Zchn von dem Original abweichende Ergebnisse. Die Bedingung (Zchn = ’A’) ergibt mit dem Wert ’B’ für Zchn den Wahrheitswert falsch. Die unverfälschte Relation (Zchn ≥ ’A’) ist für Zchn gleich ’B’ wahr. Ein Testfall, der für Zchn den Wert ’B’ enthält, ist hinreichend sensitiv zur Unterscheidung der mutierten Komponente (Zchn = ’A’) von der unverfälschten Komponente. Mit den Werten ’A’ und ’B’ für Zchn können alle Mutanten der Komponente 1 erkannt werden. Für die restlichen Komponenten existieren folgende mutierte Komponenten:

Tabelle 5.2 Mutierte Komponenten und Testfälle

Es können keine Testdaten erzeugt werden, die abweichende Ergebnisse der mutierten Komponente (Gesamtzahl = INT_MAX) verursachen (Tab. 5.3).

Tabelle 5.3 Mutierte Komponenten und Testfälle

Die mutierte Komponente ist äquivalent zu der unverfälschten Komponente.

5.1 Diversifizierender Test

189

Die mutierte Komponente (Zchn ≤ ’A’) in Tab. 5.4 ist äquivalent zu der nicht mutierten Komponente. Es können keine Testdaten gebildet werden, die abweichende Ergebnisse liefern. Die Bedingung (Zchn ≥ ’A’) ergibt nur für Werte von Zchn, die kleiner sind als ’A’ von der Bedingung (Zchn = ’A’) abweichende Ergebnisse. Da in ZaehleZchn für diese Werte die Schleife nicht betreten wird, sind sie an dieser Stelle nicht möglich. Aus diesem Grund entsteht durch diese Mutation kein geändertes Verhalten.

Tabelle 5.4 Mutierte Komponenten und Testfälle

Tabelle 5.5 Mutierte Komponenten und Testfälle

Tabelle 5.6 Mutierte Komponenten und Testfälle

Tabelle 5.7 Mutierte Komponenten und Testfälle

190

5 Spezielle dynamische Testtechniken

Tabelle 5.8 Mutierte Komponenten und Testfälle

Aus den angegebenen Testdaten in den Tabellen Tab. 5.1 bis Tab. 5.8 können die folgenden Testfälle abgeleitet werden, die in der Lage sind, alle nicht äquivalenten Mutanten zu erkennen: 1. Aufruf mit Gesamtzahl = 0 Eingelesene Zeichen: Zchn = ’A’, ’B’, ’E’, ’I’, ’O’, ’U’, ’Y’, ’Z’, ’a’ 2. Aufruf mit Gesamtzahl = INT_MAX Eingelesenes Zeichen: Zchn = ’A’

Die Durchführung eines Mutationen-Tests erfordert leistungsfähige Werkzeuge. Diese erzeugen durch Anwendung einer Mutationstransformation auf ein zu testendes Programm automatisch Mutanten. Anschließend wird die Eignung einer Menge von Testfällen durch Ausführung des Programms und seiner Mutanten mit diesen Testfällen ermittelt. Der Prozentsatz der erkannten Mutanten ist ein Maß für diese Eignung der Testfälle. Ein Satz von Testfällen ist umso geeigneter, je mehr Mutanten als fehlerhaft identifiziert werden. 5.1.3.3

Der Mutationen-Test erfordert eine leistungsfähige Werkzeugunterstützung.

Bewertung des Mutationen-Tests

Der Mutationen-Test dient im eigentlichen Sinne nicht zur Testdurchführung. Daher ist eine empirische Bewertung des Mutationen-Tests unsinnig. Bezogen auf die in einem gegebenen Programm zufällig vorliegenden Fehler ist zu erwarten, dass die Leistungsfähigkeit des Mutationen-Tests deutlich von der verwendeten Mutationstransformation abhängt. Dennoch sind im Folgenden einige empirische Werte angegeben.

Der Mutationen-Test ist keine Testtechnik im engeren Sinne.

Eine vergleichende Untersuchung /Girgis, Woodward 86/ des datenflussorientierten Tests, des kontrollflussorientierten Tests und des schwachen Mutationen-Tests hat zu Ergebnissen bezüglich der Gesamtleistungsfähigkeit der Verfahren und ihrer Leistungsfähigkeit bezüglich Berechnungsfehlern und Bereichsfehlern des Kontrollflusses geführt. Insgesamt hat der schwache Mutationen-Test zur Entdeckung von 41 % der vorhandenen Fehler geführt. Die datenflussorientierten (70 %) und die kontrollflussorientierten Verfahren (85 %) haben hier eine höhere Erfolgsquote vorzuweisen. Der

5.1 Diversifizierender Test

191

schwache Mutationen-Test hat nur 30 % der Berechnungsfehler, jedoch 79 % der Kontrollflussfehler gefunden. Unter den Mutationen-Tests ist die Mutation der relationalen Ausdrücke das leistungsfähigste einzelne Verfahren mit einer Trefferquote von 21 %. Durch Mutation der Variablenreferenzen sind 18 % der Fehler entdeckt worden. Das Variablendefinitionskriterium hat 14 % der Fehler identifiziert, und durch Mutation der arithmetischen Ausdrücke sind 10 % der Fehler entdeckt worden. Die Betrachtung der Leistungsfähigkeit der einzelnen Mutations-Transformationen in Abhängigkeit der gefundenen Fehlertypen lässt erkennen, dass die Mutation relationaler Ausdrücke das Kriterium ist, das die meisten Kontrollflussfehler entdeckt, andererseits jedoch nur 3 % der Berechnungsfehler identifiziert. Die Mutation der Variablenreferenzen identifiziert ebenfalls einen höheren Prozentsatz der Kontrollflussfehler als der Datenfehler. Die Mutation der Variablendefinitionen und die Mutation der arithmetischen Ausdrücke zeigen höhere Fehlererkennungsraten bei den Berechnungsfehlern als bei den Fehlern des Kontrollflusses.

Der Regressionstest spürt Seiteneffekte von Modifikationen auf.

Ansatz: Wiederholung von Testfällen

5.1.4

Regressionstest

5.1.4.1

Eigenschaften und Ziele des Regressionstests

Das Ziel des Regressionstests ist nachzuweisen, dass Modifikationen von Software keine unerwünschten Auswirkungen auf die Funktionalität besitzen. Durch Software-Modifikationen, z. B. durch Funktionalitätserweiterungen oder Fehlerkorrekturen können neue Fehler in zuvor fehlerfreie Teile eingefügt werden. Der Regressionstest zielt auf die Erkennung derartiger Seiteneffekte. Weil nicht davon ausgegangen werden kann, dass korrekt abgearbeitete Testfälle auch nach Änderungen der Software weiterhin korrekt abgearbeitet werden, reicht die einmalige Durchführung von Testfällen nicht aus. Streng genommen, müssten alle bisherigen Testfälle nach Modifikationen wiederholt werden. Oft kann jedoch sichergestellt werden, dass nur eine bestimmte Teilmenge der Testfälle mit einer vorgenommenen Modifikation potentiell in Verbindung steht. In diesem Fall reicht es aus, nur diese Teilmenge der Testfälle zu wiederholen. Ob ein wiederholter Testfall korrekt abgearbeitet wurde, wird nicht durch Vergleich mit der Spezifikation beurteilt sondern durch Vergleich der neu erzeugten Ausgaben mit den Ausgaben der Vorläuferversion. Falls die Ausgaben identisch sind, so ist ein Testfall erfolgreich absolviert. 5.1.4.2

Die manuelle Durchführung von Regressionstest ist nicht sinnvoll.

192

Beschreibung des Regressionstests

Grundsätzlich können Regressionstests manuell durchgeführt werden. Dies ist allerdings eine schlechte Lösung. Ein Regressionstest besteht aus der Wiederholung von bereits durchgeführten Testläufen. Die zu testen-

5 Spezielle dynamische Testtechniken

de Software ist pro durchzuführendem Testfall in den gleichen Zustand zu versetzen wie bei der vorhergehenden Durchführung dieses Testfalls. Es sind identische Eingaben vorzunehmen. Die neu erzeugten Ausgaben sind mit den Ausgaben der Vorläuferversion zu vergleichen. Falls keine Unterschiede auftreten, ist der Regressionstestfall erfolgreich absolviert. Falls Unterschiede erkannt werden, so ist zu prüfen, ob diese gewünscht sind, oder ob sie fehlerhafterweise aufgetreten sind. Im erstgenannten Fall ist das geänderte Verhalten für zukünftige Regressionstests als SollVerhalten, also als Referenzfall, zu definieren. Im zweiten Fall muss der Fehler lokalisiert und korrigiert werden. Die Durchführung eines Regressionstests erfordert die wiederholte Abarbeitung stets gleichbleibender Schritte. Es bietet sich daher an, zur Durchführung von Regressionstests ein entsprechendes Werkzeug zu verwenden. Außerdem ist gerade die monotone Wiederholung gleichbleibender Schritte eine Eigenschaft des Regressionstests, die eine manuelle Durchführung behindert. Die Wahrscheinlichkeit, Fehler, die auftreten, zu übersehen, ist recht hoch. Nach stundenlangem, monotonem Eingeben von Testdaten aus einer Testdokumentation gefolgt von einem Vergleich der erzeugten Ausgaben mit den in der Testdokumentation aufgezeichneten Ausgaben kommt es verständlicherweise zu Ermüdungserscheinungen. Diese führen dazu, dass aufgetretene Diskrepanzen häufig nicht bemerkt werden. Dies ist besonders kritisch, weil Fehler in Regressionstests selten sind. Alle Testfälle, die einem Regressionstest zugrunde liegen, sind bereits wenigstens einmal erfolgreich absolviert worden. Man sucht ausschließlich Folgefehler durch Erweiterungen und Fehlerkorrekturen. Die Anzahl der Fehler, die bei der Durchführung von Regressionstests erkannt werden, ist daher typischerweise deutlich geringer als die Fehleranzahl, die bei der erstmaligen Durchführung der zugrunde liegenden Testfälle aufgetreten ist. Die Kombination aus der geringen Wahrscheinlichkeit, dass ein Fehlverhalten auftritt, und der hohen Wahrscheinlichkeit, dass dieses Fehlverhalten übersehen wird, führt dazu, dass manuelle Regressionstests in der Regel wirtschaftlicher Unsinn sind. Sinnvoll ist die automatische Durchführung von Regressionstests mit einem unterstützenden Werkzeug. Ein derartiges Werkzeug zeichnet die Testeingaben und die Testergebnisse bei der Testdurchführung auf. Nachdem die Korrektheit der erzeugten Testergebnisse anhand der Spezifikation verifiziert worden ist, bezeichnet man die aufgezeichneten Testeingaben und Testergebnisse als Referenztestfälle (Abb. 5.4). Die aufgezeichneten Testeingaben können nach Modifikationen der Software automatisch wiederholt werden. Die erzeugten Testergebnisse werden mit den zuvor aufgezeichneten Referenzergebnissen verglichen. Ein manueller Eingriff ist nur erforderlich, falls abweichende Testergebnisse festgestellt werden. Durch die Automatisierung des Regressionstests wird der Aufwand für die manuelle Wiederholung der Testfälle eingespart. Darüber hinaus wird das Risiko vermieden, Abweichungen zwischen den Regressions- und den

5.1 Diversifizierender Test

Regressionstests sind, soweit möglich, zu automatisieren.

Manuelle Regressionstests sind wirtschaftlich unsinnig.

193

Abbildung 5.4 Prinzip des Regressionstests

Referenzergebnissen zu übersehen. Automatische Regressionstests sind daher technisch und wirtschaftlich besser als manuelle Regressionstests. Regressionstestwerkzeuge bieten oft weitere Funktionalität.

Da Regressionstestwerkzeuge lediglich Aktivitäten an den Schnittstellen aufzeichnen müssen – die Eingaben und Reaktionen – sind Regressionstestwerkzeuge in der Regel unabhängig von der Programmiersprache der zu testenden Software. Viele Regressionstestwerkzeuge bieten bereits die Möglichkeit, grafische Benutzungsoberflächen zu testen. Oft verfügen Regressionstestwerkzeuge zusätzlich über Möglichkeiten zur Lasterzeugung und zur Messung von Auslastungen und Antwortzeiten im Leistungs- und Stresstest. 5.1.4.3

Regressionstests sind unverzichtbar.

194

Bewertung des Regressionstests

Die Fähigkeit zur Wiederholung von Tests – insbesondere nach Modifikationen – wird in vielen Standards gefordert. Die Durchführung von Regressionstests ist daher eine notwendige Tätigkeit in der Software-Entwicklung. Standards verlangen in der Regel keine automatischen Regressionstests. Wie oben bereits argumentiert, sind manuelle Regressionstests jedoch oft nicht sinnvoll. Daher sollten Regressionstests, so weit möglich, automatisch durchgeführt werden. Falls ein Teil der Testfälle nicht automatisiert werden kann, muss entschieden werden, ob diese Testfälle nicht wiederholt werden oder im Ausnahmefall manuell durchgeführt werden. Regressionstests sind von zentraler Bedeutung, um Folgefehler und Seiteneffekte nach Modifikationen weitgehend auszuschließen. Sie sollten daher nicht als unangenehme Forderung von Standards gesehen werden sondern als wichtiges Mittel zur Fehlerreduzierung.

5 Spezielle dynamische Testtechniken

5.1.5

Bewertung des diversifizierenden Tests

Die diversifizierenden Tests besitzen anders als z. B. die funktionsorientierten Testtechniken keine homogene Bedeutung als Gruppe von Testtechniken. Der Regressionstest ist eine in der Praxis sehr wichtige Testtechnik. Der Back to Back-Test ist auf einen speziellen Anwendungsbereich beschränkt; dort aber sehr leistungsfähig und oft die einzige Möglichkeit zur Testdurchführung. Der Mutationen-Test ist kein Testverfahren im eigentlichen Sinne sondern bietet eine definierte Experimentierplattform zur Beurteilung der Leistungsfähigkeit von Testtechniken. Daher kann die Gruppe der diversifizierenden Testtechniken nicht insgesamt bewertet werden. Vielmehr ist es nötig, die einzelnen Techniken getrennt zu betrachten. Zusammenfassend werden die folgenden Empfehlungen gegeben: >

Der Regressionstest ist als unverzichtbarer Bestandteil jeder Software-Entwicklung zu bewerten. Wichtig ist, Regressionstests – so weit möglich – zu automatisieren.

>

Der Back to Back-Test ist besonders für technische Anwendungen geeignet. Da er die mehrfache Realisierung der zu testenden Software verlangt, ist es erforderlich, möglichst kleine mit diesem Verfahren zu überprüfende Software-Komponenten zu identifizieren. Dies geschieht in der Regel mit Hilfe eines Entwurfes nach Kritikalität. Der Back to Back-Test ist besonders interessant für sicherheitskritische oder hoch zuverlässige Software-Anwendungen, die eine Vielzahl von Testfällen erfordern. Darüber hinaus bietet er eine einfache Möglichkeit zur Bewertung der Korrektheit von Testergebnissen, wenn eine manuelle Bewertung schwierig ist.

>

Der Mutationen-Test kann für die Praxis als Testverfahren nicht empfohlen werden. Empirische Ergebnisse zur Leistungsfähigkeit von Testtechniken, die auf Basis von Mutationen-Tests gewonnen wurden, sind für die Praxis jedoch von hoher Bedeutung.

5.2 5.2.1

Bereichstest (Domain Testing) Eigenschaften und Ziele der Bereichstests

Einige Teststrategien nehmen eine Sonderstellung ein, da sie keiner der bisher beschriebenen Kategorien eindeutig zugeordnet werden können. Entweder verfolgen sie vollständig andere Zielsetzungen als die kontrollflussorientierten, datenflussorientierten, funktionsorientierten oder diversifizierenden Ansätze, oder sie wählen eine Mischform der Verfahren. Einige der im Folgenden beschriebenen Verfahren sind eigenständig, an-

5.2 Bereichstest (Domain Testing)

195

dere sind nur in Kombination mit weiteren Testtechniken sinnvoll einsetzbar. Neben der im Zusammenhang mit dem funktionsorientierten Test dargestellten funktionsorientierten Äquivalenzklassenbildung anhand der Programmspezifikation besteht die Möglichkeit, die Implementation als Basis zur Teilung des Eingabedatenbereichs zu benutzen. Auf dieser Grundlage – der Verwendung von Spezifikation und Implementation zur Bildung von Äquivalenzklassen – ist eine Anzahl von eigenständigen, fehlerorientierten Teststrategien entstanden, die in der englischsprachigen Literatur unter dem Begriff Domain-Testing behandelt werden /Clarke et al. 82/. Alle Bereichstests sind eine gezielte Kombination einfacherer Testtechniken.

5.2.2

Zwei Fehlerklassen: Bereichsfehler und Berechnungsfehler

Heuristik: Fehler häufen sich an Bereichsgrenzen

196

Pfadbereichstest

Die strukturorientierte Äquivalenzklassenbildung geht auf eine grundlegende Veröffentlichung von /White, Cohen 80/ zum Thema Domain Testing zurück. Die in einem Programm vorhandenen Fehler können in zwei Klassen geteilt werden – Bereichsfehler und Berechnungsfehler. Ein Bereichsfehler führt zur Ausführung eines falschen Programmpfads. Ein Berechnungsfehler liegt dann vor, wenn eine bestimmte Eingabe den korrekten Pfad ausführt, jedoch zur Berechnung eines falschen Wertes führt. Die hier dargestellte Testtechnik konzentriert sich auf die Entdeckung der Bereichsfehler, bietet aber auch zum Teil die Möglichkeit Berechnungsfehler zu erkennen. Der Eingabedatenbereich eines Programms wird in Bezug auf die Programmpfade in Pfadbereiche geteilt. Das Verfahren besitzt durch die Bildung dieser Äquivalenzklassen, deren Werte einen identischen Pfad ausführen, Verbindungen zum Pfadüberdeckungstest. Ein Bereichsfehler manifestiert sich in der Verschiebung der Bereichsgrenzen. Dem Bereichstest liegt die Erfahrung zugrunde, dass Fehler häufig an Bereichsgrenzen auftreten. Bereichsfehler können festgestellt werden, falls Testdaten in der Nähe der Bereichsgrenzen gewählt werden. Der Bereichstest ist ein strukturorientiertes, fehlerorientiertes Verfahren, das durch Kombination von Prinzipien der strukturorientierten Technik Pfadüberdeckungstest mit der fehlerorientierten Grenzwertanalyse entstanden ist. Die hier verwendete Form der Grenzwertanalyse ist ein, im Gegensatz zur Grenzwertanalyse beim funktionsorientierten Test, sehr determiniert eingesetztes Verfahren und ein interessantes Beispiel für die Kombinationsmöglichkeit von höchst unterschiedlichen Testansätzen. Die Pfadbedingung eines Programmpfades ist die Bedingung, die Eingabewerte des Programms erfüllen müssen, um den betrachteten Pfad auszuführen. Sie ergibt sich bei der symbolischen Ausführung des Pfades. Die Pfadbedingung beschreibt Teilbereiche des Eingabewertebereichs – strukturorientierte Äquivalenzklassen – die einen identischen Pfad aus-

5 Spezielle dynamische Testtechniken

führen. Gibt es keine Eingabewerte, welche die Pfadbedingung erfüllen, so ist der Pfad nicht ausführbar. Jedem ausführbaren Pfad Pi kann demzufolge ein Teilbereich D[Pi ] der Eingabewerte und die von dem Pfad kalkulierte Funktion C[Pi ] zugeordnet werden. Ein Programm kann in Form von – möglicherweise unendlich vielen – Paaren (D[Pi ],C[Pi ]) dargestellt werden. D[Pi ] ist der Pfadbereich des Pfades Pi . D[Pi ] stellt jene Eingaben dar, die zur Ausführung des Pfades Pi führen. Jedem Pfad Pi kann die Funktion C[Pi ] zugeordnet werden, welche die durch den Pfad berechneten Werte angibt. >

Ein Bereichsfehler manifestiert sich in der Notwendigkeit zur Modifikation des Pfadbereiches D[Pi ].

>

Ein Berechnungsfehler führt zu einer Veränderung der berechneten Funktion C[Pi ].

>

Fehlende Pfade bewirken das Hinzufügen eines neuen Paares (D[Pi ],C[Pi ]). D[Pi ] ist ein Teilbereich eines Pfadbereiches D[P j ] vor Hinzufügung des neuen Paares.

Da die Entdeckung eines Fehlers mehrere der beschriebenen Modifikationen hervorrufen kann, können Fehler nicht immer eindeutig einem Typ zugeordnet werden. Ein Fehler ist dann von einem bestimmten Fehlertyp, falls in der Menge der verwendeten Modifikationen die dem Fehlertyp zugeordnete Modifikation enthalten ist. Unter den folgenden Voraussetzungen kann gezeigt werden, dass eine betrachtete Bereichsgrenze korrekt ist oder maximal um einen kleinen Wert e von der korrekten Bereichsgrenze abweicht: >

Zufällige Korrektheit der Ausgaben, die einen falschen Pfad ausführen, kommt nicht vor.

>

Es liegt kein fehlender Pfad im Zusammenhang mit dem getesteten Pfad vor.

>

Jede Bereichsgrenze wird von einem einfachen Prädikat erzeugt.

>

Die kalkulierten Funktionen aller benachbarten Pfadbereiche unterscheiden sich von der betrachteten Funktion.

>

Sowohl die gegebene Bereichsgrenze sowie ggf. die korrekte Bereichsgrenze sind lineare Funktionen der Eingabevariablen.

>

Der Eingabebereich ist kontinuierlich.

5.2 Bereichstest (Domain Testing)

197

Die Autoren des Verfahrens definieren zwei Typen von Testfällen bzw. Testpunkten. Ein ON-Testpunkt liegt auf der Bereichsgrenze. OFF-Testpunkte liegen eine kleine Differenz ε entfernt, auf der offenen Seite der Grenze. Daraus folgt, dass Testpunkte auf einer geschlossenen Grenze innerhalb des betrachteten Bereichs liegen, während die auf der offenen Seite der Grenze befindlichen Testpunkte zu einem Nachbarbereich gehören. Im Gegensatz zu dieser Situation befinden sich Testpunkte auf einer offenen Grenzlinie im Nachbarbereich und die um ε entfernten Testpunkte gehören dem betrachteten Bereich an. Durch geschickte Wahl von ONund OFF-Testpunkten und durch Verwendung eines hinreichend kleinen Wertes ε kann die Korrektheit der Grenzlinie bis auf minimale Abweichungen sichergestellt werden. Im Folgenden wird die Arbeitsweise des Verfahrens für zweidimensionale lineare Ungleichungen dargestellt.

BEISPIEL

Die Operation MinMaxBetrag soll für zwei reelle Zahlen die Absolutbeträge bilden. Der größere Betrag soll der Variablen Max und der kleinere Betrag soll der Variablen Min zugeordnet werden. Implementierung in Modula-2: void MinMaxTest::MinMaxBetrag(float &Min, float &Max) { float Hilf; if (Min < 0) { Min = -1 * Min; } if (Max < 0) { Max = -1 * Max; } if (Min > Max) { Hilf = Min; Min = Max; Max = Hilf; } }

In dem Kontrollflussgraphen nach Abb. 5.5 können acht unterschiedliche Pfade identifiziert werden.

198

5 Spezielle dynamische Testtechniken

Abbildung 5.5 Kontrollflussgraph zu MinMaxBetrag

Die Operation enthält folgende Pfade, Pfadbereiche und berechnete Funktionen (Minin und Maxin seinen die Eingabewerte der Variablen Min und Max; Minout und Maxout seinen die Ausgabewerte von Min und Max): P1 = nstart , n1 , n2 , n3 , n4 , n5 , n6 , n f inal D[P1 ]: Minin < 0 ∧ Maxin < 0 ∧ Minin < Maxin C[P1 ]: Minout = -Maxin , Maxout = -Minin P2 = nstart , n1 , n3 , n4 , n5 , n6 , n f inal D[P2 ]: Minin ≥ 0 ∧ Maxin < 0 ∧ Minin > -Maxin C[P2 ]: Minout = -Maxin , Maxout = Minin P3 = nstart , n1 , n2 , n3 , n5 , n6 , n f inal D[P3 ]: Minin < 0 ∧ Maxin ≥ 0 ∧ -Minin > Maxin C[P3 ]: Minout = Maxin , Maxout = -Minin P4 = nstart , n1 , n2 , n3 , n4 , n5 , n f inal D[P4 ]: Minin < 0 ∧ Maxin < 0 ∧ Minin ≥ Maxin C[P4 ]: Minout = -Minin , Maxout = -Maxin P5 = nstart , n1 , n3 , n5 , n6 , n f inal D[P5 ]: Minin ≥ 0 ∧ Maxin ≥ 0 ∧ Minin > Maxin C[P5 ]: Minout = Maxin , Maxout = Minin

5.2 Bereichstest (Domain Testing)

199

P6 = nstart , n1 , n3 , n5 , n6 , n f inal D[P6 ]: Minin ≥ 0 ∧ Maxin < 0 ∧ Minin ≤ -Maxin C[P6 ]: Minout = Minin , Maxout = -Maxin P7 = nstart , n1 , n2 , n3 , n5 , n f inal D[P7 ]: Minin < 0 ∧ Maxin ≥ 0 ∧ -Minin ≤ Maxin C[P7 ]: Minout = -Minin , Maxout = Maxin P8 = nstart , n1 , n3 , n5 , n f inal D[P8 ]: Minin ≥ 0 ∧ Maxin ≥ 0 ∧ Minin ≤ Maxin C[P8 ]: Minout = Minin , Maxout = Maxin

e

Abbildung 5.6 Pfadbereiche der Operation MinMaxBetrag

Die Eingabedatenbereiche können grafisch in einer Ebene, die von den Eingabevariablen Min und Max aufgespannt wird, dargestellt werden (Abb. 5.6). Zu den Prädikaten existieren Grenzlinien, die aufgrund der linearen Ungleichungen der Bedingungen und der ausschließlich linearen Operationen Geraden sind.

200

5 Spezielle dynamische Testtechniken

In Abb. 5.6 sind Testpunkte für den Test einer geschlossenen Grenze für D[P6 ] dargestellt. Für Grenzlinien, die zweidimensionalen Ungleichungen entsprechen, müssen die Testpunkte die Reihenfolge ON-OFF-ON besitzen. Die ON-Testpunkte gehören zum Eingabedatenbereich D[P6 ]. Der OFF-Testpunkt gehört zu D[P2 ]. Falls einer der gewählten Testpunkte eine unkorrekte Ausgabe erzeugt, so liegt ein Fehler vor. Erzeugen alle drei Testpunkte korrekte Ausgaben, so existieren zwei Möglichkeiten: >

Die Bereichsgrenze ist korrekt.

>

Die Grenze ist nicht korrekt, weicht jedoch maximal um einen bestimmten Betrag von der korrekten Bereichsgrenze ab.

e

Abbildung 5.7 Entdeckte fehlerhafte Grenzlinie

Falls alle Testpunkte korrekte Ausgaben erzeugen, so ist sichergestellt, dass die korrekte Grenzlinie nur so verlaufen kann, dass die Verbindungslinien der Punkte a und c sowie b und c geschnitten werden. Für alle anderen Grenzlinien erzeugt mindestens ein Testpunkt ein unkorrektes Ergebnis. Die Linie durch die Punkte x und y in Abb. 5.6 kann eine mögliche Soll-Grenzlinie sein. Die gegebene Grenze würde jedoch nicht als fehlerhaft erkannt, da alle Testpunkte korrekte Ergebnisse liefern. Durch Wahl eines hinreichend kleinen Wertes e für die Entfernung des OFF-Testpunktes von der gegebenen Bereichsgrenze, kann eine fast beliebig geringe Abweichung der korrekten Grenzlinie von der gegebenen Bereichsgrenze erreicht werden.

5.2 Bereichstest (Domain Testing)

201

e

Abbildung 5.8 Entdeckte fehlerhafte Grenzlinie

In Abb. 5.7 und Abb. 5.8 sind zwei als korrekt angenommene Grenzen angegeben, für die die gegebene Grenze als falsch erkannt würde, da stets einer der Testpunkte ein fehlerhaftes Ergebnis liefert.

Probleme des Pfadbereichstests

Das dargestellte Testverfahren weist einige spezifische Problematiken im Zusammenhang mit prinzipiellen Schwächen des Pfadüberdeckungstests, komplexen Datenstrukturen und nichtlinearen Prädikaten auf. Fehler werden vom Tester durch Vergleich der erzeugten Ausgaben mit den erwarteten Ausgaben identifiziert. Aus diesem Grund muss der Tester die Beurteilung der Korrektheit von Ausgaben leisten können. Er benötigt Wissen über das gewünschte Verhalten des Programms – eine mindestens informale Spezifikation. Die Schwierigkeiten, die durch fehlende Pfade und durch das Nichtvorhandensein des entsprechenden Pfadbereichs entstehen, sind ein grundsätzliches Problem der strukturellen Testverfahren, die nur für jene Programmkomponenten Testfälle bilden können, die vorhanden sind. Da die Beurteilung der korrekten Verarbeitung eines Testfalls allein anhand der Korrektheit der erzeugten Ausgaben vorgenommen wird, können Fehler, die nur durch Zufall ein korrektes Ergebnis erzeugen, nicht erkannt werden. Falls zwei benachbarten Pfadbereichen identische Funktionen zugeordnet sind, können Bereichsfehler nicht erkannt werden, da unabhängig vom durchlaufenen Pfad korrekte Ausgaben erzeugt werden. Nichtlineare Pfadprädikate erschweren die Lösung der Pfadbedingung und verursachen Schwierigkeiten bei der Abschätzung des maximal noch zu erwar-

202

5 Spezielle dynamische Testtechniken

tenden Fehlers bezüglich der Lage der Bereichsgrenze, da die Grenzen keine Geraden, sondern Ausschnitte aus komplexeren Funktionen sind.

5.2.3

Test fehleroffenbarender Unterbereiche

/Goodenough, Gerhart 75a/, /Goodenough, Gerhart 75b/, /Goodenough, Gerhart 81/ haben ein Äquivalenzklassenverfahren vorgeschlagen, das eine Teilung des Eingabedatenbereichs anhand des Programmcodes und anhand der Spezifikation vornimmt (siehe auch /Gourlay 83/). Die zentrale These der Autoren ist, dass weder der Code noch die Spezifikation allein als Basis für einen umfassenden Test hinreichend ist. Mit strukturorientierten Vorgehensweisen lassen sich beispielsweise fehlende Pfade nicht entdecken, während bei spezifikationsorientierten Ansätzen die konkrete Implementation nicht ausreichend beachtet wird. Das vorgeschlagene Verfahren nimmt, verursacht durch die Kombination unterschiedlicher Ansätze, eine Stellung zwischen den klassischen Kategorien Black Box-Test und White Box-Test ein. Der von Goodenough und Gerhard vorgeschlagene Ansatz ist von /Weyuker, Ostrand 80, Weyuker, Ostrand 81/ erweitert und modifiziert worden. Der Test fehleroffenbarender Unterbereiche sieht eine kombinierte Verwendung des Pfadbereichstests, des funktionalen Tests und fehlerorientierter Testverfahren vor. Ausgehend von den Begriffen Gültigkeit und Zuverlässigkeit in Bezug auf ein Testkriterium, wird gezeigt, dass ein Kriterium nur dann für alle Programme garantiert zuverlässig und gültig ist, wenn der gesamte Eingabebereich getestet wird. Dieser erschöpfende Test ist für reale Programme unpraktikabel. Ein zuverlässiges Kriterium im Sinne der Definition nach Weyuker und Ostrand ist ein Kriterium, das Tests T bestehend aus einer Anzahl von Testfällen t erzeugt, derart, dass entweder alle Tests T erfolgreich oder nicht erfolgreich sind. Ein Test T ist erfolgreich, falls alle Testfälle t aus T ein gemessen an der Spezifikation korrektes Ergebnis liefern. Ein Testkriterium C ist gültig, falls für ein unkorrektes Programm F mindestens ein Test T erzeugt wird, der nicht erfolgreich in Bezug auf F ist. Ein ideales Kriterium ist zuverlässig und gültig.

Ein Testkriterium für ein numerisches Programm, das mit ganzen Zahlen operiert, könnte verlangen, dass jeder Test T mindestens eine positive und eine negative Eingabe und den Wert Null enthält.

Äquivalenzklassenbildung anhand des Codes und der Spezifikation

Die Kriterien Zuverlässigkeit und Gültigkeit eines Tests

BEISPIEL

Jeder Test T besteht demzufolge aus mindestens drei Testfällen t. Mögliche Tests entsprechend der Forderung des Kriteriums sind: { -1, 0, 1 }, { -4, 0, 18}, ... Dieses Testkriterium ist zuverlässig, falls jeder Satz von Eingaben, der mindestens eine positive und eine negative Zahl und den Wert Null enthält, entweder für alle Eingaben korrekte Ergebnisse liefert oder für mindestens eine Eingabe fehlerhafte Ergebnisse erzeugt.

5.2 Bereichstest (Domain Testing)

203

Das Kriterium ist gültig, falls mindestens einer der Tests T einen Fehler in dem numerischen Programm erkennt. Dies ist dann erfüllt, falls eine gemessen an der Spezifikation falsche Ausgabe erzeugt wird.

Da ein ideales Kriterium zuverlässig und gültig ist, besitzt es folgende Eigenschaften: >

Alle Tests T sind erfolgreich oder nicht erfolgreich.

>

Mindestens ein Test T ist für ein fehlerhaftes Programm nicht erfolgreich.

Daraus folgt, dass jeder beliebige Test T, den ein ideales Kriterium erzeugt, >

für ein fehlerhaftes Programm nicht erfolgreich ist und

>

für ein fehlerfreies Programm erfolgreich ist.

Diese Betrachtungsweise eines Testkriteriums besitzt einige Problematiken:

Definition: Fehleroffenbarender Unterbereich

204

>

Ein für jedes Programm ideales Testkriterium muss erschöpfend testen.

>

Ein für ein bestimmtes Programm F ideales Kriterium, muss nicht notwendig für ein geringfügig modifiziertes Programm F’ ideal sein. Daraus folgt, dass ein anfänglich ideales Kriterium im Zuge fortschreitender Testaktivitäten und entsprechender Programmkorrekturen seinen idealen Charakter verlieren kann.

>

Es existiert keine generelle Entscheidungsmöglichkeit bezüglich der Idealität eines Kriteriums ohne Kenntnis der Programmfehler oder mindestens der Fehlertypen.

Andererseits existiert für jedes Programm F ein ideales Kriterium C, das nicht erschöpfend testet. Zur Lösung dieser Problematik sieht das hier beschriebene Testverfahren die Bildung fehleroffenbarender Unterbereiche vor, die folgendermaßen definiert sind: Ein Testkriterium C ist fehleroffenbarend bezüglich eines Unterbereiches S des Eingabedatenbereichs eines Programms, falls die unkorrekte Verarbeitung einer Eingabe aus S die nicht erfolgreiche Testdurchführung mit jedem Testfallsatz, den C erzeugt, zur Folge hat. Falls die Testdurchführung mit jedem Testfallsatz, den C erzeugt, erfolgreich ist, so erzeugt jede Eingabe aus S korrekte Ausgaben.

5 Spezielle dynamische Testtechniken

Aus dieser Definition kann das Testkriterium C eliminiert werden, indem jede nicht leere Eingabedatenmenge aus S als Testfall zugelassen wird. Fordert man weiterhin das oben beschriebene Verhalten bezüglich der Verarbeitung von Eingaben aus S, so wird S als fehleroffenbarender Unterbereich bezeichnet. Ein fehleroffenbarender Unterbereich S besitzt die Eigenschaft, dass alle Eingaben aus S entweder korrekt oder unkorrekt verarbeitet werden. Zur Bildung der fehleroffenbarenden Unterbereiche ist eine sinnvolle Teilung des Eingabedatenbereichs anhand von programmabhängigen und programmunabhängigen Informationen notwendig. Es kann nicht garantiert werden, dass jeder beliebige Fehler in S entdeckt wird. Der hier vorgesehene Ansatz ist die Bildung fehleroffenbarender Unterbereiche in Bezug auf bestimmte Fehler. Weyuker und Ostrand sehen als ersten Schritt eine Bildung von strukturorientierten Äquivalenzklassen vor – analog zu den von Howden beschriebenen und von White und Cohen zur Definition eines Testverfahrens genutzten Pfadbereichen. Diese Unterbereiche stellen die programmabhängige Information dar und gruppieren Werte zusammen, die von dem Programm gleich behandelt werden. Weitere Unterbereiche entstehen – analog zum funktionalen Test – durch Bildung funktionaler Äquivalenzklassen unter Nutzung von Informationen aus der Spezifikation, dem Algorithmus und den Datenstrukturen, die jene Werte zusammen gruppieren, die von dem Programm gleichartig verarbeitet werden sollten. Die zwei Unterbereichsmengen werden zum Schnitt gebracht, so dass jeder der entstehenden Unterbereiche ausschließlich Werte enthält, die vom Programm gleichartig verarbeitet werden und nach der Spezifikation gleichartig verarbeitet werden sollten. Zusätzlich können noch Erkenntnisse über potentielle Fehler einfließen. Üblicherweise weichen die aus der Struktur gebildeten Äquivalenzklassen nicht sehr von den aus der Spezifikation hergeleiteten Unterbereichen ab, da Implementation und Spezifikation Beschreibungen eines Problems auf unterschiedlichen Abstraktionsebenen sind. Abweichungen sind typische Stellen an denen Fehler vermutet werden können. Die Autoren des Verfahrens sind der Ansicht, dass die so gebildeten Unterbereiche fehleroffenbarend für eine Reihe von Fehlern sind.

Die Spezifikation der Operation MinMaxBetrag teilt den Eingabedatenbereich in drei Unterbereiche mit entsprechenden Subspezifikationen:

BEISPIEL

D[S1 ]: |Minin | < |Maxin | C[S1 ]: Minout = |Minin |, Maxout = |Maxin | D[S2 ]: |Minin | > |Maxin | C[S2 ]: Minout = |Maxin |, Maxout = |Minin | D[S3 ]: |Minin | = |Maxin | C[S3 ]: Minout = Maxout = |Minin |

5.2 Bereichstest (Domain Testing)

205

Ein Vergleich der drei Spezifikationsteilbereiche mit den acht Teilbereichen der Implementation lässt erkennen, dass die Bereiche D[S1 ] und D[S2 ] auf alle acht Implementationsbereiche abgebildet werden. Für den Bereich D[S3 ] existiert kein gesonderter Bereich in der Implementation. D[S3 ] wird gemeinsam mit anderen Bereichen durch die Implementation behandelt. D[P7 ] enthält Teile von D[S1 ] und Teile von D[S3 ], aber keiner der zwei Spezifikationsbereiche ist in D[P7 ] vollständig enthalten. D[S1 ] enthält Teile von D[P7 ]. D[S1 ] enthält D[P7 ] jedoch nicht vollständig. Der Schnitt der drei Spezifikationsbereiche mit den acht Implementationsbereichen erzeugt 12 Eingabedatenbereiche: D1 = D[P1 ] ∩ D[S2 ] = Minin < 0 ∧ Maxin < 0 ∧ Minin < Maxin D2 = D[P2 ] ∩ D[S2 ] = Minin ≥ 0 ∧ Maxin < 0 ∧ Minin > -Maxin D3 = D[P3 ] ∩ D[S2 ] = Minin < 0 ∧ Maxin ≥ 0 ∧ -Minin > Maxin D4 = D[P4 ] ∩ D[S1 ] = Minin < 0 ∧ Maxin < 0 ∧ Minin > Maxin D5 = D[P5 ] ∩ D[S2 ] = Minin ≥ 0 ∧ Maxin ≥ 0 ∧ Minin > Maxin D6 = D[P6 ] ∩ D[S1 ] = Minin ≥ 0 ∧ Maxin < 0 ∧ Minin < -Maxin D7 = D[P7 ] ∩ D[S1 ] = Minin < 0 ∧ Maxin ≥ 0 ∧ -Minin < Maxin D8 = D[P8 ] ∩ D[S1 ] = Minin ≥ 0 ∧ Maxin ≥ 0 ∧ Minin < Maxin D9 = D[P4 ] ∩ D[S3 ] = Minin < 0 ∧ Maxin < 0 ∧ Minin = Maxin D10 = D[P6 ] ∩ D[S3 ] = Minin > 0 ∧ Maxin < 0 ∧ Minin = -Maxin D11 = D[P7 ] ∩ D[S3 ] = Minin < 0 ∧ Maxin > 0 ∧ -Minin = Maxin D12 = D[P8 ] ∩ D[S3 ] = Minin ≥ 0 ∧ Maxin ≥ 0 ∧ Minin = Maxin Aus diesen fehleroffenbarenden Unterbereichen können konkrete Testfälle nach unterschiedlichen Aspekten ausgewählt werden. Eine fehlerorientierte Vorgehensweise unter Verwendung der Grenzwertanalyse oder des Tests spezieller Werte ist sinnvoll.

5.2.4 Kombination von Korrektheitsbeweis und dynamischem Test

206

Partition-Analyse

/Richardson, Clarke 81/, /Richardson, Clarke 85/ haben ein Verfahren vorgeschlagen, das einen zum Test von fehleroffenbarenden Unterbereichen identischen Ansatz wählt und zusätzlich eine Kombination des Korrektheitsbeweises mit dem dynamischen Test vorsieht. Die hier beschriebene Form der Partition-Analyse ist ein konkretes Verfahren. Der Begriff wird im Unterschied zu einigen Publikationen nicht als Oberbegriff für eine Gruppe von Verfahren verwendet. In /Jeng, Weyuker 89/ wird eine wesentlich weitere Definition des Begriffs Partition-Analyse verwendet. Die Partition-Analyse ist ein gutes Beispiel für jüngere Testansätze, die durch gemeinsame Anwendung verschiedener Techniken eine Leistungssteigerung erreichen wollen. Die Zuordnung zum dynamischen Test ist nur aufgrund der Beziehungen des Verfahrens zu den zwei zuvor dargestellten Testansätzen gewählt worden. Eine Zuordnung zum symbolischen Test oder zur Verifikation ist ebenso möglich. Die zentralen Thesen der Autoren sind, dass weder Korrektheitsbeweis noch Test allein

5 Spezielle dynamische Testtechniken

eingesetzt ausreichen, um hinreichende Zuverlässigkeit eines Programm zu garantieren, und dass zur Überprüfung von Programmen die aktuelle Implementation und die Spezifikation benutzt werden müssen. Im Gegensatz zu dem von Weyuker und Ostrand beschriebenen Verfahren muss die Programmspezifikation notwendig in einer formalen Spezifikationssprache verfügbar sein. Aus der Implementation werden durch symbolische Analyse die Pfadbereiche mit den zugeordneten Funktionen abgeleitet. Mit dem gleichen Ansatz können aus der formalen Spezifikation die Teilspezifikationen mit ihren zugeordneten Funktionen gewonnen werden. Analog zum Test fehleroffenbarender Unterbereiche werden die Pfadbereiche mit den Teilspezifikationsbereichen zum Schnitt gebracht. Die entstehenden Unterbereiche bezeichnen Richardson und Clarke als Procedure subdomains, für die symbolische Ausdrücke bezüglich der durch die Spezifikation und durch die Implementation kalkulierten Funktionen existieren. Der erste Schritt zur Überprüfung der Übereinstimmung zwischen Spezifikation und Implementation ist die Verifikation der Partition-Analyse. Es werden drei Konsistenzeigenschaften definiert: >

Kompatibilität: Eine Implementation P ist kompatibel zu einer Spezifikation S, falls P und S jeweils einen identischen Eingabevektor x und Ausgabevektor z verwenden und für identische Wertebereiche D[S] = D[P] definiert sind.

>

Äquivalenz: Eine Implementation P ist äquivalent zu einer Spezifikation S, falls P(x) = S(x) für alle x ∈ D[S] gilt.

>

Isomorphismus: Eine Implementation P ist isomorph zu einer Spezifikation S, falls eine bijektive Abbildung B:S→P existiert, so dass B(Si ) = P j dann und nur dann gilt, falls Si = P j .

Die Kompatibilitäts-Eigenschaft dient zur Konsistenzprüfung der Schnittstellen. Spezifikation und Implementation müssen über identische Schnittstellen, das heißt gleiche Art und Anzahl von Parametern verfügen. Außerdem müssen die Definitionsbereiche identisch sein. Die Äquivalenz zwischen einer Spezifikation und einer Implementation impliziert die Korrektheit der Implementation in Bezug auf die Spezifikation. In Fällen, in denen die Äquivalenz schwierig zu zeigen ist, kann u. U. Isomorphismus hergeleitet werden, der zur Demonstration der Korrektheit hinreicht, aber nicht notwendig ist. Der Verifikationsprozess beginnt mit der Herleitung der Kompatibilität. Kann diese Eigenschaft gezeigt werden, so wird als nächstes versucht, die Äquivalenz oder den Isomorphismus für die entstandenen Teilbereiche zu zeigen. Zu diesem Zweck müssen die symbolischen Ausdrücke für die durch die Implementation kalkulierte Funktion und die nach der Spezifikation zu kalkulierende Funktion verglichen werden. Falls für Teilbereiche Kompatibilität und

5.2 Bereichstest (Domain Testing)

Definition von Konsistenzeigenschaften

Ablauf der PartitionAnalyse

207

Äquivalenz bzw. Isomorphismus hergeleitet werden können, so ist für diese Teilbereiche Korrektheit gezeigt. Der Verifikationsprozess muss jedoch nicht immer erfolgreich sein und besitzt zusätzlich den Nachteil, dass er die Postulierung einer künstlichen Umgebung voraussetzt, sich also der natürlichen Laufzeitumgebung weitgehend verschließt. Zur Unterstützung der erfolgreichen Verifikation sieht das Verfahren darum die Durchführung zusätzlicher Tests in der natürlichen Umgebung vor. Ist der Verifikationsprozess in Teilen nicht erfolgreich gewesen, so kann die Durchführung dynamischer Tests das Vertrauen in die Funktion der Software erhöhen oder Beispiele für Fehlfunktionen liefern. Die Wahl von Testfällen erfolgt analog zu dem Test fehleroffenbarender Unterbereiche unter Verwendung fehlerbasierter Strategien zur Wahl von konkreten Testdaten innerhalb einer Procedure subdomain. Richardson und Clarke sehen den Test spezieller Werte und die Wahl von Testdaten aus Grenzbereichen vor.

5.2.5

Bereichstests besitzen eine eher geringe Praxiseignung.

Die Bereichstests sind im Prinzip eine Verallgemeinerung des der funktionalen Äquivalenzklassenbildung zugrunde liegenden Verfahrens. Im Grunde sind alle Bereichstest-Techniken Äquivalenzklassenbildner, die die Äquivalenzklassenbildung nach jeweils unterschiedlichen Regeln vornehmen. Die Bereichstests besitzen spezifische Schwächen, die ihre Praxiseignung reduzieren. Die Anwendung von Bereichstesttechniken wird daher nicht empfohlen.

5.3

Der Zufallstest ist eine stochastische Testtechnik.

208

Bewertung der Bereichstests

Zufallstest

Der Zufallstest (random test) ist eine Testtechnik, die aus den Wertebereichen der Eingabedaten zufällig Testfälle erzeugt. Im Unterschied zu den anderen hier dargestellten Testverfahren, liegt dem Zufallstest keine deterministische Strategie zugrunde. Der Zufallstest ist eine stochastische Testtechnik. In der einschlägigen Literatur findet man typischerweise eine Gegeneinanderstellung von random testing und partition testing. Mit dem Begriff partition testing werden in diesem Zusammenhang diejenigen Testtechniken bezeichnet, die den Eingabedatenbereich in Teilbereiche zerlegen und verlangen, dass diese Teilbereiche mit Testdaten nach bestimmten Regeln vollständig abgedeckt werden. Die Bildung dieser Partitionen kann nach unterschiedlichen Regeln geschehen. Alle in diesem Buch vorgestellten funktions- und strukturorientierten Testtechniken sind nach dieser Definition partition tests. Die funktionsorientierten Testtechniken nehmen eine Unterteilung des Eingabedatenbereichs anhand der Spezifikation vor, während die strukturorientierten Testtechniken den Eingabebereich anhand von Strukturinformationen partitio-

5 Spezielle dynamische Testtechniken

nieren. Partitionen können disjunkt sein (z. B. beim Pfadüberdeckungstest) oder Überschneidungen aufweisen (z. B. beim Zweigüberdeckungstest). Der Zufallstest partitioniert den Eingabedatenbereich nicht. Vielmehr wird der Eingabedatenbereich entsprechend einer vorgegebenen Häufigkeitsverteilung mit Testfällen abgedeckt. Im einfachsten Fall wählt man eine gleichverteilte Abdeckung. Eine in der Praxis verbreitete Fassung des Zufallstests nutzt das so genannte operationale Profil. Das operationale Profil gibt an, welche Betriebsfälle in der Praxis wie häufig auftreten. Ein Zufallstest entsprechend des operationalen Profils simuliert daher die reale Benutzung. Verbreitet werden die Testfälle für den Test nach dem operationalen Profil nicht synthetisch erzeugt sondern durch Aufzeichnung realer Betriebsfälle in der Praxis gewonnen. Ein Zufallstest entsprechend des operationalen Profils ermöglicht es durch statistische Analyse der Ergebnisse, Aussagen über Qualitätseigenschaften – z. B. Zuverlässigkeit – zu erhalten.

Definition: Operationales Profil

Der Zufallstest ist von vielen Autoren insbesondere wegen des fehlenden deterministischen Verhaltens kritisiert worden. /Myers 79/ schreibt: „Probably the poorest methodology of all is random-input testing – the process of testing a program by selecting, at random, some subset of all possible input values.“ Später durchgeführte Untersuchungen zeigen jedoch das Zufallstest in Bezug auf seine Leistungsfähigkeit nicht deutlich schlechter als die deterministischen Testtechniken ist. Der Aufwand zur Erzeugung der Testdaten ist beim Zufallstest in der Regel deutlich geringer. Daher kann Zufallstesten in Bezug auf die Kosten ein effizienteres Verfahren sein. Mehrere Autoren haben diesen Sachverhalt bestätigt /Duran, Ntafos 84/, /Hamlet, Taylor 90/, /Weyuker, Jeng 91/. Grundsätzlich könnte dies Anlass zu der Überlegung geben, ob z. B. der hohe Aufwand für Abdeckungsmessungen (z. B. Zweigüberdeckungstest) gerechtfertigt ist. Neuere Arbeiten scheinen zu bestätigen, dass die intuitive Vermutung, dass geplante Tests leistungsfähiger sein werden als zufällige Tests, begründet ist. /Gutjahr 99/ zeigt, dass durch realistischere Wahl einiger Rahmenbedingungen beim Vergleich von Zufallstests und partition tests ein besseres Abschneiden der partition tests erreicht wird. Gutjahr modelliert die Ausfallraten des Programms mit Zufallsvariablen, die die in den anderen Untersuchungen verwendeten deterministischen Ausfallraten ersetzen. Dieses realistischere Modell führt zu einem Anstieg der Eignung der deterministischen Tests. Eine Erklärung für dieses Ergebnis ist die durch die deterministischen partition tests erreichte gezielte Diversität der Testdaten. Diese ist insbesondere im Falle ungenauen Wissens eine geeignete Strategie, um Risiken zu verhindern.

Leistungsfähigkeit des Zufallstests

In der Praxis werden Zufallstests und die als partition test bezeichneten deterministischen Tests aus unterschiedlichen Gründen verwendet. Die Frage, welcher der beiden Ansätze leistungsfähiger ist, stellt sich daher nicht. Zufallstests, insbesondere auf Basis des operationalen Profils, werden im Hinblick auf die Erzeugung statistisch abgesicherter Zuverlässigkeitsaussagen verwendet. Strukturorientierte Testtechniken dienen dazu

Der Zufallstest ergänzt deterministische Testtechniken.

5.3 Zufallstest

209

sicherzustellen, dass die Codierung entsprechend definierter Vollständigkeitskriterien getestet ist. Funktionsorientierte Testtechniken dienen dazu, die korrekte Funktion gegen die Spezifikation definiert zu prüfen. Eine Ersetzung der funktions- oder strukturorientierten Testtechniken gegen einen reinen Zufallstest ist daher nicht sinnvoll. Zufallstests können weder eine vollständige Abdeckung der Spezifikation durch Testfälle noch eine vollständige Abdeckung des Codes gewährleisten. Ein Zufallstest ist daher ergänzend zu deterministischen Testansätzen sinnvoll. Ein ausschließlicher Zufallstest muss in der Regel als nicht adäquat gelten.

5.4 Error guessing fordert Praxiserfahrung.

Error guessing kann systematische Testtechniken ergänzen.

210

Error guessing

Error guessing wird im Englischen auch als special values testing, also als Test spezieller Werte, bezeichnet. Error guessing arbeitet weder stochastisch noch deterministisch. Der Ansatz besitzt deutliche Merkmale einer Ad hoc-Vorgehensweise. Dieses auf den ersten Blick regellose Herangehen ist die wesentliche Ursache für die Kritik an diesem Testansatz. Error guessing kann weder die Einhaltung statistischer Kriterien noch die Erreichung definierter Abdeckungen garantieren. Einerseits ist error guessing ein sehr unsystematischer Testansatz, der allein eingesetzt unbefriedigend ist. Andererseits gibt es oft Tester, die ad hoc jene Testfälle identifizieren können, die Fehler zu Tage fördern. Wenn der Test durch die „richtigen“ Personen durchgeführt wird, so kann error guessing eine sehr effektive Technik sein. Die Ursache für diese auf den ersten Blick regellose Erzeugung geeigneter Testdaten ist, dass die entsprechenden Personen bei näherer Betrachtung keineswegs regellos arbeiten. Vielmehr nutzen sie eine in oft langjähriger Praxis erworbene Erfahrung, die es ihnen ermöglicht fehlerträchtige Stellen im Programm aufzuspüren. Error guessing ist daher in vielen Fällen kein Ad hoc-Ansatz sondern ein auf Erfahrung basierendes Verfahren. Aus diesem Grund kann man error guessing nicht in der Theorie lernen. Man muss es durch eine langjährige Praxis erwerben. Als alleiniger Testansatz ist error guessing aufgrund der fehlenden Nachweisbarkeit der erreichten Abdeckung und den fehlenden Vollständigkeitskriterien ungeeignet. Ausgesprochen sinnvoll kann error guessing als Ergänzung systematischer Testtechniken sein. Viele dieser Techniken besitzen Freiheitsgrade für die Wahl konkreter Testdaten, die durch Verwendung von error guessing genutzt werden können. So bietet beispielsweise eine systematische funktionsorientierte Testplanung nach dem Verfahren der funktionsorientierten Äquivalenzklassenbildung die erforderliche Abdeckung der Spezifikation. Es definiert aber keine Regel für die Wahl konkreter Testdaten aus den Äquivalenzklassen. Diese Entscheidung kann z. B. durch error guessing herbeigeführt werden.

5 Spezielle dynamische Testtechniken

5.5

Verwendung von Zusicherungen

Zusicherungen (assertions) sind keine Testtechnik. Vielmehr dienen sie zur Offenbarung von Fehlersituationen. Begünstigt durch die in modernen Programmiersprachen verfügbaren Strukturierungs-, Hierarchisierungs- und Kapselungsmechanismen können Fehlersituationen eine Zeit lang unbemerkt in einer Software vorliegen. Ein einfaches Beispiel ist eine Variable, die einen falschen Wert besitzt aber zur Zeit keine von außen sichtbare Wirkung erzeugt. Dies ist insbesondere in objektorientierter Software problematisch. Eine Klasse enthält lokale Daten – die so genannten Attribute – die innerhalb der Klasse im Regelfall gekapselt sind. Die Werte dieser Attribute können normalerweise von außen nicht eingesehen werden. Ein fehlerhafter Attributwert manifestiert sich daher erst von außen wahrnehmbar, wenn dieser Wert durch eine Operation verwendet wird und nach außen eine fehlerhafte Reaktion herbeiführt.

Zusicherung = assertion

Um ein Fehlverhalten von Software zu erkennen, muss der Fehlerort durch einen Testfall ausgeführt werden. Bei der Ausführung des Fehlerortes muss die Fehlersituation eintreten. Dies ist nicht zwangsläufig bei jeder Ausführung des Fehlerortes erfüllt, da der Eintritt der Fehlersituation möglicherweise an die Ausführung mit bestimmten Datenwerten gekoppelt ist.

Die Ausführung des Fehlerortes und der Eintritt der Fehlersituation sind notwendig zur Fehlererkennung.

Die zwei Anweisungen if(x > 5) ... und if(x ≥ 5) ... verhalten sich für alle Werte von x mit Ausnahme des Wertes x = 5 identisch. Falls die Abweichung der beiden Anweisungen ein angenommener Fehler ist, so könnte dieser Fehlerort mit jedem Wert von x ausgeführt werden, ohne das eine Fehlersituation eintritt, außer es wird der Wert 5 als Testdatum gewählt. Die Ausführung des Fehlerortes ist daher eine notwendige aber keine hinreichende Bedingung für den Eintritt der Fehlersituation.

Aber auch der Eintritt der Fehlersituation garantiert nicht, dass ein von außen wahrnehmbares Fehlverhalten eintritt. Wie bereits erläutert, ist es möglich, dass die Fehlersituation in der Software verkapselt ist und nicht wahrgenommen werden kann. Daher ist es erforderlich, dass zur Erkennung des Fehlverhaltens eine Fortpflanzung der Fehlersituation an eine von außen wahrnehmbare Stelle erfolgt. Zusicherungen erhöhen die Wahrscheinlichkeit, dass ein innerhalb einer Software aufgetretenes Fehlverhalten von außen bemerkt wird. Zusicherungen erhöhen die Beobachtbarkeit einer Software. Zunächst einmal ist eine Zusicherung nichts anderes als ein auf formale Weise angegebener Kommentar über Eigenschaften des Programmzustandes an der Stelle, an der die Zusicherung angegeben ist. Nehmen wir an, ein Programmierer bearbeitet eine Stelle seines Programmcodes, von der er weiß, dass an dieser Stelle der Wert der Variablen x positiv sein muss. Er könnte diesen Sachverhalt als kon-

5.5 Verwendung von Zusicherungen

BEISPIEL

Zusicherungen verbessern die Fehlerfortpflanzung an einer beobachtbaren Stelle.

211

ventionellen Kommentar in seinem Programmtext schreiben. Nachteilig an dieser Lösung ist, dass der Kommentar nicht automatisch ausgewertet werden kann. Eine bessere Lösung ist, dieses Wissen als Zusicherung zu formulieren. Der Programmierer muss sich dabei an eine definierte Syntax halten. Denkbar ist, dass Zusicherungen mit dem Schlüsselwort assert eingeleitet werden, und die eigentliche Zusicherung als Argument angegeben werden muss. Der Programmierer würde also an dieser Stelle schreiben: assert(x > 0). Zusicherungen als Sprachbestandteil

Zusicherungen sind in einigen Programmiersprachen Bestandteil des Sprachumfangs. Hier bieten oft die einschlägigen Compiler Möglichkeiten, die Zusicherungen zu aktivieren und zu deaktivieren. Wird die Stelle des Programms bei aktivierten Zusicherungen z. B. mit einem negativen Wert von x durchlaufen, so wird diese Verletzung der Zusicherung registriert und dem Tester unverzüglich gemeldet. Der fehlerhafte Wert der Variablen x pflanzt sich quasi unmittelbar nach außen fort, unabhängig davon, ob er in der Software verkapselt ist. Falls Zusicherungen nur zu Testzwecken verwendet werden, so können sie für die Erzeugung der ausgelieferten Software deaktiviert werden. Es existiert auch die Möglichkeit, die Zusicherungen aktiv zu belassen und ihre Meldungen auf einen nicht-flüchtigen Speicher umzulenken. Dieses Konzept kann dazu dienen, nach dem Eintritt von Fehlverhalten in der Feldbenutzung Hinweise auf die Fehlerursache zu erhalten. Grundsätzlich kann man Programmierern freistellen, ob sie Zusicherungen verwenden möchten.

Minimalanforderungen für die Verwendung von Zusicherungen

Es bietet sich an, mindestens zu Beginn und am Ende jeder Operation sowie für jede Schleife eine Zusicherung zu fordern. Man spricht von Vorbedingungen, Nachbedingungen und Schleifeninvarianten. Durch die Verwendung höherer Logiken können mit Zusicherungen kompliziertere Sachverhalte beschrieben werden. Die Zusicherung assert(x > 0) nutzt so genannte Aussagenlogik. In dieser einfachen Logik können aber einige in der Programmierung häufig vorkommenden Sachverhalte nicht beschrieben werden. So ist es z. B. nicht möglich zu beschreiben, dass ein Feld in einem definierten Indexbereich aufsteigend sortiert ist. Derartige Zusicherungen erfordern so genannte Prädikatenlogik. Diese stellt insbesondere so genannte Quantoren zur Verfügung. Der Allquantor gestattet es zu beschreiben, dass ein bestimmter Sachverhalt für alle Betrachtungseinheiten gilt, während der Existenzquantor beschreibt, dass der Sachverhalt für mindestens eine Betrachtungseinheit gilt. Ein zwischen den Indizes 0 und i aufsteigend sortiertes Feld a kann durch Nutzung eines Allquantors folgendermaßen beschrieben werden: ∀ a ≤ a[ j+1] j|0 ≤ j < i [ j]

212

5 Spezielle dynamische Testtechniken

Dieser Ausdruck ist folgendermaßen zu lesen: Für alle j, die größer gleich 0 und kleiner i sind, gilt: a[ j] ≤ a[ j+1] Dieser Sachverhalt kann ohne Benutzung des Allquantors nicht mehr kompakt beschrieben werden. Im Regelfall bieten Werkzeuge, die die Formulierung von Zusicherungen gestatten, jedoch nur Aussagenlogik an. Die Verwendung von Zusicherungen wird mit Nachdruck empfohlen. Zusicherungen sind ein sehr einfaches Hilfsmittel, um den negativen Einfluss der Kapselungsmechanismen in der Software-Technik zu verringern. Sie erhöhen die Beobachtbarkeit der zu prüfenden Software, ohne den Kapselungsmechanismus zu durchbrechen. Die Software meldet sich „quasi von selbst“ falls eine Fehlersituation aufgetreten ist. Darüber hinaus sind Zusicherungen präzis formulierte Kommentare, die insbesondere Wartungstätigkeiten unterstützen können. Ein Wartungsprogrammierer, der Zusicherungen in einem Quelltext, den er nicht selbst geschrieben hat, findet, weiß von welcher Situation der Programmierer der Software ausgegangen ist. Dies erleichtert ohne Zweifel die Einarbeitung in ein Programm. Minimalregeln für die Verwendung von Zusicherungen sollten Bestandteil von Codierregeln eines jeden Unternehmens sein.

5.6

Zusicherungen unbedingt verwenden

Bewertung

Unter den diversifizierenden Testtechniken ist der Regressionstest zweifellos die Technik mit der breitesten Praxisbedeutung. Er ist für jedes Unternehmen wichtig und wird in allen Anwendungsbereichen gefordert. Entscheidend ist seine automatische Durchführung. Der Back to Back-Test ist besonders geeignet für sicherheitskritische kleine Software-Module. Sein Anwendungsbereich ist im Wesentlichen die eingebettete Software-Entwicklung. Die Pfadbereichstests besitzen keine nennenswerte praktische Bedeutung. Der Zufallstest ist insbesondere in jener Variante, die auf dem operationalen Profil basiert, für die Praxis relevant. Er ermöglicht statistisch abgesicherte Aussagen über Qualitätseigenschaften, z. B. Zuverlässigkeit. Error guessing ist als Testtechnik ohne Zweifel in der Praxis sehr verbreitet. Sie sollte jedoch nur in Kombination mit anderen systematischen Testtechniken, z. B. der funktionalen Äquivalenzklassenbildung, genutzt werden. Zusicherungen sind ein wichtiges Hilfsmittel bei der Testdurchführung. Darüber hinaus bieten sie Vorteile für die Wartungsprogrammierung. Zusicherungen sollten unbedingt in der Software-Entwicklung genutzt werden.

5.6 Bewertung

213

CHECKLISTE

214

>

Prüfen Sie, ob sie ihre Regressionstests automatisch durchführen können. Falls Sie nicht alle Regressionstestfälle automatisieren können, so sollten Sie diejenigen automatisieren, für die das möglich ist. Für die verbleibenden manuellen Testfälle können Sie gegebenenfalls eine Auswahl treffen.

>

Falls Sie sicherheitskritische Software insbesondere im Steuerungsbereich entwickeln und gegebenenfalls mehrkanalige Hardware vorliegen haben, so sollten Sie über die Nutzung des Back to Back-Tests nachdenken. Er ist in dieser Situation oft ein technisch und wirtschaftlich geeignetes Verfahren.

>

Statistisch abgesicherte Aussagen über Software-Zuverlässigkeit können durch einen Zufallstest auf Basis des operationalen Profils erzeugt werden. Einer Einführung in die statistischen Auswertetechniken finden Sie in diesem Buch im Kapitel 14.

>

Error guessing sollten Sie nur in Kombination mit anderen systematischen Techniken nutzen.

>

Sie sollten Zusicherungen unbedingt verwenden. Prüfen Sie, ob ihre Programmierumgebung Zusicherungen unterstützt. Zusicherungen sollten mindestens in Form von Vorbedingungen, Nachbedingungen und Schleifeninvarianten angegeben werden.

5 Spezielle dynamische Testtechniken

6 Modellbasiertes Testen Modellbasiertes Testen ist ein vieldiskutiertes Thema. Daher mag es überraschen, dass es in dem in diesem Buch vorgestellten Klassifikationsschema nicht berücksichtigt wird. Tatsächlich bildet modellbasiertes Testen keine eigenständige Gruppe innerhalb der Testtechniken. Praktisch alle systematischen Testtechniken basieren auf mehr oder weniger expliziten Modellen und können deshalb als modellbasierte Ansätze verstanden werden. Im Folgenden werden daher mehrere an anderer Stelle in diesem Buch beschriebene Techniken referenziert. Neben diesen modellbasierten Tests im weiteren Sinne existieren aber modellbasierte Testtechniken im engeren Sinne. Diese verlangen z. B. die Erstellung aufwändiger Modelle zum Zwecke des Tests, die auf eine automatische Erzeugung von Testfällen und Auswertung von Testläufen zielen. Der Unterschied zu den an anderer Stelle vorgestellten Techniken ist nicht ein anderer Ansatz, sondern eine oft sehr viel umfassendere, systematischere Nutzung von Modellen. Aufgrund der größeren Systematik, Explizitheit und Präzision des modellbasierten Tests im Vergleich zu vielen anderen systematischen Testtechniken ist dem modellbasierten Test hier ein eigenes Kapitel gewidmet.

Übersicht 6.1

Eigenschaften und Ziele des modellbasierten Tests . . . . . . . . . . 216

6.2

Beschreibung des modellbasierten Tests . . . . . . . . . . . . . . . . . . . . 218

6.3

Bewertung des modellbasierten Tests . . . . . . . . . . . . . . . . . . . . . . 229 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

215

6.1

MBT = Testfallerstellung aus Modellen und Testauswertung mit Hilfe von Modellen

Eigenschaften und Ziele des modellbasierten Tests

Viele Software-Prüftechniken der Klassifikation entsprechend Abb. 1.13 können als modellbasierte Testtechniken verstanden werden. Die meisten struktur- und funktionsorientierten Testtechniken basieren auf Modellen, z. B. Kontrollflussgraphen oder Zustandsautomaten. Ein wichtiges Ziel des modellbasierten Testens ist die Erstellung von Testfällen aus Modellen, ein anderes die Auswertung von Testläufen mit Hilfe von Modellen. Die Art der Modelle und die verwendeten Notationen sind dabei vielfältig (siehe z. B. /Schieferdecker et al. 08/).

Abbildung 6.1 Prinzip des MBT

Abb. 6.1 stellt das Prinzip des modellbasierten Testens dar. Der modellbasierte Test im engeren Sinne verwendet Verhaltensmodelle auf Basis der Spezifikationen in den unterschiedlichen Testphasen. Falls das Ziel der automatischen Generierung von Testfällen nicht erreicht werden kann, so können Testfälle ggf. auch manuell aus dem Modell abgeleitet werden. Für die Testfallerstellung gibt es abhängig vom Modelltyp unterschiedliche Kriterien zur Testfallauswahl, z. B. Überdeckungskriterien. Da Modelle nur bestimmte Eigenschaften des Testobjekts – oft abstrahiert – darstellen, sind die erstellten Testfälle häufig noch nicht konkret genug um direkt ausgeführt zu werden. Daher müssen die Testfälle noch verfeinert bzw. präzisiert werden in spezielle Testskripte, die in der Testumgebung direkt verarbeitet werden können. Modellbasiert erzeugte Testfälle enthalten neben den Testeingaben auch Informationen zu den erwarteten Ausgaben und Verhalten. Diese werden mit den Reaktionen der geteste-

216

6 Modellbasiertes Testen

ten Software verglichen, um das Testergebnis zu bestimmen. Mögliche Testergebnisse sind: bestanden (pass), nicht bestanden (fail), ergebnislos (inconclusive). Grundlegend gibt es zwei verschiedene Ansätze für das modellbasierte Testen. Im ersten Ansatz werden Systemmodelle für die automatische Testfallgenerierung verwendet. Diese Systemmodelle sind meistens Verhaltens- oder Strukturmodelle aus der Softwareentwicklung. Der zweite Ansatz verwendet speziell erzeugte Testmodelle.

MBT mit Systemmodellen vs. MBT mit Testmodellen

Abbildung 6.2 MBT aus Systemmodellen

Abb. 6.2 stellt den ersten der beschriebenen Ansätze für modellbasiertes Testen auf Basis von Systemmodellen dar. Das Verhaltens- oder Strukturmodell wird aus den Anforderungen konstruiert. Die Software wird mit den Testfällen ausgeführt. Wurde der Code von Hand implementiert, so wird der Code gegen das Modell geprüft. Wurde der Code aus dem Systemmodell automatisch generiert, wird der verwendete Codegenerator überprüft. Bei der Verwendung nicht zertifizierter Codegeneratoren ist dieser Ansatz empfehlenswert. Die Abb. 6.3 stellt den zweiten der beschriebenen Ansätze dar: Den modellbasierten Test mit einem unabhängigen Testmodell. Hier wird neben dem Systemmodell ein weiteres Modell erzeugt. Derartige Modelle werden Testmodelle genannt. Der Vorteil des unabhängigen Entwicklungspfades für Testmodelle liegt darin, eventuelle Fehler im Systemmodell zu erkennen. Testmodelle werden im Regelfall aus den Anforderungen erstellt. Während der Erstellung des Testmodells werden daher die Anforderungen implizit noch einmal aus dem Aspekt ihrer Überprüfung heraus betrachtet. Dies bietet die Möglichkeit eventuelle Inkonsistenzen oder Unvollständigkeiten zu erkennen und die Anforderungen im Hinblick auf Testbarkeit zu untersuchen. Testfälle werden wie bei dem zuvor beschriebenen Ansatz automatisch generiert oder manuell ausgewählt. Die Testfälle werden auf der Software ausgeführt und ausgewertet. Falls das Sy-

6.1 Eigenschaften und Ziele des modellbasierten Tests

Überprüfung des manuellen erstellten Codes vs. Überprüfung des Codegenerators

Unabhängiges Testmodell ermöglicht Fehler im Systemmodell aufzudecken

217

Abbildung 6.3 MBT mit unabhängigem Testmodell

stemmodell ausführbar ist, beispielsweise durch Simulation, können die Testfälle auch zur Überprüfung des Systemmodells verwendet werden. Nachteilig ist der Zusatzaufwand, der durch die unabhängige Erstellung von Testmodellen entsteht. Dies kann insbesondere bei Änderungen der Anforderungen zu Mehraufwand führen.

Systemmodell vs. Umgebungsmodell

6.2

Beschreibung des modellbasierten Tests

6.2.1

Charakterisierung verschiedener Modelltypen

Innerhalb des modellbasierten Tests werden unterschiedliche prüfungsrelevante Aspekte modelliert. Zum einen ist die Stimulation des Testobjekts durch seine Umgebung von Interesse, zum anderen das spezifizierte Verhalten des Testobjekts. Die Stimulation des Testobjekts wird beim modellbasierten Test durch Umgebungsmodelle repräsentiert, das Verhalten durch Systemmodelle. Umgebungsmodelle beschreiben die Stimulation des Testobjekts durch seine Umgebung und damit typische Eingaben der umgebenden Komponenten, Aktoren und Entitäten an das Testobjekt. Aus Umgebungsmodellen werden Eingaben an das Testobjekt generiert. Ein Systemmodell beschreibt ausgewählte Aspekte des Verhaltens des Testobjekts. Das Systemverhalten ist durch eine Menge von Ein-Ausgabe-Relationen bestimmt. Abb. 6.4 zeigt das Testobjekt eingebettet in seine Umgebung, die z. B. aus Benutzern, weiteren Komponenten, Sensoren und Aktuatoren bestehen kann. Über die Schnittstelle werden Daten zwischen dem Testobjekt und seiner Umgebung ausgetauscht. Neben der Unterscheidung zwischen System- und Umgebungsmodellen gibt es eine Vielzahl weiterer Unterscheidungsmerkmale.

Es gibt eine Vielzahl von Unterscheidungsmerkmalen von Modellen 218

Zum Beispiel gibt es im Bereich der verteilten Systeme das Problem, dass einzelne lokale Ausführungsschritte häufig nicht in eine bestimm-

6 Modellbasiertes Testen

Umgebung

Ausgaben

Eingaben

Benutzer

Schnittstelle

Eingaben

Testobjekt

Komponenten

Eingaben

Ausgaben

Ausgaben

Hardware Sensoren & Aktuatoren

Abbildung 6.4 System- und Umgebungsmodell

ten vorher festgelegten Reihenfolge ausgeführt werden, sondern durch Umgebungsparameter wie das Einsetzen von Interrupts oder der jeweiligen Auslastung des Systems unterschiedliche Reihenfolgen möglich sind. Beim Test dieser Systeme empfiehlt sich die Verwendung so genannter nicht-deterministischer Modelle mit denen die Auswahl unterschiedlicher Ausführungsschrittreihenfolgen explizit dargestellt werden können. Zum Test einzelner Systeme ohne verteilte Funktionalität empfiehlt sich die Verwendung deterministischer Modelle. Auch die Bedeutung der Zeit bzw. zeitlicher Abhängigkeiten von Systemgrößen für die Prüfung und deren Prüfergebnisse nimmt Einfluss auf die Auswahl geeigneter Modelle. Während man bei einfachen sequentiellen Kontrollflüssen ohne direkte Kopplung an Zeit in der Regel so genannte zeitdiskrete Modelle verwendet, sind in den Bereichen, in denen Zeit bzw. zeitliches Verhalten eine zentrale Rolle spielt so genannte zeitkontinuierliche Modelle zu verwenden. In diesen Modellen wird Zeit explizit im Modell aufgenommen, in der Regel durch nicht-negative reelle Zahlen, auf die referenziert werden kann. Auf diese Weise lassen sich Aspekte wie Verweildauer oder Zeitverbrauch geeignet modellieren. Koppelt man die modellierte Zeit an die reale Zeit ergibt sich die zusätzlich Möglichkeit so genannte Echtzeitbedingungen wie zeitbeschränkte Antwortzeiten von Systemen zu modellieren. Für jeden Modelltyp gibt es unterschiedliche Arten der Beschreibung und der Analyse. Zum Beispiel ist es möglich Zustandsautomaten sowohl durch eine explizite Beschreibung der Übergangsrelation, als auch durch Vor- und Nachbedingungen zu spezifizieren. Mittlerweile hat sich

6.2 Beschreibung des modellbasierten Tests

219

die Verwendung von Temporallogiken wie LTL (Linear Temporal Logic) oder CTL (Computational Tree Logic) zur Beschreibung von zeitbehafteten Modellen wie auch zur Beschreibung von Zeiteigenschaften von Modellen in der Praxis bewährt. Für diese Sprachen stehen auch leistungsfähige Analysewerkzeuge, so genannte Model Checker, Constraint Solver und Theorem Prover, zur Verfügung. Für Zuverlässigkeitsanalysen sicherheitskritischer Systeme spielen stochastische Prozesse zur Modellierung der Umgebung eine wichtige Rolle. Wegen ihrer Einfachheit in der Darstellung und der vielfältigen Analysemöglichkeiten haben so genannte Markov-Ketten eine für die Praxis relevante Bedeutung erhalten. Sie können sowohl zur Modellierung stochastischer Wechselwirkungen im Systemverhalten herangezogen werden wie auch zur expliziten Modellierung von Ausfallverhalten. Für jeden Modelltyp gibt es unterschiedliche Kriterien zur Testfallableitung

Für die verschiedenen Modelltypen gibt es unterschiedliche Überdeckungskriterien zur Ableitung von Testfällen. Weit verbreitet sind Kriterien zur strukturellen Modellüberdeckung mit dem Ziel der Abdeckung aller Modellelemente oder bestimmter Kombinationen der Modellelemente in den Testfällen. Daneben gibt es auch Ansätze, die Daten und deren Wertebereiche zu überdecken. Zum Erstellung von Testfällen anhand der genannten Kriterien gibt es verschiedene Verfahren, die mit Hilfe von mathematischen Analysen oder Algorithmen Testfälle aus Modellen ableiten können. Typische Vertreter sind etwa Suchalgorithmen, wie sie in der Graphentheorie verwendet werden, Model Checking oder zufällig erzeugte Testfälle (siehe z. B. /Robinson-Mallett et al. 05/, /Robinson-Mallett et al. 06a/, /Robinson-Mallett et al. 08/). Im Folgenden werden einige ausgewählte Modelltypen genauer vorgestellt. 6.2.1.1

Zustandsautomaten

Zustandsautomaten sind weit verbreitet zur Modellierung von Systemverhalten.

Zustandsautomaten sind ein verbreitetes Beschreibungsmittel für gedächtnisbehaftetes Systemverhalten. In den Kapiteln 2.3 und 13.3.3.1 werden Zustandsautomaten und zustandsbasiertes Testen eingeführt. Ein typischer Vertreter der Zustandsautomaten sind die deterministischen, endlichen Zustandsautomaten. Sie haben eine endliche Anzahl von Zuständen. Determinismus bedeutet, dass in jedem Zustand für jede gültige Eingabe aus dem Eingabealphabet eindeutig eine Transition bestimmt wird, die diesen Zustand verlässt. In der Praxis wird der Determinismus oft implizit angenommen und nicht explizit in die Bezeichnung aufgenommen. Deswegen spricht man auch allgemein von endlichen Zustandsautomaten (finite state machines, FSM).

Erweiterte Zustandsautomaten haben zusätzlich Bedingungen zum Schalten der Transitionen.

Erweiterte Zustandsautomaten (engl. extended finite state machines, EFSM) bieten zusätzlich die Möglichkeit Bedingungen bezüglich von Variablen zum Schalten von Transitionen zu definieren. Diese liegen in Form von Booleschen Ausdrücken vor. Das Beispiel entsprechend Abb.

220

6 Modellbasiertes Testen

13.2 ist demnach ein erweiterter Zustandsautomat mit Bedingungen bezüglich des eingezahlten Geldbetrags. Wie in Kapitel 2.3.2 beschrieben, entsprechen Testfälle im Kontext von Zustandsautomaten Pfaden durch den Automaten. Eine Reihe von Verfahren mit verschiedenen Testvollständigkeitskriterien existiert, die automatisiert Testfälle aus der Automatenstruktur ableiten, z. B.: >

Zustandsüberdeckung

>

Transitionsüberdeckung

>

Überdeckung aller Paare von Transitionen (pairwise transition coverage) Hier müssen die Testfälle alle aufeinander folgenden Paare von Transitionen überdecken. Dieses Kritierium enthält auch die Transitionsüberdeckung.

In /Binder 99/ werden weitere Kriterien beschrieben, die für die Testfallgenerierung aus Zustandsautomaten angewendet werden können. Wird für die Getränkeautomatensteuerung nach Abb. 13.2 die Überdeckung aller Zustände des Automaten angestrebt, so führt das z. B. zu der folgenden Lösung: Die Konfiguration des Automaten ist: >

Zustandsüberdeckung

>

Getränke = Tee, Kaffee, Wasser

>

Preise: Preis(Tee) = 150, Preis(Kaffee) = 200, Preis(Wasser) = 100

>

Akzeptierte Münzen = {10, 20, 50, 100, 200}

Ein abstrakter Testfall, der alle Zustände des Automaten überdeckt, ist in Tab. 6.1 dargestellt. Der Testfall besteht aus fünf Testschritten und überdeckt alle fünf Zustände der Getränkautomatensteuerung. Die Transitionen Getränk_gew. Getränk_wählen(G) und Betrag_gez. Geld_eingeben(B) werden nicht überdeckt. 6.2.1.2

Vor- und Nachbedingungen

Beim Testansatz mit Vor- und Nachbedingungen wird angenommen, dass das das Testobjekt als System mit Variablen beschrieben ist, die die internen Systemzustände abbilden. Die Operationen des Systems greifen auf Variablen zu und ändern gegebenenfalls deren Werte. Vor- und Nachbedingungen beschreiben Zusicherungen zu Variablen vor und nach dem Ausführen von Operationen. Das Konzept wird auch als Design-by-contract

6.2 Beschreibung des modellbasierten Tests

Vor- und Nachbedingungen sind formale Zusicherungen zu Systemvariablen

221

Tabelle 6.1 Ein abstrakter Testfall

bezeichnet. Es ermöglicht die Beschreibung „formaler Verträge“ zur Verwendung von Schnittstellen und Funktionen. Vor- und Nachbedingungen werden auch zur Spezifikation von Operationen verwendet. Vorbedingungen müssen gelten bevor eine Aktion ausgeführt wird. Falls die Vorbedingung nicht eingehalten wird, kann die Aktion nicht ausgeführt werden. Nachbedingungen gelten in jedem Fall nach Ausführung einer Aktion, falls die davor geforderten Vorbedingungen erfüllt wurden. Nachbedingungen dienen insbesondere der Spezifikation des erwarteten Testergebnisses. Daneben gibt es noch so genannte Invarianten. Sie stellen Bedingungen dar, die stets – also invariant – gültig sein müssen. Bedingungen werden oft mit Hilfe von Aussagen- oder Prädikatenlogik formuliert. Die entsprechenden Ausdrücke können sehr komplex sein. In Abhängigkeit von der Notation der Bedingungen kann die Testfallableitung aus Vor- und Nachbedingungen automatisiert und werkzeugunterstützt erfolgen. Die entsprechenden Testtechniken für Bedingungsüberdeckung wurden in Kapitel 3.4 eingeführt. Im Folgenden wird das Strukturmodell der Getränkeautomatensteuerung (Abb. 13.1) benutzt. Ziel ist die einfache Bedingungsüberdeckung der Zusicherungen einer Funktion. Als Beispiel wird die Spezifikationssprache Object Constraint Language (OCL) verwendet. OCL ist Teil der UML und dient der Spezifikation von Zusicherungen und Invarianten in verschiedenen UML-Diagrammen. Das nachfolgende Beispiel in OCL-Notation beschreibt die Vor- und Nachbedingungen der Funktion Geld_eingeben der Komponente Getränkeautomatensteuerung. context Getränkeautomatensteuerung::Geld_eingeben(uint Betrag) pre: 1 ≤ Betrag ≤ 500 post: Gez_Betrag = Gez_Betrag@pre + Betrag

Die Zusicherungen beziehen sich auf den Eingabeparameter Betrag der Funktion und auf die Systemvariable Gez_Betrag. Die Vorbedingung sagt aus, dass der eingegebene Geldbetrag zwischen 1 und 500 betragen muss. Die Nachbedingung sagt aus, dass wenn die Vorbedingung erfüllt

222

6 Modellbasiertes Testen

und die Funktion Geld_eingeben ausgeführt wurde sich der insgesamt gezahlte Betrag (Variable: Gez_Betrag) um den Wert Betrag erhöht hat. Die Nachbedingung sichert die korrekte Berechnung der Variable Gez_Betrag zu. Für die Testfallableitung wird die Vorbedingung betrachtet. Sie bezieht sich auf den Eingabeparameter Betrag und beschreibt dessen Grenzen für gültige Werte. Gemäß der Grenzwertanalyse werden hier die Grenzen für gültige und ungültige Eingaben betrachtet (hier: 1 und 500). Damit ergeben sich 4 mögliche Testfälle (Tab. 6.2). Für die Testfälle kann aus der Nachbedingung das Testorakel abgeleitet werden.

Testfallerstellung für Zusicherungen erfolgt durch Äquivalenzklassen- und Grenzwertanalyse

Tabelle 6.2 Identifizierte Testfälle

Die Testfälle umfassen 2 gültige und 2 ungültige Fälle. Bei Eingabe der ungültigen Testfälle ist zu überprüfen, dass die Getränkeautomatensteuerung die Funktion Geld_eingeben nicht ausführt. Der Wert der Variable Gez_Betrag, díe in der Funktion verwendet wird, ist hier irrelevant. Für die beiden gültigen Testfälle ist es möglich, das erwartete Ergebnis anhand der Nachbedingung zu bestimmen. Die Variable Gez_Betrag muss entsprechend dem eingezahlten Betrag erhöht werden. 6.2.1.3

Temporallogiken

Temporallogiken beschreiben Eigenschaften von Zuständen und deren Änderung in Systemabläufen über die Zeit. Diese Eigenschaften können ggf. auch bewiesen werden. Die Temporallogiken werden im Folgenden auf erweiterte Zustandsautomaten angewendet.

Temporallogiken beschreiben Eigenschaften von Zuständen und deren Änderung über die Zeit

Abb 6.5 zeigt die Spezifikation der Getränkeautomatensteuerung als erweiterten Zustandsautomaten. In der Abbildung wird das System als kommunizierender erweiterter Zustandsautomat dargestellt. Die Eigenschaft „kommunizierend“ bedeutet, dass sich der Automat und mit anderen Automaten über das Verschicken von Nachrichten synchronisieren kann. Die Transitionen können Ereignisse entweder nur senden oder empfangen, aber niemals beides gleichzeitig. Eine Transition, die eine Eingabe und eine Ausgabe enthalten soll, wird auf zwei Transitionen aufgeteilt, eine Transition für das Empfangen der Eingabe und eine Transition für das Senden der Ausgabe. Als erweiterter Zustandsautomat können auch Variablen und Bedingungen bezüglich dieser Variablen in den Transitionen enthalten sein.

6.2 Beschreibung des modellbasierten Tests

223

Abbildung 6.5 Erweiterter Zustandsautomat der Getränkeautomatensteuerung

Anfragesprachen erlauben die formale Spezifikation von Eigenschaften in der Temporallogik

Für Automaten existieren Anfragesprachen mit Temporallogiken, durch die formal Eigenschaften bezüglich dessen Zustände spezifiziert und durch Werkzeuge überprüft werden können. Ein Beispiel einer Temporallogik ist CTL. Die Überprüfung der Eigenschaften erfolgt durch mathematische Standardalgorithmen. Das Ergebnis der Überprüfung sagt aus, ob die spezifizierte Eigenschaft für die gesamten Zustandsautomaten gilt oder nicht. Bei Nichterfüllung wird ein Gegenbeispiel angegeben.

Testfallableitung mit Temporallogik basiert auf dem Finden von Gegenbeispielen

Das Verfahren zur Testfallableitung auf Basis von Temporallogik ist eigentlich der formalen Verifikation zuzuordnen, da die Konsistenz zwischen einer Realisierung (hier: Zustandsautomat) und einer Spezifikation (ausgedrückt durch Temporallogik) mathematisch nachgewiesen wird. Für die Testfallableitung ist es möglich, die Eigenschaften so zu spezifizieren, dass die dazu ermittelten Gegenbeispiele interessante Testfälle darstellen. Beispielsweise kann spezifiziert werden, dass ein besonders sicherheitskritischer Zustand, der unerreichbar ist, in jedem Fall durchlaufen wird. Das Ergebnis sollte lauten, dass der Zustand nie erreicht wird. Das entsprechende Gegenbeispiel kann als Testfall verwendet werden. Als Beispiel wurde eine CTL-Spezifikation für die Getränkeautomatensteuerung verwendet mit den folgenden zu überprüfenden Eigenschaften: 1. A[] not deadlock

Es gilt für alle Zustände, dass es zu keinem Deadlock im System kommt. Damit gibt es immer eine Möglichkeit von jedem Zustand aus den Endzustand zu erreichen. Im Beispiel ist Bereit der Endzustand. Ergebnis: Eigenschaft erfüllt

224

6 Modellbasiertes Testen

2. Automat.Getränk_ausg → Automat.Gez_Betrag ≥ Automat.Preis

Es gilt immer, dass der eingezahlte Betrag gleich oder größer dem Getränkepreis war, falls ein Getränk ausgegeben wurde. Hier soll sichergestellt werden, dass immer ausreichend Geld eingezahlt werden muss, bevor das Getränk ausgegeben wird. Ergebnis: Eigenschaft erfüllt 3. E (Automat.Gez_Betrag < Automat.Preis and

Kunde.Getraenk_empfangen) Hier wird ein Beispiel gesucht, bei dem der eingezahlte Betrag kleiner oder gleich dem Preis ist und das Getränk ausgegeben wurde. Ergebnis: Eigenschaft nicht erfüllt. Gegenbeispiel: >

Getränk_eingeben (Tee)

>

Preis (Tee) = 200

>

Geld_eingeben (100)

>

Geld_zurückgeben

6.2.1.4

Markov-Ketten

Markov-Ketten sind Zustandsautomaten mit Übergangswahrscheinlichkeiten an den Transitionen. Sie werden zur probabilistischen Modellierung von Systemen eingesetzt (siehe Kapitel 14.4.4). Die Übergangswahrscheinlichkeiten sind je nach Art der Markov-Kette unterschiedlich spezifiziert. Diskrete Markov-Ketten (discrete time Markov chains, DTMC) haben diskrete Übergangswahrscheinlichkeiten. Sie beschreiben nur die Wahrscheinlichkeit, dass eine bestimmte Transition ausgeführt wird, jedoch nicht den Zeitpunkt. Kontinuierliche Markov-Ketten (continuous time Markov chains, CTMC) verfügen über Wahrscheinlichkeitsfunktionen an den Transitionen, die in Abhängigkeit von der Zeit die Wahrscheinlichkeit und den Zeitpunkt zur Ausführung der Transition beschreiben. Die Wahrscheinlichkeitsverteilungen in den Markov-Ketten sind gedächtnislos. Das heißt, dass das zukünftige Verhalten nur vom gegenwärtigen Zustand abhängt, jedoch nicht vom Weg, der in diesen Zustand genommen wurde.

Markov-Ketten sind Zustandsautomaten mit Übergangswahrscheinlichkeiten an den Transitionen

Im modellbasierten Testen werden Markov-Ketten für die Modellierung der Systemumgebung eingesetzt, die oft probabilistisch beschrieben werden kann. In den Markov-Ketten kann dadurch das operationale Profil des Testobjekts abgebildet werden (vgl. Kapitel 5.3). Da diese Modelle die Benutzung des Testobjekts durch dessen Umgebung darstellen, werden sie auch als Benutzungsmodelle (engl. usage models) bezeichnet. Benutzungsmodelle werden im Allgemeinen aus den Anforderungen erstellt, da diese beschreiben, wie, von wem und über welche Schnittstellen das Testobjekt benutzt wird. Benutzungsmodelle werden im modellbasierten statistischen Testen verwendet /Prowell et al. 99/.

Verwendung von Markov-Ketten für die probabilistische Modellierung der Systemumgebung

6.2 Beschreibung des modellbasierten Tests

225

Berücksichtigung des operationalen Profils für aussagekräftige Testfälle und Zuverlässigkeitsschätzungen

Durch die Berücksichtigung des operationalen Profils des Testobjekts können später die Testergebnisse für eine Zuverlässigkeitsprognose verwendet werden (vgl. Kapitel 14.5). Die Schwierigkeit liegt hier in der Ermittlung und Abbildung des operationalen Profils. Da Markov-Ketten aus Zuständen und Transitionen bestehen, können hier die bekannten Testfallgenerierungsverfahren für Zustandsautomaten angewendet werden. Zusätzlich dazu gibt es die Möglichkeit mit stochastischen Verfahren Testfälle anzuleiten, die der definierten Wahrscheinlichkeitsverteilung und damit dem operationalen Profil entsprechen. Als Beispiel wurde für die Steuerung des Getränkeautomaten ein Benutzungsmodell erstellt. Die Strukturen beider Modelle sind ähnlich. Das Benutzungsmodell beschreibt die möglichen Systemeingaben (Stimuli) und die daraufhin erwarteten Ausgaben (Testorakel). Es ist nicht im Allgemeinen nicht möglich, Bedingungen oder Transitionen ohne Ereignis aufzunehmen. Dadurch wurde die Transition, die für die Getränkeausgabe verantwortlich mit den beiden Transitionen der Becherausgabe verschmolzen. Die Bedingung bezüglich des eingezahlten Betrags wurde in zusätzliche Transitionen überführt. Es gibt nun die Transitionen Geld_eingezahlt (für Geld_eingezahlt und Gez_Berag < Preis) und Genug_Geld_eingezahlt (für Geld_eingezahlt und Gez_Berag ≥ Preis). Die Wahrscheinlichkeitsverteilung wurde willkürlich festgelegt und soll dem operationalen Profil eines typischen Kunden des Getränkeautomaten entsprechen.

Abbildung 6.6 Benutzungsmodell des Getränkeautomaten

Testfälle aus MarkovKetten = Zufallstests gemäß dem operationalen Profil

226

Abb. 6.6 zeigt das Benutzungsmodell des Getränkeautomaten mit den Systemeingaben und deren Wahrscheinlichkeiten. Die erwarteten Ausgaben wurden im Benutzungsmodell zur Vereinfachung nicht annotiert. Im Beispiel wurden 100 Testfälle zufällig gemäß dem operationalen Profil abgeleitet. Tab. 6.3 zeigt die Häufigkeit der Transitionen in der abgeleiteten

6 Modellbasiertes Testen

Testfallmenge. Diese wird direkt durch die definierten Wahrscheinlichkeiten festgelegt.

Tabelle 6.3 Häufigkeit der Transitionen

6.2.1.5

Prozesskalküle

Ein mit den Zustandsautomaten verwandter Formalismus sind Prozesskalküle. Allerdings werden nicht wie bei Zustandsautomaten Zustände und Transitionen als wesentliche Bestandteile betrachtet, sondern miteinander kommunizierende Prozesse. Einer dieser Prozesskalküle ist CSP (communicating sequential processes /Hoare 78/). Der betrachtete Getränkeautomat kann mittels CSP folgendermaßen dargestellt werden:

Prozesskalküle beschreiben ein System durch kommunizierende Prozesse

Geld={0..50} datatype Getraenketyp=WASSER|SAFT|KAFFEE datatype JN = JA|NEIN channel geld_zurueckgeben channel getraenk_ausgeben: Getraenketyp channel becher_ausgeben channel getraenk_waehlen: Getraenketyp channel preis_ermitteln: Getraenketyp channel preis_ermittelt: Geld channel betrag_anzeigen: Geld channel betrag_hinzufuegen: Geld channel geld_eingeben: Geld channel rueckgeld_auszahlen: Geld channel becher_waehlen: JN BEREIT = -> -> -> ->

getraenk_waehlen ? g preis_ermitteln ! g preis_ermittelt ? p betrag_anzeigen ! p GETRAENK_GEW(0,g,p)

6.2 Beschreibung des modellbasierten Tests

227

GETRAENK_GEW(gez_betrag, gew_getraenk, preis) = (getraenk_waehlen ? g -> preis_ermitteln ! g -> preis_ermittelt ? p -> betrag_anzeigen ! p -> GETRAENK_GEW(0,g,p)) [] (geld_eingeben ? b -> betrag_hinzufuegen ! b -> BETRAG_GET(gez_betrag+b, gew_getraenk, preis)) BETRAG_GET(gez_betrag, gew_getraenk, preis) = if gez_betrag >= preis then ZAHLUNG_AUSR(gez_betrag, gew_getraenk, preis) else (geld_eingeben ? b -> betrag_hinzufuegen ! b -> BETRAG_GET(gez_betrag+b, gew_getraenk, preis) [] geld_zurueckgeben -> rueckgeld_auszahlen ! gez_betrag -> BEREIT) ZAHLUNG_AUSR(gez_betrag, gew_getraenk, preis) = becher_waehlen ? x -> (if (x == JA) then becher_ausgeben -> BECHER_AUSG(gez_betrag, gew_getraenk, preis) else BECHER_AUSG(gez_betrag, gew_getraenk, preis)) [] geld_zurueckgeben --> rueckgeld_auszahlen ! gez_betrag -> BEREIT rueckgeld(gegeben, kosten) = if (gegeben >= kosten) then gegeben - kosten else 0 BECHER_AUSG(gez_betrag, gew_getraenk, preis) = getraenk_ausgeben ! gew_getraenk -> rueckgeld_auszahlen ! rueckgeld(gez_betrag, preis) -> BEREIT PREISGENERATOR = preis_ermitteln ?

Getraenk -> preis_ermittelt! 17 -> PREISGENERATOR

Diese Beschreibung wird so gelesen: Zunächst werden drei Datentypen und eine Menge von Kommunikationskanälen definiert. Jeder Kanal entspricht dabei einer Art von Ein- oder Ausgabenachricht an die Umgebung. Die meisten Kanäle können zusätzliche Daten in Verbindung mit den Nachrichten versenden. Die eigentliche Implementierung besteht aus einer Ansammlung einzelner Prozesse. Jeder Zustand des Automaten wir dabei durch einen Prozess dargestellt, beispielsweise durch „BEREIT“. Ein Prozess kann dabei zusammengesetzt werden aus einzelnen Kommunikationsschritten, durch Aufrufen anderer Prozesse, durch Auswahl zwischen den möglichen nächsten Schritten oder durch Parallelkompositionen von Prozessen. Beispielsweise bedeutet „betrag_anzeigen ! p -> GE-

228

6 Modellbasiertes Testen

TRAENK_GEW(0,g,p)“, dass auf dem Kanal „betrag_anzeigen“ eine Nachricht mit dem Wert der Variablen p verschickt wird und anschließend „GETRAENK_GEW“ mit den Parametern 0, g und p aufgerufen wird. Kommunikationsschritte mit einem „?“ beschreiben Empfang von Ereignissen, „[]“ bedeutet, dass von den es umschließenden Prozessen einer zur weiteren Ausführung ausgewählt wird, und „||“ bedeutet, dass die umschließenden Prozesse parallel ausgeführt werden sollen. Um Testfälle aus solchen Prozesskalkül-Ausdrücken abzuleiten, kann man diese Ausdrücke einige Schritte weit ausführen und dabei alle betrachteten Ein- und Ausgaben mitprotokollieren. Beispielsweise könnte man hier folgenden Testfall ermitteln (→ Eingabe, ← Ausgabe): → ← → ← → ← → ← → ← ←

getraenk_waehlen WASSER preis_ermitteln WASSER preis_ermittelt 17 betrag_anzeigen 17 geld_eingeben 10 betrag_hinzufügen 10 geld_eingeben 10 betrag_hinzufügen 10 becher_waehlen NEIN getraenk_ausgeben WASSER rueckgeld_auszahlen 3

Die systematische Ableitung von Testfällen aus Prozesskalküle erfolgt mit Hilfe von Model Checking. Ähnlich wie bei der Temporallogik werden Gegenbeispiele zu spezifizierten Eigenschaften gesucht, die interessante Aspekte im Testobjekt beschreiben.

6.3

Testfallableitung aus Prozesskalkülen basiert auch auf dem Finden von Gegenbeispielen

Bewertung des modellbasierten Tests

Das modellbasierte Testen umfasst Ansätze zur systematischen Erstellung von Testfällen aus Modellen heraus. Wie schon in der Einleitung des Kapitels beschrieben ist, lassen sich viele Testtechniken in den modellbasierten Test einordnen. Dadurch gelten für den modellbasierten Test auch die gleichen Aussagen. Das Einsatzgebiet für den modellbasierten Test hängt dabei von der Verfügbarkeit von geeigneten Modellen, den verwendeten Modelltypen und dargestellten Aspekten des Testobjekts ab. Je nach Modelltyp und der betrachteten Systemebene kann das Modell und die daraus angeleiteten Testfälle für den Modul-, Integrations-, oder Systemtest verwendet werden. Durch die Vielfalt von Modellen kann keine allgemein gültige Empfehlung ausgesprochen werden. Da in vielen Software-Entwicklungsprojekten Systemmodelle (z.B. Struktur- oder Verhaltensmodelle) erstellt werden, stellen diese einen guten Startpunkt dar. Diese Modelle sollten un-

6.3 Bewertung des modellbasierten Tests

Startpunkt für MBT sind verfügbare Modelle aus dem Systementwurf

229

tersucht werden, ob sie für die systematische Erstellung von Testfällen verwendbar sind. Im MBT sind Zustandsautomaten weit verbreitet

In der Praxis haben sich für Steuerungssysteme und -software verschiedene Arten von Zustandsautomaten als Modelle etabliert. Einige typische Vertreter wurden in diesem Kapitel vorgestellt. Die Verwendung von Vorund Nachbedingungen bietet sich an, wenn diese Bedingungen systematisch für die Aktionen im System bezüglich der relevanten Systemvariablen spezifiziert werden können. Bei einer großen Anzahl von Variablen und komplexen Systemstrukturen ist dieser Ansatz aufwändig. Der Aufbau von unabhängigen Testmodellen (beispielsweise Umgebungsmodelle) hat den Vorteil, dass von der Entwicklung unabhängige Artefakte für den Test erstellt werden und ohne eventuell begangene Fehler im Entwurf zu übernehmen. Jedoch ist dieser Ansatz auch mit entsprechendem Mehraufwand verbunden. Die anwendbaren Verfahren hängen wieder von den zugrunde liegenden Modellen ab. Eine kleine Auswahl von Testfallableitungstechniken wurden in diesem Kapitel vorgestellt, beispielsweise die Überdeckung der Graphenstruktur, der Bedingungen oder die Ableitung von Zufallstests. Die folgenden Quellen bieten einen guten Überblick über gegenwärtige Ansätze und Werkzeuge im modellbasierten Test: /Baker et al. 07/, /Braspenning 08/, /Broy et al. 05/, /Jacky et al. 08/, /Utting, Legeard 06/.

CHECKLISTE

230

>

Existiert eine Spezifikation, gegen die getestet werden soll?

>

Welche Systemmodelle wurden im Entwurf erstellt und können für den modellbasierten Test verwendet werden?

>

Überprüfung der Qualität und der Eignung der Modelle zur Testfallableitung (eventuell müssen Modelle verfeinert oder verändert werden)

>

Soll ein unabhängiges Testmodell verwendet werden? Falls ja, genügt die Spezifikation zur Erstellung des Testmodells?

>

Festlegung der Kriterien zur Testfallableitung in Abhängigkeit von dem verwendeten Modell

>

Wie wird das Testorakel für die Testauswertung erstellt? Können hierzu Informationen aus existierenden Modellen verwendet werden?

>

Existieren Werkzeuge für die Ableitung, Ausführung und Auswertung der modellbasierten Testfälle?

>

Wie werden die Testskripte aus den abgeleiteten Testfällen erstellt? Müssen dazu noch Adapter entwickelt werden?

6 Modellbasiertes Testen

7 Software-Messung Mit Messungen in der Software-Technik werden die gleichen Ziele verfolgt, die Messtechnik in anderen Anwendungsbereichen auszeichnen. Es sollen definierte Eigenschaften quantifiziert werden. Die in der Software-Entwicklung verbreiteten qualitativen Aussagen – z. B. dieses Software-Modul ist hinreichend getestet – sollen durch quantitative Aussagen – z. B. dieses Software-Modul besitzt eine Testabdeckung von 82 %, und unser Ziel besteht darin, mindestens 85 % Testabdeckung zu erreichen – ersetzt werden. Messwerte können z. B. Produkteigenschaften ausdrücken oder zur quantitativen Kontrolle und Steuerung von Software-Entwicklungsprozessen genutzt werden. Ferner können sie zur Prognose von nicht direkt messbaren Eigenschaften sowie zur Definition von prüfbaren Zielen verwendet werden. Ein bekanntes Zitat von Lord Kelvin aus den Popular Lectures and Addresses von 1889 bringt die Schwierigkeit des Umgangs mit nicht quantifizierter Information zum Ausdruck: „When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind.“ Der deutsche Physiker Max Planck (1858 – 1947) soll gesagt haben: „Was man messen kann, das existiert auch.“

Übersicht 7.1

Eigenschaften und Ziele der Software-Messung . . . . . . . . . . . . . 232

7.2

Maße und Metriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

7.3

Maßtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

7.4

Forderungen an Maße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

7.5

Maßskalen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

7.6

Datenerfassung für Maßsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

7.7

Zielgerichte Definition von Maßen . . . . . . . . . . . . . . . . . . . . . . . . . 245

7.8

Auswertung von Messungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

7.9

Wichtige Maße für Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

7.10

Fallstudie zur Software-Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

7.11

Bewertung der Software-Messung . . . . . . . . . . . . . . . . . . . . . . . . . 266 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

231

7.1 Ziel: Quantitativer Zugang zu Software

Eigenschaften und Ziele der Software-Messung

Die Definition von Software-Maßen basiert auf dem Wunsch, einen quantitativen Zugang zum abstrakten Produkt Software zu gewinnen. Dabei ist zwischen der Vermessung von Eigenschaften einer Software und der quantitativen Kontrolle des zugrundeliegenden Entwicklungsprozesses zu unterscheiden. In Abhängigkeit der Ziele können unterschiedliche Informationen interessant sein. Dementsprechend existieren sehr viele unterschiedliche Vorschläge für Maße. Ein Software-Manager benötigt andere Informationen als ein Qualitätssicherer, ein Programmierer oder ein Benutzer eines Programms. Maße ermöglichen z. B. einen quantitativen Vergleich unterschiedlicher Software-Produkte. Häufig liefern Messwerte erst im Vergleich mit Werten anderer bekannter Software-Produkte eine verwertbare Aussage. Außerdem kann jedes Maß nur einen begrenzten Bereich quantifizieren. Es ist „blind“ in anderen Bereichen und erfasst daher in keinem Fall die Eigenschaften einer Software als Ganzes. Ein verlässlicher Gesamteindruck kann nur durch Auswertung einer Gruppe von Maßen gewonnen werden. Messen ohne eine zielgerichtete Definition der anzuwendenden Maße und ihre systematische Auswertung ist zum Scheitern verurteilt. Ein Überblick zum Thema Messen von Software wird z. B. in /Fenton, Pfleeger 98/ und /Möller, Paulish 93/ gegeben. Die Bedeutung des Messens steigt mit dem ständigen Umfangs- und Komplexitätszuwachs der Software-Produkte. Umfangreiche Software-Entwicklungen können rein intuitiv auf Basis qualitativer Informationen weder erfolgreich durchgeführt, noch gesteuert und erst recht nicht optimiert werden. Aktuelle Trends unterstreichen die Bedeutung des Messens:

232

>

Moderne, flache Managementstrukturen fordern ein Maßsystem, das dem Manager Informationen automatisch zur Verfügung stellt und damit die geforderten größeren Führungsspannen ermöglicht. Der Trend im Bereich des Managements geht zu flacheren Strukturen. Ein Manager betreut erheblich mehr Entwickler als bisher. Die Bereitstellung und Verdichtung von Informationen geschieht nicht mehr durch das mittlere Management, sondern über automatisierte Maßsysteme. Eingriffe des Managements sind nur dann erforderlich, wenn Messwerte auf Problemsituationen hinweisen.

>

Das steigende Interesse an Software-Entwicklungsprozessen und die damit verbundenen Bewertungsverfahren unterstreichen die Wichtigkeit von Maßen zusätzlich. Das von vielen Firmen angewendete Software-Prozess-Assessment ordnet mit Hilfe eines so genannten Capability Maturity Models den Reifegrad eines Software-Entwicklungsprozesses z. B. in eine von fünf Stufen ein. Die möglichen Reifegrade sind z. B. 1-initial, 2-repeatable, 3-defined, 4-managed, 5-op-

7 Software-Messung

timizing. Die Erreichung der Reifegrade 4 und 5 ist im Prinzip nur bei Existenz und Nutzung eines umfassenden Maßsystems möglich, das die Messung von Produktivität und Qualität, die Bewertung von Projekten auf der Basis dieser Messungen, die Erkennung von Abweichungen, die Festlegung von Korrekturmaßnahmen im Falle von Abweichungen, die Identifikation und Beherrschung von Projektrisiken und die Prognose des Projektverlaufs und der Produktivität ermöglicht. >

Eine wesentliche Rolle spielt die Messtechnik im Zusammenhang mit Standards. Standards, z. B. die DIN ISO 9000-Normen, besitzen Bedeutung als Qualifikationsnachweis gegenüber Kunden. Sie gestatten die Abgrenzung gegenüber nicht vergleichbar ausgewiesenen Mitbewerbern. Ferner können sie im Rahmen der Produkthaftung wichtig sein, und sie sind in einigen Bereichen Voraussetzung zur Auftragserteilung. Alle Standards legen besonderen Wert auf eine systematische Vorgehensweise und die Transparenz und Kontrolle des Entwicklungsprozesses. Dies kann mit Hilfe entsprechender Maße nachgewiesen werden.

Verbreitete Einsatzbereiche für Maße sind: >

Kontrolle der Qualität

>

Kontrolle der Komplexität

>

Kontrolle und Operationalisierung des Software-Entwicklungsprozesses

>

Aufwands-, Kosten- und Zeitabschätzung

>

Aufwands-, Kosten- und Zeitverfolgung

>

Definition und Kontrolle der Einhaltung von Standards

>

Frühzeitige Problemidentifikation

>

Vergleich und Beurteilung von Produkten

>

Feedback bei der Einführung neuer Methoden, Techniken und Werkzeuge

7.2

Einsatzbereiche für Maße

Maße und Metriken

Das Wort Metrik entstammt dem Griechischen und bedeutet Kunst des Messens. In der Mathematik bezeichnet man als Metrik diejenige Struktureigenschaft eines metrischen Raums, durch die in ihm die Entfernung

7.2 Maße und Metriken

In der Software-Technik verwendet man Maße, keine Metriken.

233

zweier Punkte definiert ist. Die Grundlage bildet eine so genannte Maßbestimmung, die den Punkten Koordinaten zuordnet. Das Messen von Eigenschaften eines Systems ist in diesem Sinne als eine Maßbestimmung zu verstehen, da Objekten der realen Welt (z. B. einer Systemkomponente) Messwerte zugeordnet werden. Daher muss man korrekterweise im Zusammenhang mit den hier betrachteten Messungen von Maßen reden. Die Verwendung des Begriffs Metrik ist im Grunde falsch und wird von manchen Autoren korrekterweise abgelehnt (z. B. /Zuse 91, S. 29//. Eine Metrik kommt beim Vergleich zweier Objekte der Realität zustande. Sie gibt an, wie die Differenz zweier Objekte unter Verwendung der definierten Maßbestimmung zu ermitteln ist. Dies ist in der Regel die Motivation bei den hier betrachteten Messungen. Der Sinn des Messens ist ein Vergleich einer neuen Situation mit einer bereits bekannten Situation unter Verwendung eines bestimmten Maßes, um Analogieschlüsse zu ermöglichen. So kann z. B. ein Komplexitätsmaß (z. B. /McCabe 76/) gemeinsam mit Erfahrungswissen darüber, ab welchem Wert des Komplexitätsmaßes mit Schwierigkeiten zu rechnen ist, als Indikator verwendet werden, um komplexitätsreduzierende Maßnahmen einzuleiten. Im Prinzip werden in den hier betrachteten Situationen Maße immer im Sinne von Metriken gebraucht. In der Praxis ist es üblich, anstelle des Begriffs Maß den Begriff Metrik zu verwenden. Dennoch wird im folgenden der korrekte Begriff Maß verwendet.

7.3 Produktmaße vs. Prozessmaße

234

Maßtypen

Traditionell werden Produkt- und Prozessmaße unterschieden. Darüber hinaus ist die Berücksichtigung von Projektmaßen sinnvoll, die wichtige Informationen für die Projektsteuerung bereitstellen (Abb. 7.1). Produktmaße stellen Informationen über Eigenschaften eines Produkts (z. B. Komplexität, Umfang) bereit. Sie können z. B. zur Erkennung kritischer Produktteile und für die Einordnung und den Vergleich von Produkten verwendet werden. Prozessmaße erfassen Eigenschaften des Entwicklungsprozesses (z. B. Produktivität, Fehlerkosten). Sie dienen u.a. zur Kontrolle der ordnungsgemäßen Durchführung von Prozessschritten und zum Aufspüren von Problemen im Prozess, um Gegenmaßnahmen zu ermöglichen. In vielen Fällen ist es möglich, Maße auf ein Produkt, ein Projekt oder den Prozess zu beziehen. So ist z. B. die erreichte Testüberdeckung ein Produktmaß, falls sie für ein bestimmtes Produkt angegeben wird. In diesem Fall ist die erreichte Testüberdeckung eine Eigenschaft des Produkts. Legt ein Prozess einen Zielwert für die Testüberdeckung fest, der z. B. dazu dient, den Abschluss einer Testphase operational festzulegen, so kann die Testüberdeckung als Prozessmaß verstanden werden. Ferner kann die erreichte Testüberdeckungsrate bezogen auf den Zielwert zur Kontrolle des Projektfortschritts dienen. Das Maß kann in diesem Fall als Projektmaß betrachtet werden.

7 Software-Messung

Prozessmaße

Produktmaße Function Points

Durchschnittliche Produktivität

LOC Zyklomatische Zahl

Testüberdeckung TerminMittlere treue an FehlerfinProzessphasendungsrate der übergängen Code-Inspektion

Aktuell aufgelaufene Kosten geplante Kosten Projektmaße

Abbildung 7.1 Maßtypen

Maße können mehrere Bereiche involvieren. Ein typisches Beispiel ist das Function Point-Maß, dessen Ziel die Schätzung des Entwicklungsaufwands eines Produkts anhand seiner Funktionalität zu einem frühen Zeitpunkt ist. Dies kann z. B. auf Basis des Pflichtenhefts erfolgen. Im ersten Schritt wird der Umfang der zu realisierenden Funktionalität in Form so genannter Function Points ermittelt. Das Ergebnis dieses Schritts wird allein von dem zu entwickelnden Produkt bestimmt. Es handelt sich hier folglich um ein Produktmaß. Unter Verwendung eines Diagramms oder einer Tabelle, die den Function Points Entwicklungsaufwände zuordnet, wird in einem zweiten Schritt der erforderliche Entwicklungsaufwand ermittelt, der anschließend z. B. zur Angebotserstellung verwendet werden kann. Diese Umrechnungstabelle bzw. Dieses Umrechnungsdiagramm repräsentiert ein Prozessmaß, das ausdrückt, wie viel Entwicklungsaufwand der spezifisch verwendete Prozess erfordert, um eine bestimmte Menge an Funktionalität zu realisieren. Es ist leicht einzusehen, dass ein geeignetes Aufwandsschätzmaß Produkt- und Prozesseigenschaften beachten muss, da der erforderliche Entwicklungsaufwand von beiden Aspekten beeinflusst wird. Natürlich ist der Umfang des zu realisierenden Produkts ein entscheidender Faktor. Darüber hinaus ist zu erwarten, dass zwei Unternehmen, die den Auftrag erhalten, das gleiche Produkt zu entwickeln, unterschiedliche Entwicklungsaufwände benötigen werden. Dieser Aspekt wird durch die Umrechnungstabelle oder -kurve dargestellt, die den aktuellen Stand des Prozesses repräsentiert. Die Function Point-Methode involviert Produkt- und Prozessmaße. Sie ist daher ein hybrides Messverfahren.

7.3 Maßtypen

235

7.4 Eigenschaften von Maßen

Forderungen an Maße

Um Maße sinnvoll nutzen zu können, müssen folgende Voraussetzungen erfüllt sein: >

Einfachheit Ist das Ergebnis so einfach, dass es nur einen angemessenen Interpretationsaufwand erfordert?

>

Eignung (Validität) Ist das Maß zu der zu messenden Eigenschaft hinreichend stark korreliert?

>

Stabilität Ist der Wert des Maßes stabil gegenüber Manipulationen von untergeordneter Bedeutung?

>

Rechtzeitigkeit Kann das Maß bereits zu einem Zeitpunkt gebildet werden, der noch ein rechtzeitiges Einwirken auf das Produkt oder den Prozess gestattet?

>

Analysierbarkeit Können Messwerte in Relation zueinander gesetzt werden? Sind die Messwerte statistisch analysierbar? Neben einem numerischen Wertebereich als Voraussetzung für statistische Analysierbarkeit, ist der Skalentyp des Maßes entscheidend. Skalentypen werden in diesem Kapitel ebenfalls kurz diskutiert.

>

Reproduzierbarkeit Der Wert eines Maßes soll für ein bestimmtes Produkt unabhängig von der Art der Bildung einen identischen Wert besitzen. Reproduzierbarkeit setzt Objektivität voraus, d. h. es darf z. B. keine subjektive Einflussnahme durch den Messenden möglich sein. Ferner muss das Maß präzis definiert sein.

Dass diese Forderungen nicht selbstverständlich sind, zeigt z. B. die Eigenschaft Reproduzierbarkeit, die wesentlich von der Präzision der Maßdefinition bestimmt wird. Ist ein Maß präzis definiert, so ist es in der Regel unabhängig von der Art der Bildung reproduzierbar. Dies zeigt die Betrachtung einiger Beispiele. >

236

Für Kontrollflussgraphen (siehe Kapitel 8) ist McCabes zyklomatische Zahl als Komplexitätsmaß folgendermaßen definiert: Bezeichnet e (edges) die Anzahl der Kanten und n (nodes) die Anzahl der Knoten des Kontrollflussgraphen, so ist die zyklomatische Zahl z = e-n+2. Für einen gegebenen Kontrollflussgraphen ist diese Definition so präzis, dass das Maß vollständig reproduzierbar ist.

7 Software-Messung

>

Betrachtet man das Maß Lines of Code (LOC), so ist leicht zu erkennen, dass die Definition dieses Maßes keine vergleichbare Präzision erreicht. Es stellen sich folgende Fragen: Wie sind Leerzeilen zu zählen? Sollen Kommentarzeilen mitgezählt werden? Sollen mehrere Anweisungen in einer Zeile wie mehrere Zeilen oder wie eine Zeile gezählt werden? Definiert man Regeln für den Umgang mit derartigen Fällen, so ist auch der Wert des Maßes Lines of Code vollständig reproduzierbar.

>

Bei dem bereits erwähnten Maß Function Points ist die exakte Reproduktion von Werten nicht möglich. Die Anwendung der Function Point-Methode erfordert eine manuelle Bewertung von Komplexitäten durch Einordnung in eine der Kategorien einfach, mittel oder komplex. Da die Methode bereits auf Basis früher, unpräziser Beschreibungen eines geplanten Produkts anwendbar ist, existieren für die Zuordnung zu den Kategorien nur recht vage Regeln, die nicht verhindern können, dass in Grenzfällen zwei Personen unterschiedliche Zuordnungen wählen. Einerseits ist das Maß Function Points prinzipiell nicht vollständig reproduzierbar. Andererseits zeigt die Erfahrung, dass methodisch erfahrene Personen Ergebnisse erzeugen, deren Abweichungen für die Aufwandsschätzung toleriert werden können. Im Normalfall wird der Grad der Reproduzierbarkeit für die beabsichtigte Anwendung ausreichen.

>

Noch schlechter reproduzierbar sind Eigenschaften wie z. B. Verständlichkeit, für die nicht notwendig eine einheitliche Interpretation existiert. Hier verzichtet man oft auf die Definition von Maßen und zieht stattdessen eine manuelle Prüfung mit einer Gruppe von Personen in Form eines Reviews vor.

7.5

Maßskalen

7.5.1

Grundlagen

Wenn abstrakte Eigenschaften als Zahlenwerte ausgedrückt werden, so muss man prüfen, welche Operationen mit diesen Zahlenwerten bei ihrer Weiterverarbeitung sinnvoll sind. Zur Verdeutlichung dieser Aussage sollen zwei Situationen betrachtet werden.

Messung der Länge:

BEISPIEL

Brett a ist einen Meter lang. Brett b ist zwei Meter lang. Darum ist Brett b doppelt so lang wie Brett a. Diese Behauptung ist sinnvoll.

7.5 Maßskalen

237

Messung der Temperatur: Heute haben wir eine Temperatur von 20°C. Gestern haben wir 10°C gemessen. Also ist es heute doppelt so warm wie gestern. Das ist falsch. Die richtige Antwort ist: Heute ist es rund 3,5 % wärmer als gestern.

Offensichtlich gibt es einen Unterschied zwischen der Messung der Temperatur in °C und der Messung der Länge in Metern, der dazu führt, dass bestimmte Operationen auf die Temperaturskala in °C keine sinnvollen Aussagen liefern. In beiden Beispielen ist die Division verwendet worden. Eine Länge von 2 Metern dividiert durch eine Länge von einem Meter ergibt den Wert 2. 20°C dividiert durch 10°C ergibt ebenfalls 2. Welches Ergebnis würde man erhalten, wenn am Vortag -5°C gemessen worden wären? Wäre es dann heute -4 mal so warm wie gestern? Die Aussagen, die entstehen, wenn man Temperaturen auf der Celsius-Skala dividiert, sind unsinnig. Diese Operation ist auf der Celsius-Skala nicht erlaubt. Die Ursache ist der so genannte Skalentyp des Maßes Temperatur in °C. Während die Messung der Länge in Metern eine Rationalskala bildet, ist die Temperatur in °C nur als Intervallskala verwendbar. Auf Intervallskalen sind Divisionen nicht sinnvoll. Die Rationalskala für die Temperatur ist durch die Kelvin-Skala definiert, so dass die korrekte Verarbeitung der Temperaturmessung folgendermaßen durchgeführt werden muss: 20°C entspricht 293,15K. 10°C entspricht 283,15K. 293,15K dividiert durch 283,15K ergibt ungefähr 1,035. Skalentypen

Während die Temperatur einen physikalischen, leicht vorstellbaren Hintergrund besitzt, gilt dies für viele der hier betrachteten Maße nicht. Daher ist es wichtig, Verfahren zur Ermittlung des Skalentyps zu kennen. Insgesamt unterscheidet man die folgenden fünf Skalentypen, die aufeinander aufbauen. Jeder höhere Skalentyp besitzt alle Eigenschaften der einfacheren Skalentypen: >

Nominalskala: Freie Bezeichnung bestimmter Eigenschaften mit Markierungen –

>

238

Namen unterschiedlicher Software-Analysemethoden (SA, SA/RT, OOA, ...)

Ordinalskala: Abbildung eines geordneten Aspekts einer Eigenschaft auf eine geordnete Menge von Messwerten und zwar so, dass die Ordnung erhalten bleibt –

Abbildung des Eintreffens von Patienten auf die Behandlungsreihenfolge in einer Arztpraxis

–

Abbildung des Gewichts eines Risikos auf die Risikoprioritätszahl bei der FMECA (Failure Mode, Effects and Criticality Analysis; siehe Kapitel 14)

7 Software-Messung

>

Intervallskala: Eine Skala, die auch dann noch gültig ist, falls Transformationen g(x)=ax + b, mit a>0, auf sie angewendet werden. –

>

Rationalskala: Eine Skala in der Messwerte zueinander in Relation gesetzt werden können. Zulässige Transformationen haben die Form g(x)=ax, mit a>0. Prozentuale Aussagen über Messwerte sind sinnvoll. Es darf dividiert werden. – –

>

Temperaturskalen in Grad Celsius oder Fahrenheit. Falls F eine Temperatur auf der Fahrenheit-Skala ist, so kann die Temperatur C auf der Celsius-Skala folgendermaßen errechnet werden: C = 5/9 (F - 32) = 5/9 F - 160/9. Die Relationen zwischen Temperaturen bleiben erhalten.

Länge in Metern (Es ist doppelt so weit von a nach b wie von c nach d). Temperatur in Kelvin.

Absolutskala: Eine Skala, die die einzige Möglichkeit zur Messung des Sachverhaltes darstellt. – – –

Zählen Häufigkeiten Wahrscheinlichkeiten

Eine sehr ausführliche Darstellung von Skalendiskussionen ist in /Zuse 91/ enthalten. Dem an Skalendiskussionen interessierten Leser empfehle ich die Lektüre des genannten Buches. Im folgenden werden einige Definitionen angegeben und Grundlagen der Skalendiskussion erläutert. Die vermittelten Kenntnisse sind theorielastig, aber von großer Bedeutung für die Praxis. Wir betrachten im Folgenden die empirische Relation •≥. Es wird verlangt, dass sie eine so genannte schwache Ordnung auf der Menge der Module A bildet, also folgende Axiome erfüllt: >

Reflexivität: a •≥ a, ∀ a ∈ A Ein Beispiel für eine reflexive Relation ist die Identität „=“ auf jeder nicht leeren Menge.

>

Transitivität: a •≥ b, b •≥ c ⇒ a •≥ c, ∀ a, b, c ∈ A (Falls die Komplexität des Moduls a größer gleich der Komplexität des Moduls b ist und die Komplexität von b größer gleich der von c ist, so ist auch die Komplexität von a größer gleich der von c) Die Relation „ist Nachfahr von“ auf der Menge der Menschen ist ein Beispiel für eine transitive Relation. Jeder Mensch ist Nachfahr seiner Eltern, die Nachfahren ihrer Eltern sind. Daher ist jeder Mensch auch Nachfahr seiner Großeltern.

>

Konnexität (Vollständigkeit): a •≥ b oder b •≥ a, ∀ a, b ∈ A Die Relation „≥“ ist auf der Menge der Natürlichen Zahlen konnex.

7.5 Maßskalen

Schwache Ordnung

239

7.5.2

Skalendiskussion

Im Folgenden wird die Eigenschaft „Komplexität“ betrachtet. Für die Software-Module a und b werden die binären Relationen •≥ (komplexer oder gleich komplex), •> (komplexer) und •≈ (gleich komplex), die auf die Module angewendet werden können, als empirische Relationen bezeichnet. Die intuitive Idee von Komplexität, so wie sie Menschen entscheiden würden, bestimmt die empirische Relation. Es sei A die Menge aller Software-Module, mit a, b, c ∈ A. Man schreibt: >

a •> b; (a ist komplexer als b)

>

a •≈ b; (a ist genauso komplex wie b)

>

a •≥ b ⇔ a •> b oder a •≈ b;

7.5.2.1 Ordinalskalen bilden Eigenschaften „richtig herum ab“.

Die Ordinalskala

Ordinalskalen zeichnet die Eigenschaft aus, dass sie die Relation der Eigenschaften zweier Objekte unter Beibehaltung ihrer Orientierung auf die Messwerte abbildet. Die empirische Relation bezüglich der Eigenschaften wird auf eine entsprechende formale Relation der Messwerte abgebildet. Falls die Axiome Reflexivität, Transitivität und Konnexität für die empirische Relation •≥ bezüglich A gültig sind, so existiert eine Ordinalskala (Abb. 7.2): ((A, •≥), (R, ≥), f), mit a •≥ b ⇔ f(a) ≥ f(b), ∀a, b ∈ A (A, •≥) ist das empirische relationale System (Module und ihre empirisch bewertete Relation). (R, ≥) ist das formale relationale System (Die (numerischen) Werte der Maße als reelle Zahlen und die entsprechende formale Relation ≥). f ist ein Maß. Messung

A R 0

³ a · b

Empirisches relationales System

Messung

f(b) £ f(a)

Formales relationales System

Abbildung 7.2 Die Ordinalskala

240

7 Software-Messung

7.5.2.2

Die Rationalskala

Eine Rationalskala muss alle Kriterien einer Ordinalskala erfüllen. Das empirische und formale rationale System muss folgendermaßen erweitert werden: ((A, •≥, °), (R, ≥, +), f), mit a •≥ b ⇐⇒ f(a) ≥ f(b) (Ordinalskala) und f(a ° b) = f(a) + f(b), (Rationalskala) ∀a, b ∈ A

Rationalskalen sind additiv.

° ist eine binäre Operation für das empirische relationale System. + ist die entsprechende binäre Operation für das formale relationale System (Abb. 7.3). Messung

A a° b

R

Messung

0

a · ³ b

Empirisches relationales System

Messung

f(b) £ f(a) f(a° b)=f(a)+f(b)

Formales relationales System

Abbildung 7.3 Die Rationalskala

Ein Maß f: A → R , das die oben angegebene Forderung der Rationalskala erfüllt, existiert genau dann, wenn folgendes gilt: >

(A, •≥) erfüllt die Axiome Reflexivität, Transitivität und Konnexität.

>

a ° (b ° c) •≈ (a ° b) ° c, ∀a, b, c ∈ A (Assoziativität) Die Assoziativität verlangt, dass die Reihenfolge der Verknüpfung mehrerer Module keinen Einfluss auf die betrachtete Eigenschaft der Ergebnisse besitzt.

>

a •≥ b ⇔ a ° c •≥ b ° c ⇔ c ° a •≥ c ° b , ∀a, b, c ∈ A (Monotonie) Die Monotoniebedingung fordert, dass sich die empirische Relation zwischen zwei Modulen durch die Verknüpfung beider Module mit einem beliebigen dritten Modul nicht verändern darf.

>

Falls c •> d, so gilt: ∀a, b ∈ A, ∃n ∈ N, a ° nc •≥ b ° nd (Archimedisches Axiom) Das Archimedische Axiom fordert, dass zwischen zwei beliebig aber fest gewählten Modulen keine unendliche Differenz der betrachteten Eigenschaft existieren darf. Jeder Komplexitätsunterschied zwischen

7.5 Maßskalen

241

zwei Modulen a und b kann durch n-fache Akkumulation der (kleinen) Komplexitätsdifferenz zwischen c und d kompensiert werden. 7.5.2.3 Definition der empirischen Relation

Lines of Code: Elementare Modifikationen

Die empirische Relation

Da die empirische Relation •≥ in der Definition der Skalen verwendet wird, ist es erforderlich, sie genau festzulegen. Eine generelle Definition ist nicht möglich, da die empirische Relation eine intuitive Idee von Komplexität widerspiegelt. Daher wird sie mit Hilfe so genannter kleiner Modifikationen an einem zu messenden Objekt definiert, indem man sich überlegt, ob diese Modifikationen zu einer erhöhten, verringerten oder identischen Komplexität führen. Betrachten wir das Maß Lines of Code (LOC) als Beispiel. Wir analysieren die folgenden elementaren Modifikationen eines vorgestellten Messobjekts: Modifikation 1: Codezeile hinzufügen Modifikation 2: Codezeilen vertauschen Modifikation 3: Codezeile verschieben Wir bezeichnen das unmodifizierte Messobjekt mit a und die jeweils durch die elementaren Modifikationen veränderten Messobjekte mit b. Wir betrachten LOC als Umfangsmaß. Aufgrund unserer Vorstellung der zu messenden Sachverhalte treffen wir die folgenden Entscheidungen: Die Modifikation 1 erhöht die Komplexität des modifizierten Moduls b gegenüber a, während die Modifikationen 2 und 3 eine identische Komplexität erzeugen. Wir haben die empirische Relation •≥ auf diese Weise für das Maß LOC definiert. Der nächste Schritt ist die Prüfung, wie das Maß LOC auf die Modifikationen reagiert: M1: a •≥ a ⇒ LOC (b) > LOC (a) M2: b •≈ a ⇒ LOC (b) = LOC (a) M3: b •≈ a ⇒ LOC (b) = LOC (a) Die Wirkungen der Modifikationen auf das Maß LOC entspricht der aufgrund der elementaren Modifikationen erforderlichen Wirkung. Falls diese Eigenschaften der Modifikationen 1 bis 3 akzeptiert werden, so erfüllt LOC die Kriterien der Ordinalskala. Die Messwerte können als Ordinalskala verwendet werden. Das Maß LOC erfüllt außerdem die Axiome Assoziativität, Monotonie und das Archimedische Axiom, falls als binäre Operation ° die textuelle Verkettung verwendet wird. Ferner gilt für zwei beliebige Module a und b: LOC (a ° b) = LOC (a) + LOC (b) (additiv) Die Werte des Maßes LOC können in Bezug auf die vereinbarte Operation ° als Rationalskala verwendet werden.

242

7 Software-Messung

Betrachten wir als weiteres Beispiel die zyklomatische Zahl. Sie ist für eine Anzahl p von Kontrollflussgraphen definiert als: Z = e − n + 2p, mit e = Anzahl der Kanten, n = Anzahl der Knoten, p = Anzahl der betrachteten Kontrollflussgraphen

Zyklomatische Zahl: Elementare Modifikationen

Für einen einzelnen Kontrollflussgraphen gilt p = 1, also : Z = e − n + 2 Führen wir eine Skalendiskussion für das Maß Z. Zur Prüfung, ob Z als Ordinalskala verwendet werden kann, müssen wir die für unserer Verständnis der empirischen Relation relevanten elementaren Modifikationen untersuchen. Dies seien: Modifikation 1: Einen Knoten und eine Kante hinzufügen Modifikation 2: Eine Kante verschieben Modifikation 3: Eine Kante hinzufügen Bezeichnen wir mit a das unmodifizierte Modul und mit b die jeweils modifizierten Module, so gilt mit unserer Bewertung der empirischen Relation: Modifikation 1: b •≈ a ⇒ Z(b) = Z(a) Modifikation 2: b •≈ a ⇒ Z(b) = Z(a) Modifikation 3: b •> a ⇒ Z(b) > Z(a) In Bezug auf die angegebenen Modifikationen gilt b •≥ a ⇒ Z(b) ≥ Z(a); d. h. die Werte können als Ordinalskala verwendet werden. Die Prüfung der Rationalskala erfordert die Festlegung einer betrachteten Verknüpfungsoperation für Kontrollflussgraphen. Wählen wir als Verknüpfungsoperation ° die Sequenz, die den Endeknoten eines Kontrollflussgraphen über eine zusätzliche Kante mit dem Startknoten eines anderen Kontrollflussgraphen verbindet. Wie das Beispiel in Abb. 7.4 zeigt, erfüllt Z nicht die Bedingung der Additivität bezüglich der Operation °, d. h. Z(a) + Z(b) = Z(a°b). Die Werte des Maßes Z können bezüglich der Operation ° (Sequenz) nicht als Rationalskala verwendet werden. Andererseits erfüllt Z die erforderlichen Axiome für die Rationalskala. Also muss ein Maß Z  existieren, das additiv ist: Z  = Z − 1 = e − n + 1. Dieses Maß Z  kann bezüglich der betrachteten Verknüpfungsoperation als Rationalskala verwendet werden (Abb. 7.4).

7.5 Maßskalen

243

Abbildung 7.4 Diskussion der zyklomatischen Zahl

7.6

Datenerfassung für Maßsysteme

Es ist sinnvoll, viele Informationen werkzeugunterstützt zu erfassen.

Maße sind direkt zählbare, errechnete oder bewertete Größen, eventuell auch eine entsprechende Kombination. Es müssen Eingangsgrößen (Primärdaten) für die Bildung der Maße erhoben werden. Nicht alle Primärdaten können direkt automatisch, z. B. aus dem Quellcode ermittelt werden. Zum Teil ist es erforderlich, Primärdaten manuell zu erfassen oder mit Erfahrungswissen aus dem Zusammenhang zu schließen. Vorteilhaft ist, möglichst viele der erforderlichen Informationen automatisch, werkzeugunterstützt zu erfassen. Dies reduziert den Aufwand für die Messung.

Seiteneffekte müssen erfasst werden.

Oft ist es erforderlich, neben den vermuteten primären Einflussgrößen auch Seiteneffekte mit zu erfassen, um entsprechende Korrekturen zu ermöglichen. Viele Maße vermessen nicht ausschließlich eine Eigenschaft, sondern werden durch mehrere Eigenschaften beeinflusst. Wird z. B. die MTBF als ein Maß für die Zuverlässigkeit eines Systems benutzt, so wird dieser Zusammenhang bei alleiniger Auswertung von Ausfallstatistiken verzerrt. Da normalerweise während des Beobachtungszeitraums die Anzahl der betriebenen Systeme nicht konstant ist, ist den statistisch verteilten Ausfallzeitpunkten ein Einfluss durch die schwankende Anzahl der betriebenen Systeme überlagert, so dass die Wahrscheinlichkeit, in einem betrachteten Zeitintervall einen Ausfall zu beobachten, fällt oder steigt.

MTBF: Siehe Abschnitt 7.9.5

Die Anzahl der im Markt befindlichen Versionen wird bei einem neuen System nach seiner Markteinführung ansteigen. Dies erhöht natürlich

244

7 Software-Messung

die Wahrscheinlichkeit, in einem bestimmten Zeitintervall ein Fehlverhalten zu beobachten. Falls Fehler parallel dazu korrigiert werden, so ist es möglich, dass trotz der steigenden Zuverlässigkeit Fehlverhalten häufiger beobachtet werden. Größere Modifikationen, z. B. neue Versionen mit einem erweiterten Funktionsumfang und Portierungen, führen in der Regel zu einem weiteren Anstieg der Ausfallwahrscheinlichkeit. Die Konsequenz ist, dass maßgebliche Einflussgrößen, die als Seiteneffekte gewertet werden, erfasst werden müssen, um sie in dem Auswertemodell beachten zu können. In dem angegebenen Beispiel sind dies z. B. die Installationszahlen des Systems, mit deren Hilfe die MTBF auf jeweils eine installierte Version bezogen werden kann. Ferner sind wichtige Ereignisse, z. B. Versionssprünge und Portierungen, zu notieren.

7.7

Zielgerichte Definition von Maßen

Es ist wesentlich, Maße in bezug auf bestimmte zu erreichende Ziele zu definieren. Ein bekannter Ansatz zur zielgerichteten Definition von Maßen ist die GQM-Methode /Basili, Rombach 88/. Im Grunde sieht GQM eine „Top-Down“-Identifikation geeigneter Maße vor. Es sind drei Fragen zu beantworten:

GQM

1. Welches Ziel soll durch die Messung erreicht werden (Goal)? 2. Welche Fragen müssen beantwortet werden können, um das Ziel zu

erreichen (Question)? Oder anders formuliert: Was muss gemessen werden, d. h. welche Eigenschaften eines Produkts oder eines Prozesses sollen erfasst werden? 3. Wie kann das gemessen werden, d. h. welche Maße sind in der Lage,

die benötigten Eigenschaften möglichst frei von Seiteneffekten zu erfassen (Metric)? Ein Beispiel für die Definition von Maßen, deren Ziel die Bereitstellung von Informationen für die Auswahl optimaler Prüftechniken ist, wird in /Liggesmeyer 95/ beschrieben.

7.8

Auswertung von Messungen

Maße sind nutzlos und aufgrund des erforderlichen Aufwands für die Erhebung der Daten sogar schädlich, solange nicht sinnvolle Schlussfolgerungen auf Basis der Messwerte möglich sind. Die korrekte Bewertung und Interpretation von Messwerten ist außerordentlich wichtig für den Erfolg eines Messprogramms und wird in der Praxis leider oft vernachlässigt. Eine einheitliche Empfehlung von unteren und oberen Grenzen

7.8 Auswertung von Messungen

Messen ohne geeignete Datenauswertung ist sinnlos.

245

für ein bestimmtes Maß ist schwierig. Im Grunde ist nicht zu erwarten, dass identische Grenzwerte eines Maßes über alle Anwendungsgebiete hinweg gültig sind. Vielmehr muss z. B. mit Erfahrungswissen ermittelt werden, welche Werte als normal und welche als nicht tolerierbare Abweichungen anzusehen sind. Und auch dann gilt, dass eine Abweichung von üblichen Werten ein Hinweis auf ein Problem sein kann, aber keineswegs sein muss. Statistische Verfahren zur Interpretation von Messreihen sind in der Fertigung etabliert. Sie bilden die Basis für die statistische Qualitätskontrolle von Fertigungsprozessen und gestatten die Definition so genannter Prüfpläne.

Empirisches Modell Quadratische Abhängigkeit: Siehe Abschnitt 7.9.2

In den meisten Fällen ist nicht der Wert eines Maßes die interessierende Eigenschaft, sondern eine andere Eigenschaft, von der man annimmt, dass sie mit dem Maß korreliert ist (siehe z. B. /Robillard et al. 91/). Die Zuordnung zwischen Messwerten und den relevanten Eigenschaften ist schwierig (Abb. 7.5). Sie erfordert viel Erfahrungswissen oder geeignete systematische Auswertemodelle. Statistische Techniken zur Ermittlung derartiger Modelle werden in diesem Kapitel vorgestellt. Die Modellbestimmung erfolgt auf Basis von Beobachtungen, die sich z. B. auf bereits abgeschlossene, vergleichbare Projekte beziehen. Daher handelt es sich um empirische Modelle. Man kann empirische und theoretische Modelle unterscheiden. So basieren z. B. die bekannten Halstead-Maße /Halstead 77/ auf theoretischen Modellen. Aufgrund theoretischer Betrachtungen hat Halstead z. B. eine quadratische Abhängigkeit des erforderlichen Ent-

Abbildung 7.5 Auswertung von Messungen

246

7 Software-Messung

wicklungsaufwands E (effort) vom Umfang eines Software-Produkts postuliert (E = c · Umfang2 ). Eine Kalibrierung kann hier zur Bestimmung der Proportionalitätskonstanten c dienen. Während bei theoretischen Modellen eine Hypothese vorliegt, die beschreibt, warum der Zusammenhang zwischen Maßen und der interessierenden Eigenschaft zustande kommt, ist bei empirischen Modellen ausschließlich eine Beschreibung des Zusammenhangs gewünscht, ohne Aussagen über die Ursachen zu erhalten. Bei empirischen Modellen kann man aufgrund des höheren Freiheitsgrads oft eine bessere Approximation erreichen.

Theoretisches Modell

Auch hier existieren Mischformen. Die bereits als Beispiel angeführte Function Point-Methode involviert sowohl theoretische als auch empirische Ansätze. Die Komplexität der Funktionalität wird mit Hilfe theoretischer Überlegungen auf unterschiedlich komplexe Teilfunktionen zurückgeführt. Einer „einfachen Eingabe“ werden 3 Function Points zugeordnet. Einer „mittleren Eingabe“ werden 4 Function Points zugeordnet, und für eine „komplexe Eingabe“ werden 6 Function Points vergeben. Analog wird mit anderen Werten für Ausgaben, Abfragen, Datenbeständen und Referenzdaten verfahren. Dieser Schritt ist ein theoretischer Ansatz. Im Gegensatz dazu ist die Abbildung von Function Points auf den Entwicklungsaufwand mit Hilfe der empirisch erzeugten Tabellen oder Kurven ein empirischer Schritt. Die Function Point-Methode besitzt also sowohl einen empirischen als auch einen theoretischen Charakter (Abb. 7.6).

Abbildung 7.6 Die Function Point-Methode

7.8.1

Darstellung von Messwerten

Messwerte werden in der Praxis häufig grafisch dargestellt. Die verfügbaren Messwerkzeuge bieten oft verschiedene Darstellungsmöglichkeiten. Neben Grafiken sind tabellarische Darstellungen üblich. Grafiken bieten den Vorteil der größeren Übersichtlichkeit. Eine große Menge von Informationen kann auf einen Blick wahrgenommen werden. Ungewöhnliche Werte („Ausreißer“) sind leicht zu erkennen. Nachteilig ist, dass die Ablesung genauer Messwerte in Grafiken kaum möglich ist. Falls eine genaue Messwertablesung zwingend erforderlich ist, können Grafiken mit den Messwerten beschriftet werden. Tabellarische Darstellungen gestatten die kompakte Darstellung vieler Messwerte. Nachteilig ist ihr häufig gegebener Mangel an Übersichtlichkeit. Daher ist ein Wechsel zwi-

7.8 Auswertung von Messungen

Grafiken vs. Tabellen

247

schen grafischen und tabellarischen Darstellungen oft erwünscht und auch sinnvoll. Zur Darstellung von Software-Messwerten werden all jene grafischen Darstellungen verwendet, die auch in anderen Bereichen der Messtechnik Verwendung finden. Neben allen denkbaren Arten von Balken-, Linien- und Flächendiagrammen, die sowohl in zwei- wie auch in dreidimensionaler Form verwendet werden, wird insbesondere zur Darstellung von Software-Messwerten das so genannte Kiviat-Diagramm verwendet. Dieses Diagramm wird im Folgenden näher beschrieben. Kiviat-Diagramme

Kiviat-Diagramme gestatten die übersichtliche Darstellung der Werte unterschiedlicher Maße für eine bestimmte Betrachtungseinheit. Ein typischer Einsatzfall eines Kiviat-Diagramms ist die Darstellung der zyklomatischen Zahl, des Maßes Life Variables, des Umfangsmaßes Lines of Code und weiterer Maße für ein bestimmtes betrachtetes Modul. KiviatDiagramme verwenden Strahlen, auf denen die Messwerte abgetragen werden. Die Anzahl der Strahlen entspricht der Anzahl der unterschiedlichen verwendeten Maße. Alle Strahlen beginnen in einem gemeinsamen Punkt, dem Zentrum des Kiviat-Diagramms (Abb. 7.7). Falls für jedes Maß Minimal- und Maximalwerte festgelegt worden sind, so können diese Werte in das Kiviat-Diagramm mit eingezeichnet werden. Jeder Strahl wird so in drei Bereiche unterteilt: den Normalbereich, den Bereich zu kleiner und den Bereich zu großer Werte. Verbindet man alle Minimalwerte sowie alle Maximalwerte durch Linien, so erhält man drei Flächen in der Ebene, die zu kleine Messwerte, „normale“ Messwerte und zu große Messwerte charakterisieren. In Abb. 7.7 sind die zu kleinen Werte durch die zentrale graue Fläche charakterisiert. Die zu großen Werte finden sich in der grauen außenliegenden Fläche. Der dazwischen liegen-

Abbildung 7.7 Kiviat-Diagramm

248

7 Software-Messung

Abbildung 7.8 Kiviat-Diagramm mit einem zu hohen Wert der zyklomatischen Zahl

de weiße Bereich entspricht den Normalwerten. Verbindet man die auf den Strahlen aufgetragenen Messwerte, so erhält man einen Linienzug, der den Bereich der normalen Messwerte nicht verlassen darf. Er darf die Linienzüge, die die Minimal- und Maximalwerte verbinden, nicht schneiden. Das Diagramm nach Abb. 7.7 stellt daher ein Modul mit akzeptablen Messwerten dar. Das Diagramm nach Abb. 7.8 stellt eine Situation dar, in der vier der Messwerte im Normalbereich liegen. Der fünfte Messwert – die zyklomatische Zahl – besitzt einen zu hohen Wert. Dieser Sach-

Abbildung 7.9 Kiviat-Diagramm eines komplexen Moduls

7.8 Auswertung von Messungen

249

Abbildung 7.10 Kiviat-Diagramm eines einfachen Moduls

verhalt ist bei Betrachtung des Diagramms unmittelbar zu erkennen. Kiviat-Diagramme ermöglichen zusätzlich eine direkte Einschätzung von Modulen durch Bewertung des Verlaufs des Linienzuges, der sich durch Verbinden der Messwerte ergibt, mit den Linienzügen, die den Normalbereich von den kritischen Bereichen trennen. Abb. 7.9 stellt ein Kiviat-Diagramm eines in jeder Hinsicht komplexen Moduls dar. Der Linienzug der Messwerte verläuft für jeden Messwert dicht an der Grenze des äußeren Bereichs, d. h. an der Grenze zu unakzeptabel hohen Messwerten. Abb.

Abbildung 7.11 Kiviat-Diagramm eines Moduls mit hoher Kontrollkomplexität und geringer Datenkomplexität

250

7 Software-Messung

7.10 stellt die gegenteilige Situation dar. Es handelt sich hier um ein Kiviat-Diagramm eines in jeder Hinsicht einfachen Moduls. Der Linienzug der Messwerte verläuft dicht in der Nähe des inneren grauen Bereichs, d. h. in der Nähe der Minimalwerte. Darüber hinaus können Kiviat-Diagrammen auch relativ unkompliziert unterschiedliche Profile entnommen werden. Abb. 7.11 stellt ein Kiviat-Diagramm eines Moduls mit hoher Kontrollkomplexität und geringer Datenkomplexität dar. Das Modul ist umfangreich und besitzt eine hohe zyklomatische Zahl. Es enthält also viele Entscheidungen. Die Maße Life Variables und Variablenspanne weisen kleine Werte auf. Die Datenkomplexität ist daher gering. Der wesentliche Vorteil der Kiviat-Diagramme ist die Möglichkeit der Beurteilung einer Betrachtungseinheit anhand einer größeren Zahl von Messwerten „auf einen Blick“. Nachteilig ist, dass für jedes Maß Minimal- und Maximalwerte explizit festgelegt werden müssen. Wechselwirkungen zwischen den Messwerten und den Grenzen sind nicht beschreibbar. Diese Einschränkung ist in der Praxis oft nicht akzeptabel. Man wird für ein Modul, das in allen Messwerten außer in einem Messwert geringe Werte aufweist, eher bereit sein, höhere Werte für die komplexe Eigenschaft zu tolerieren, als bei einem Modul, das bei allen Eigenschaften relativ hohe Komplexitäten aufweist. Komplexitäten treten in Wechselwirkung. Diese Wechselwirkung ist in Kiviat-Diagrammen nicht beschreibbar.

7.8.2

Kiviat-Diagramme können Wechselwirkungen zwischen Maßen nicht erfassen.

Auswertung mit Erfahrungswissen

Oft sind in der Software-Entwicklung die interessierenden Eigenschaften nicht direkt messbar. So existiert z. B. keine direkte Möglichkeit, den Fehlergehalt durch Messungen im Quellcode festzustellen. Die Fehler liegen im Quellcode vor. Es existiert jedoch keine direkte Möglichkeit, sie messtechnisch zu erkennen. Eine andere nicht direkt messbare Eigenschaft ist die Zuverlässigkeit einer Software, die durch den zeitlichen Eintritt von Fehlverhalten als Wirkung von Fehlern eintritt. Darüber hinaus ist Zuverlässigkeit zeitlich veränderlich. Nachdem eine Software ausgeliefert und über eine ausreichend lange Zeitspanne im Feld genutzt worden ist, können mit statistischen Verfahren aus den Ausfallzeitpunkten Zuverlässigkeitsaussagen abgeleitet werden. Oft möchte man Zuverlässigkeitsaussagen aber bereits zu einem frühen Zeitpunkt erhalten, um bei erwarteten Problemen Gegenmaßnahmen ergreifen zu können. Zwei Ursachen für die fehlende Messbarkeit von Eigenschaften sind die fehlende Möglichkeit, die Eigenschaft an messbaren Merkmalen festzumachen, und zeitliche Aspekte. Im zweiten Fall ist die Eigenschaft grundsätzlich messbar, aber erst zu einem Zeitpunkt, der keinen sinnvollen Eingriff mehr erlaubt. In beiden Situationen ist es erforderlich, von messbaren Größen auf die eigentlich interessierenden Eigenschaften zu schließen. Das Ziel ist die Erstellung einer Prognose, die dazu dient, auf Basis der prognostizierten Situation Handlungsanweisungen abzuleiten. In der Praxis wird dieser Schritt noch häufig manuell vollzogen. Die Auswer-

7.8 Auswertung von Messungen

Nicht direkt messbare Eigenschaften

251

Plausibilitäten sind oft problematisch.

Qualitätsaussagen auf Basis von Komplexitätseigenschaften

Die Realität ist multikausal.

252

tung von Messungen basiert in diesem Fall auf nicht systematisch repräsentiertem Erfahrungswissen. Dies folgt oft einfachen, plausiblen, aber in der Regel unbewiesenen Regeln. Derartige Regeln können wahr sein. Dies ist aber nicht garantiert. Falls Prognoseregeln angewendet werden, die unwahr sind, existiert die Gefahr, dass aufgrund entsprechend fehlerhafter Prognosen unnötige Schritte unternommen werden bzw. nötige Eingriffe unterbleiben. Eine derartige implizite Regel könnte z. B. lauten: Wenn der Umfang von Modulen gemessen in Lines of Code zunimmt, so nimmt auch der Fehlergehalt, ausgedrückt als Fehler pro Line of Code, zu. Dieser Regel könnte die Erwartung zugrunde liegen, dass bei umfangreichen Modulen zwischen verschiedenen Modulteilen Wechselwirkungen existieren, die ein überproportionales Ansteigen des Fehlergehalts bewirken. Auf den ersten Blick scheint diese Annahme plausibel zu sein. Es gibt jedoch empirische Untersuchungen, die einen genau gegenteiligen Effekt zeigen /Basili, Perricone 84/ bzw. die Annahme zumindest nicht bestätigen /Fenton, Ohlsson 00/. Prognosen sind typischerweise für Qualitätsmerkmale auf Basis von Komplexitätseigenschaften gewünscht. Die Ursache für derartige Prognosen ist die gute Messbarkeit diverser Komplexitätseigenschaften im Softwareu-Qellcode und die kaum gegebene Messbarkeit von Qualitätseigenschaften. Daher wird oft versucht, Qualitätseigenschaften auf Basis von Komplexitätsmaßen zu bewerten. Die Erfahrung zeigt, dass dies jedoch ohne systematische Hilfsmittel allein auf Basis von Erfahrungswissen nicht verlässlich möglich ist. Eine wesentliche Ursache der Schwierigkeiten scheint die komplexe Wechselwirkung zwischen Einflussgrößen und davon abhängigen Eigenschaften zu sein. Dies soll am Beispiel der Zuverlässigkeit im Feldbetrieb erläutert werden. Es ist zu erwarten, dass die Zuverlässigkeit eines Software-Produkts von zahlreichen Einflussfaktoren abhängt. Hohe Komplexitäten in den frühen Phasen der Software-Entwicklung – d. h. in der Analyse und im Entwurf sowie in der Programmierung – lassen erwarten, dass entsprechend viele Fehler entstanden sein werden, die zuverlässigkeitsmindernd wirken. Sorgfältig durchgeführte Prüfungen – z. B. Inspektionen und Tests – werden fehlerreduzierend wirken, so dass bei Freigabe ein bestimmter Fehlergehalt existiert, der im Betrieb zu Fehlverhalten führt, das letztlich die Zuverlässigkeit beeinflusst. Um eine verlässliche Prognose der Zuverlässigkeit zu erreichen, müssten diverse Komplexitätsmaße für die verschiedenen Entwicklungsphasen und einige Maße für die Qualität der Prüfungen verwendet werden und zusammen einer Prognose der Zuverlässigkeit zugrundegelegt werden. Diese multikausale Betrachtungsweise, bei der viele Eigenschaften gemeinsam eine andere Eigenschaft beeinflussen, fällt Menschen erfahrungsgemäß schwer. In der Praxis findet man daher oft eine rein monokausale Sicht. Es wird versucht, aus der Betrachtung von Werten eines einzelnen Maßes Aussagen abzuleiten. Es ist zu erwarten, dass diese Herangehensweise oft nicht erfolgreich sein wird.

7 Software-Messung

7.8.3

Auswertung mit statistischen Techniken

Statistik ist der formale Weg für den Umgang mit unvollständigem Wissen. Erfahrungswissen beruht stets auf einer Menge von Einzelerfahrungen, aus denen implizit Regeln extrahiert werden. Die Nutzung von Erfahrungswissen ist dann kritisch, wenn die Regeln so kompliziert sind, dass sie von Menschen zur unkomplizierten Benutzung vereinfacht werden. Die durch Anwendung derartiger Erfahrungsregeln gewonnenen Erkenntnisse sind gelegentlich falsch, weil einige Einflussgrößen nicht beachtet werden. Grundsätzlich ist die Herangehensweise bei statistischen Analysen nicht anders als bei der Bewertung auf Basis von Erfahrungswissen. Beide Ansätze basieren auf Erfahrungen. Für eine statistische Auswertung müssen die Erfahrungen in statistisch auswertbarer Form vorliegen. Falls ein statistisches Prognosemodell für Feldzuverlässigkeit auf Basis von Maßen der Entwicklung gewünscht ist, so sind einige entsprechende Messdatensätze aus der Vergangenheit erforderlich, aus denen das Modell extrahiert werden kann. Es ist zu erwarten, dass die Verlässlichkeit der Aussage mit zunehmender Anzahl der Datensätze steigt. Statistische Auswertung bietet gegenüber der Auswertung mit Erfahrungswissen die Vorteile, auch komplizierte Abhängigkeiten erfassen zu können und eine Vertrauensniveau für die Verlässlichkeit der Aussagen zu liefern. Nachteilig ist, dass die Erfahrungen in gemessener Form vorliegen müssen. Geeignete Verfahren zur Bestimmung von Auswertemodellen auf Basis von Messungen sind die Hauptkomponentenanalyse (Principal Component Analysis, PCA), die Regressionsanalyse und die Diskriminanzanalyse (Abb. 7.12). Die Hauptkomponentenanalyse führt eine Vorverarbeitung der Messwerte durch. Dies dient z. B. zur Reduzierung des Verarbeitungsaufwands. Ferner ermöglicht sie die Identifizierung überflüssiger Maße und kann somit zu einer Reduzierung des Messaufwands beitragen. Mit Hilfe der Regressionsanalyse können Eigenschaften – z. B. die Restfehlerrate – als Zahlenwerte prognostiziert werden. Regressionsanalyse ist ein klassisches Verfahren, dass hier nicht weiter erläutert wird. Die Diskriminanzanalyse ermöglicht die Einteilung von Beobachtungen in zwei oder mehrere Klassen (z. B. Restfehlergehalt größer oder kleiner als ein vorgegebener Grenzwert). Für die Verfahren existieren Techniken, die eine Ermittlung des Fehlers gestatten, also eine quantifizierte Aussage zur Verlässlichkeit der Prognosen ermöglichen. Fischers Verfahren zur Diskriminanzanalyse (siehe z. B. /Johnson, Wichern 82/) ist unter sehr allgemeinen Bedingungen verwendbar. Obwohl die Technik ursprünglich für multivariat normalverteilte Messwerte entworfen wurde, arbeitet sie in der Regel auch dann zufriedenstellend, wenn diese Vorbedingung nicht erfüllt ist /Fahrmeir et al. 96/. Erfahrungsgemäß sind Messwerte oft nicht normalverteilt. Fischers Verfahren erzeugt als Modell eine Linearkombination der Maße sowie ein Skalar, das zur Diskriminierung der Beobachtungen verwendet

7.8 Auswertung von Messungen

Zu stark vereinfachte Erfahrungsregeln führen manchmal zu falschen Schlüssen.

Principal Component Analysis

Regressionsanalyse

Diskriminanzanalyse

Fischers Verfahren

253

Bezugsdaten M1 M2 M3 M4 M5 M6 M7 M8 M9 11 19 .6 12 3 .3 1 2 .3 6 20 .2

1 3 5 5

0 2 0 0 . . .

.33 .45 .66 .25

6 4 1 1

1 3 3 4

.4 .4 .6 .5

Modellermittlung

Hauptkomponentenanalyse

Regressionsanalyse

Diskriminanzanalyse Neue Messwerte

Prognosemodell Modellnutzung Prognose

Abbildung 7.12 Statische Auswertung von Messungen

wird. Daher ist das Modell einfach nutzbar. Nach der Modellermittlung sind die Ausgangsdaten nicht mehr erforderlich. Auf die Speicherung der Bezugsdaten kann verzichtet werden, da das Modell die gesamte Information trägt. Da es sehr einfach ist, erfordert seine Anwendung nur wenig Aufwand. Das ist ein Vorteil, weil sehr viele Auswertungen zur Ermittlung der Modellqualität erforderlich sind. Dieser Aspekt wird im folgenden noch erläutert. In /Liggesmeyer 00/ wird ein Ansatz beschrieben, der es gestattet, das Verfahren auf umfangreiche Maßsysteme anzuwenden. Darüber hinaus wird eine Fallstudie zur statistischen Auswertung realer Messwerte geschildert. Das Ergebnis der Modellermittlung ist der Vektor der Koeffizienten der Maße l = (l1 , ...ln ) und ein Skalar c, so dass die Linearkombination l1 M1 + l2 M2 + ...+ ln Mn optimal zwischen zwei Populationen unterscheidet. c ist der Wert, der verwendet wird, um zwischen den Populationen zu diskriminieren. Ein derartiges mathematisch begründetes Modell bildet eine optimale Auswerteregel für Messungen, die die übliche manuelle, intuitive Prozedur ersetzt. Fischers Verfahren bestimmt eine Hyperebene im n-dimensionalen Maßraum, die bestmöglich zwischen den zwei Populationen unterscheidet. Abb. 7.13 stellt dies für zwei Maße und positive Werte von l1 , l2 und c dar. Die Prognosequalität kann mit Hilfe des Anteils der Fehlklassifikationen bewertet werden. Darüber hinaus ist es möglich, die Gesamtkosten der

254

7 Software-Messung

M2 c l2

c l1

M1

Population 1 Population 2

Abbildung 7.13 Fischers Verfahren für zwei Maße

Fehlklassifikationen zur Bewertung zu verwenden. Es ist durchaus möglich, dass eine Fehlklassifikation je nach Art unterschiedliche Kosten verursacht. Wird z. B. eine Zuverlässigkeitsaussage für ein System erzeugt, die dazu dient, eine Freigabeentscheidung zu treffen, so wird die fehlerhafte Bewertung eines nicht hinreichend zuverlässigen Systems als ausreichend zuverlässig vermutlich kritischer sein, als die gegenteilige Fehlklassifikation. Die zu frühe Freigabe des Systems wird hohe Wartungskosten verursachen. Die Klassifikation eines hinreichend zuverlässigen Systems als unzuverlässig wird ebenfalls Kosten verursachen, da z. B. der Systemtest unnötigerweise fortgesetzt wird. Diese Kosten werden aber in der Regel im Vergleich zur erstgenannten Fehlklassifikation geringer sein. Um die Kosten der Fehlklassifikationen bei der Modellermittlung berücksichtigen zu können, müssen sie nicht absolut bekannt sein. Die Angabe des Verhältnisses reicht aus. Es ist möglich, dass ein Modell, das die Kosten von Fehlklassifikationen minimiert, die Anzahl der Fehlklassifikationen nicht minimiert.

7.9

Wichtige Maße für Software

Die frühesten Maße waren Umfangsmaße, die einfache, direkt verfügbare Informationen erfasst haben, z. B.: >

die Größe der Programmdatei,

>

die Anzahl der Programmzeilen (Lines of Code, LOC) oder

>

die Anzahl der Funktionen.

Diese einfachen Maße sind nur mit großen Vorbehalten zu verwenden und üblicherweise auch nicht vollständig eindeutig. Unklar ist z. B., ob bei der Zählung der Programmzeilen die Kommentarzeilen oder die Leerzeilen zu beachten sind. Die Anordnung von mehreren Anweisungen in einer Zeile führt zu einer Abnahme des Messwertes. Ferner können zwei

7.9 Wichtige Maße für Software

255

Programme mit gleichem Umfang aufgrund unterschiedlich komplexer Daten- und Kontrollstrukturen in jeder Hinsicht gegensätzliche Profile besitzen. Die unkritische Zählung von Funktionen in einem Programm führt zu der sicherlich falschen Aussage, dass ein wohlstrukturiertes Programm mit einer entsprechend hohen Anzahl an Funktionen eine höhere Komplexität besitzt, als ein unstrukturiertes, monolithisches Programm mit identischer Funktionalität. In der objektorientierten Software-Entwicklung müssen Maße verwendet werden, welche die geänderten Eigenschaften objektorientierter Software berücksichtigen. Es ist zu erwarten, dass etablierte Maße für funktional dekomponierte Software – z. B. die zyklomatische Zahl – unzureichend geeignet sind. Vorschläge für objektorientierte Maße sind z. B. in /Chidamber, Kemerer 94/ und /Briand, Wüst 01/ publiziert. Empirische Untersuchungen zu objektorientierten Maßen finden sich in /Basili et al. 96/ und /Cartwright, Shepperd 00/. Im Folgenden werden einige Beispiele für typische Maße aus den Gruppen textuelle Maße, Datenmaße, Kontrollflussmaße und Zuverlässigkeitsmaße dargestellt. Textuelle Maße setzen direkt auf dem Programmtext auf. Das verbreitete Umfangsmaß Lines of Code ist ein textuelles Maß. Im folgenden werden die Halstead-Maße als Beispiele für textuelle Maße beschrieben. Datenmaße verwenden die in einem Programm vorhandenen Daten als Basisgrößen zur Definition von Maßen. Dies kann – wie bei den textuellen Maßen – direkt auf Basis des Programmcodes oder mit Hilfe von Modellen, z. B. mit Datenflussattributen versehenen Kontrollflussgraphen, geschehen. Als Bespiele werden im folgenden die Maße Live Variables und die Variablenspanne definiert. Kontrollflussmaße verwenden die Kontrollstruktur des Programms als Basis zur Maßdefinition. Sie wird in der Regel in Form eines Kontrollflussgraphen dargestellt. Die zyklomatische Zahl wird als Beispiel für Kontrollflussmaße dargestellt. Die Werte von Zuverlässigkeitsmaßen können nicht statisch anhand von Elementen eines Programms ermittelt werden. Sie erfordern Ausfallbeobachtungen aus der Nutzung eines Software-Produkts. Die Nutzung der Software kann alternativ zum realen Betrieb durch einen geeigneten Test simuliert werden. Die während des Betriebs beobachteten Fehlverhalten dienen zur Ermittlung des Messwerts. Als Beispiel wird die MTBF (Mean Time between Failure) kurz beschrieben. Die MTBF ist ein verbreitetes Zuverlässigkeitsmaß, dessen Bestimmung auch für Software mit geeigneten statistischen Verfahren möglich ist (siehe Kapitel 14).

7.9.1 Die zyklomatische Zahl besitzt eine weite Verbreitung.

256

Die zyklomatische Komplexität

Die zyklomatische Zahl ist wahrscheinlich das am weitesten verbreitete Maß in Analyse- und Testwerkzeugen. Es stammt aus der Graphentheorie. Dort dient es zur Ermittlung der Komplexität von stark zusammenhängenden Graphen. Die zyklomatische Zahl gibt die maximale Anzahl

7 Software-Messung

linear unabhängiger Zyklen in derartigen Graphen an. Auf dem Umweg über modifizierte Kontrollflussgraphen kann sie auf Programme angewendet werden. Sie wird üblicherweise nicht durch Ermittlung aus Kontrollflussgraphen bestimmt, da der Wert für Programme auf sehr einfache Weise durch Abzählen der Entscheidungen gebildet werden kann. Die zyklomatische Zahl Z(G) eines Kontrollflussgraphen G ist: Z(G) = e − n + 2, e: Anzahl der Kanten von G, n: Anzahl der Knoten von G Für Kontrollflussgraphen ist die zyklomatische Zahl stets um eins größer als die Anzahl der Entscheidungen. Sie kann daher auf einfache Weise ermittelt werden. Für einen stark zusammenhängenden Graphen G ist die zyklomatische Zahl gleich der maximalen Anzahl linear unabhängiger gerichteter Zyklen. Ein Zyklus ist eine alternierende Sequenz aus Knoten und Kanten, deren erster und letzter Knoten identisch sind. Zyklen sind voneinander linear unabhängig, falls kein Zyklus als Linearkombination anderer Zyklen dargestellt werden kann. Kontrollflussgraphen sind nicht stark zusammenhängend, weil nicht notwendig einen Weg von jedem Knoten zu jedem anderen Knoten existiert. So besitzt z. B. der Startknoten eines Kontrollflussgraphen keinen Vorgängerknoten. Es gibt daher keinen Weg zum Startknoten zurück und folglich auch keine Zyklen, die den Startknoten enthalten. Man kann jedoch durch einen kleinen Trick Kontrollflussgraphen zu stark zusammenhängenden Graphen umformen. Man verbindet „in Gedanken“ den Endeknoten des Kontrollflussgraphen mit seinem Startknoten; man macht also künstlich den Endeknoten zum Vorgänger des Startknotens.

Definition der zyklomatischen Zahl

Kontrollflussgraphen sind nicht stark zusammenhängend.

Der Kontrollflussgraph nach Abb. 7.14 besitzt die zyklomatische Komplexität Z(G) = 9 − 8 + 2 = 3. Durch imaginäres Hinzufügen der gestrichelten Kante kann – wie beschrieben – ein stark zusammenhängender Graph erzeugt werden (Abb. 7.15), für den sich maximal drei linear unabhängige Zyklen erzeugen lassen, z. B. : a. nstart , n1 , n2 , n f inal , nstart b. n2 , n3 , n4 , n5 , n6 , n2 c. n2 , n3 , n4 , n6 , n2 Jeder weitere Zyklus in dem Kontrollflussgraphen nach Abb. 7.15 kann als Linearkombination dieser drei Zyklen dargestellt werden. Es können auch drei linear unabhängige Zyklen gebildet werden, die vollständigen Pfaden durch das Programm entsprechen. Sie beginnen und enden mit dem Knoten nstart : A. nstart , n1 , n2 , n f inal , nstart B. nstart , n1 , n2 , n3 , n4 , n5 , n6 , n2 , n f inal , nstart C. nstart , n1 , n2 , n3 , n4 , n6 , n2 , n f inal , nstart

7.9 Wichtige Maße für Software

257

Zyklomatische Zahl = Anzahl der Entscheidungen + 1

Abb. 7.16 stellt die Kontrollflussgraphen einiger linearer Kontrollstrukturen und ihre zyklomatische Komplexität dar. Man erkennt, dass die zyklomatische Zahl aller Kontrollflussgraphen um 1 größer ist, als die Anzahl der Entscheidungen. Diese Regel gilt stets. Ein Kontrollflussgraph ohne Entscheidungen verzweigt sich nicht. Verbindet man den Endeknoten eines solchen Graphen mit seinem Startknoten, so erhält man genau einen Zyklus. Fügt man in diesen Graphen eine Entscheidung ein, so bleibt dieser Zyklus erhalten und ein weiterer tritt hinzu. Dies wiederholt sich bei Einfügen weiterer Entscheidungen. Daher ist die Zahl der Zyklen stets um 1 größer als die Anzahl der Entscheidungen. Der Kontrollflussgraph nach Abb. 7.14 enthält zwei Entscheidungen. Er besitzt daher die zyklomatische Komplexität drei.

Die Testfallanzahl für einen Zweigüberdeckungstest kann anhand der zyklomatischen Zahl ermittelt werden.

Zweigüberdeckungstestwerkzeuge bieten oft eine Möglichkeit zur Messung der zyklomatischen Komplexität. Das ist sinnvoll, weil die zyklomatische Komplexität die Obergrenze der Testfallanzahl für einen vollständigen Zweigüberdeckungstest angibt. Anders formuliert: Einerseits ist es eventuell möglich, einen vollständigen Zweigüberdeckungstest mit weniger Testfällen zu erreichen, als durch die zyklomatische Zahl angegeben. Andererseits bedeutet die Durchführung einer größeren Zahl von Testfällen das Enthaltensein von Redundanzen. Die zyklomatische Zahl bietet sich also zur Aufwandschätzung für die Durchführung des Zweigüberdeckungstests an.

Abbildung 7.14 Kontrollflussgraph zu ZaehleZchn

258

7 Software-Messung

Abbildung 7.15 Kontrollflussgraph zu ZaehleZchn

Abbildung 7.16 Elementare Kontrollstrukturen und ihre zyklomatische Zahl

7.9 Wichtige Maße für Software

259

Allgemeingültige Obergrenzen für die zyklomatische Zahl sind nicht sinnvoll.

Als Obergrenze für die zyklomatische Komplexität von Software-Modulen findet man gelegentlich den Wert 10 (z. B. /Walsh 83/). Falls die zyklomatische Komplexität eines Software-Moduls diesen Wert überschreitet, so soll das Modul zerlegt werden. Ich halte diese Regel für zu stark vereinfacht. Die zyklomatische Zahl vermisst einen einzelnen Aspekt der Kontrollkomplexität. Andere Komplexitätsarten – z. B. Datenflusskomplexität – werden ignoriert. Daher sollte eine Entscheidung über die Zerlegung von Modulen in der Regel nicht auf ein einzelnes Maß gestützt werden.

7.9.2 Die Halstead-Maße setzen auf den Programmtext auf.

Die Halstead-Maße

Die Halstead-Maße /Halstead 77/ vermessen unterschiedliche Eigenschaften von Software, z. B. Komplexität, Umfang oder Aufwand. Sie basieren auf theoretischen Überlegungen, sind jedoch z. T. mit Erfolg empirisch validiert worden. Die Basis der Halstead-Maße bildet der Programmtext. Die unmittelbar im Text abzählbaren Eingangsgrößen der Maße sind die Anzahl der unterschiedlichen Operanden und Operatoren und die Gesamtzahl der Operanden und Operatoren. Die vier Basisgrößen der Halstead-Maße sind: η1 : Anzahl der unterschiedlichen Operatoren η2 : Anzahl der unterschiedlichen Operanden N1 : Gesamtzahl der verwendeten Operatoren N2 :Gesamtzahl der verwendeten Operanden Aus diesen vier Maßen können als weitere einfache Maße die Größe des verwendeten Vokabulars η und die Länge der Implementation N abgeleitet werden: η = η1 + η2 : Größe des Vokabulars N = N1 + N2 : Länge der Implementation

Der Umfang des Programms legt die Programmlänge fest.

Durch Betrachtung einiger kombinatorischer Regeln wird die Formel für die berechnete Programmlänge hergeleitet. Es ist interessant festzustellen, dass Halstead hier einen festen Zusammenhang zwischen dem Umfang des verwendeten Vokabulars und der Länge der mit diesem Vokabular erstellten Programme postuliert. Nˆ = η1 log2 η1 + η2 log2 η2 Die Programmgröße V (Volume) ist die Größe des Programms in Bits unter der Voraussetzung, dass eine Binärcodierung mit gleicher Wortlänge des Vokabulars vorliegt: V = N log2 η Die potentielle Programmgröße V ∗ ist eine hypothetische Programmgröße in einer optimalen fiktiven Programmiersprache, die allein vom Algorithmus und nicht von der real zur Implementation verwendeten Programmiersprache abhängig ist. In einer hypothetischen, idealen Programmiersprache steht die gewünschte Funktionalität bereits als Operation zur Verfügung. Daher sind zur Implementierung zwei Operatoren

260

7 Software-Messung

erforderlich; ein Operator ist der Funktionsaufruf, der andere Operator dient der Zuweisung des Ergebnisses. Daher gilt: η1∗ = N1∗ = 2 V ∗ = (N1∗ + N2∗ ) log2 (η1∗ + η2∗ ) = (2 + η2∗ ) log2 (2 + η2∗ ) Der Quotient aus der potentiellen Programmgröße V ∗ und V wird als Level bezeichnet: V∗ L= V Jede Implementation besitzt einen Level L, der kleiner oder bestenfalls gleich eins ist. Eine Programmiersprache ist umso geeigneter zur Implementierung eines Algorithmus, je näher L sich dem Wert eins nähert. Eine Programmiersprache die für einen bestimmten Algorithmus den Level eins aufweist, ist eine zur Kodierung dieses Algorithmus optimale Sprache. Daher ist der Kehrwert D (Difficulty) des Levels ein Maß für die Schwierigkeit einen Algorithmus in einer Programmiersprache zu kodieren: 1 D= L Eine zur Kodierung eines Algorithmus wenig geeignete Programmiersprache bewirkt einen Anstieg der Größe V und folglich auch der Schwierigkeit D. Die Größen L und D sind ein Maß für die Problemadäquanz der verwendeten Programmiersprache und für die Schwierigkeit einen gegebenen Algorithmus in einer bestimmten Sprache zu implementieren. Der Aufwand E (Effort) zur Kodierung eines Algorithmus ist nach Halstead proportional zur Programmgröße und zur Schwierigkeit der Kodierung. Die Schwierigkeit D ist der Kehrwert des Programmlevels L. Der Aufwand E kann daher wie folgt errechnet werden: V V2 = ∗ L V Interessant ist, dass dieses Aufwandsmaß einen quadratischen Zusammenhang zwischen dem Umfang eines Software-Moduls und dem Aufwand für seine Erstellung beschreibt, da V ∗ für jeden Algorithmus eine Konstante ist. Dies ist eine Motivation zur Modularisierung von SoftwareSystemen. Nehmen wir an, der Aufwand zur Realisierung eines Moduls mit einem bestimmten Umfang V1 sei E1 , und E1 sei proportional zu V12 . Wird das Modul in zwei Module mit den Umfängen V2 und V3 aufgeteilt, so gilt E2 ist proportional zu V22 und E3 ist proportional zu V32 . Da ferner V2 +V3 = V1 gilt, folgt dass E2 + E3 ≤ E1 . Die Summe von Quadraten ist immer kleiner oder gleich dem Quadrat der Summe. Bei einer Unterteilung eines Moduls in zwei Module wird eine maximale Reduzierung des Aufwands durch Bildung zwei gleich großer Module erreicht, die jeweils den halben Umfang besitzen. Nach Halsteads Formel erfordert diese Realisierung nur die Hälfte des Aufwands der Realisierung in Form eines E=

7.9 Wichtige Maße für Software

Quadratischen Zusammenhang zwischen Umfang und Aufwand

261

Moduls. Offensichtlich hat Halstead jedoch den Anstieg der Schnittstellenanzahl vernachlässigt, der durch eine stärkere Modularisierung verursacht wird, und die Einsparung teilweise kompensiert. Dies wird klar, wenn man sich verdeutlicht, dass nach Halsteads Formel die optimale Lösung in der Realisierung möglichst vieler elementarer, nicht weiter unterteilbarer Module besteht. Halsteads Formel approximiert den tatsächlich erforderlichen Aufwand. Es existiert eine optimale Anzahl von Modulen für jede Software. Sie ist definiert durch jenen Punkt, an dem der Aufwandsanstieg durch zusätzliche Schnittstellen die Einsparung durch weitere Modularisierung genau kompensiert.

7.9.3 Live Variables ist ein datenbasiertes Maß.

BEISPIEL

Das Maß Live Variables

Dieses Maß dient zur Messung der Komplexität. Es basiert auf der Annahme, dass die Erstellung einer Anweisung umso schwieriger ist, je mehr Variablen bei der Ausführung dieser Anweisung beachtet werden müssen. Man bezeichnet eine Variable innerhalb eines Moduls zwischen ihrer ersten und ihrer letzten Referenz als „lebendig“. Dies verdeutlicht das folgende Beispiel:

void MinMax (int& Min, int& Max) { int Hilf; 1 2 3 4

if (Min > Max) { Hilf = Min; Min = Max; Max = Hilf; } }

Tab. 7.1 gibt die Anzahl der lebendigen Variablen pro Zeile an. Die mittlere Anzahl lebendiger Variablen ist das arithmetische Mittel. Mittlere Anzahl Gesamtzahl lebendiger Variablen = lebendiger Variablen Anzahl ausführbarer Anweisungen Im Beispiel: LV =

10 = 2, 5 4 Zeile

Lebendige Variablen Anzahl

1

Min; Max

2

2

Min; Max; Hilf

3

3

Min; Max; Hilf

3

4

Max; Hilf

2

Tabelle 7.1 „Lebendige Variablen“

262

7 Software-Messung

7.9.4

Das Maß „Variablenspanne“

Ergänzend zur Lebensdauer einer Variablen ist die Spanne ihrer Referenzen wichtig. Auch die Variablenspanne ist ein Komplexitätsmaß. Ein Programm, das einen hohen Wert des Maßes Live Variables und eine hohe Variablenspanne besitzt ist in bezug auf die Daten komplex. In dem o.a. Beispiel wird die Variable min in den Zeilen 1, 2 und 3 benutzt. max wird in den Zeilen 1, 3 und 4 zugegriffen, und hilf wird in den Zeilen 2 und 4 verwendet. Die Spannen von min betragen also zweimal 1 Zeile. Die Spannen von max betragen 2 Zeilen und 1 Zeile. Die Spanne von hilf beträgt 2 Zeilen. Der arithmetische Mittelwert der Variablenspannen ist 1,4.

7.9.5

Die MTBF

Die MTBF ist neben der Ausfallrate ein weitverbreitetes Maß für die Zuverlässigkeit eines Produktes. Man kann Sie im einfachsten Fall folgendermaßen definieren: gesamte Betriebszeit MT BF = Anzahl der Aus f alle ¨ Diese simple Definition geht davon aus, dass die MTBF konstant ist, da keine Reperaturzeiten auftreten. Das ist aber bei Software aufgrund von Funktionserweiterungen und Fehlerkorrekturen in der Regel nicht korrekt. Die MTBF ist normalerweise zeitlich veränderlich. Man benötigt daher statistische Hilfsmittel zur Auswertung der Ausfälle, die es gestatten Aussagen über die MTBF herzuleiten. Die MTBF ist der Erwartungswert für die Zeitspanne zwischen zwei aufeinander folgenden Ausfällen. In Kapitel 14 wird die korrekte Definition angegeben. Für einfache Betrachtung – z. B. im Rahmen der im folgenden Abschnitt angegebenen Fallstudie – reicht die hier angegebene etwas nachlässige Definition oft aus. Ihr Vorteil ist die einfache Anwendbarkeit.

7.10

Die MTBF ist bei Software in der Regel zeitlich veränderlich.

Fallstudie zur Software-Messung

Im Folgenden wird eine konkrete Situation betrachtet. In einer bestehenden Organisation sollen softwaretechnische Verbesserungen eingeführt werden. Die folgenden Fragen müssen zu diesem Zweck beantwortet werden: >

In welcher Phase soll eine Verbesserung eingeführt werden?

>

Was soll damit erreicht werden?

>

Welche Methode soll eingesetzt werden?

>

Welche Technik und welches Werkzeug wird verwendet?

7.10 Fallstudie zur Software-Messung

Fragestellungen

263

Erfolgskontrolle

Zu messende Aspekte

Analyse

Bewertung

WICHTIG: Auch nicht betroffene Merkmale kontrollieren, um Seiteneffekte zu verhindern.

264

Ferner soll nach der Einführung der neuen Methoden, Techniken und Werkzeuge der Erfolg kontrolliert werden. Der erste Schritt sollte die Feststellung des aktuellen Stands sein: >

Welche Kosten und welcher Aufwand entstehen jeweils pro Phase?

>

Welchen Teil der Entwicklungszeit benötigen die unterschiedlichen Entwicklungsphasen?

>

Wie ist die Qualität der Ergebnisse jeder Phase?

>

In welcher Phase entsteht welcher Anteil der Fehler und welcher Teil der Fehlerbeseitigungskosten?

Um diese Fragen zu beantworten, ist eine Gruppe von Maßen erforderlich, die folgende Aspekte erfasst: >

Kostenverfolgung,

>

Zeitverfolgung,

>

Aufwandsverfolgung,

>

Qualitätsmaße für Produkt pro Phase,

>

Fehlerstatistiken (Anzahl, Aufwand zur Beseitigung, Ursache).

Der zweite Schritt ist die Analyse der Situation und die Auswahl und Einführung von Verbesserungen. Dies erfordert im einzelnen die folgenden Aktivitäten: >

Auswertung der Maße.

>

Definition von Zielen auf Basis der Messwerte.

>

Entscheidung für Verbesserungen in bestimmten Phasen.

>

Auswahl geeigneter Methoden, Techniken und Werkzeuge.

>

Geeignete Einführung.

Der dritte Schritt ist die Bewertung der Situation nach dem Abklingen von Einschwingvorgängen. Das Ziel ist die Kontrolle der Auswirkungen der neuen Arbeitsweise, also eine Erfolgskontrolle unter Verwendung der gleichen Maße, die zur Feststellung des Ist-Standes vor der Umsetzung der Maßnahmen verwendet wurden. Neben einer Bewertung der Zielmerkmale, ist es wichtig, auch jene Merkmale zu kontrollieren, von denen angenommen wird, dass sie keine Reaktion zeigen. Dies dient der Verhinderung von unerwünschten Seiteneffekten. Falls Ziele durch die ausgewählten Maßnahmen nicht erreicht worden sind oder nicht beabsichtigte Effekte eingetreten sind, so ist eine Nachbesserung erforderlich. Dieser Rückkopplungsschritt ist sehr wichtig, denn er gestattet die Installation eines kontinuierlichen Verbesserungsprozesses.

7 Software-Messung

Es soll eine Fehlerliste ausgewertet werden, um aufgrund der Fehlerhäufigkeiten, ihren Ursachen und der Aufwände für ihre Korrektur eine Entscheidung für einzuführende systematische Techniken, Methoden und Werkzeuge zu treffen. Die Ziele sind eine deutliche Reduktion der Fehleranzahl, um die Probleme der Kunden mit der Software zu reduzieren und hohe Qualität zu demonstrieren, und die Vermeidung oder frühzeitige Erkennung besonders teurer Fehler, um Aufwand und Kosten zu sparen.

Ziele der Messung

Die Vorgehensweise entspricht dem bereits dargestellten Ablauf: >

Auswahl von Maßen, die geeignet sind, die erforderlichen Informationen zu erfassen.

>

Ermittlung des Ist-Standes.

>

Identifikation der Problembereiche.

>

Definition von Gegenmaßnahmen.

>

Kontrolle, ob die erwünschten Auswirkungen eingetreten sind.

Die angestrebte deutliche Reduktion der Fehleranzahl mit dem Ziel, dem Kunden ein zuverlässigeres Produkt zur Verfügung zu stellen, führt zur Verwendung eines Zuverlässigkeitsmaßes. Es bietet sich die MTBF an. Zur Erkennung der in bezug auf die Korrektur besonders unangenehmen Fehler kann der Aufwand der jeweiligen Korrektur dienen. Geht man davon aus, dass die Software auch nach dem Auftreten eines Fehlverhaltens weiter betrieben wird, so erhält man aufgrund der Daten in der Fehlerliste (Tab. 7.2) den folgenden Wert für die MTBF: MT BF = 343 Tage/17 = 20, 2 Tage. Aus der gleichen Tabelle errechnet man einen mittleren Aufwand pro Fehlerkorrektur von 8,8 Mitarbeitertagen. Diese zwei Werte repräsentieren den hier relevanten Ausschnitt der Ist-Situation. Eine Analyse der Fehlerliste zeigt, dass die Fehler unterschiedliche Ursachen besitzen, die verschiedenen Phasen zugeordnet werden können: Der Definitionsphase können die fünf Fehler mit den Nummern 1, 6, 10, 14 und 15 zugeordnet werden. Der mittlere Korrekturaufwand dieser Fehler beträgt 27 MT (Mitarbeitertage). Der gesamte Korrekturaufwand beträgt 135 MT. Nur die drei Fehler mit den Nummern 3, 5 und 9 besitzen ihre Ursache in der Entwurfsphase. Ihr mittlerer Korrekturaufwand beträgt 5,7 MT. Der gesamte Korrekturaufwand beträgt 17 MT. In der Implementierungsphase sind zehn Fehler mit den Nummern 2, 4, 7, 8, 11, 12, 13, 16, 17 und 18 entstanden. Der mittlere Korrekturaufwand beträgt 0,6 MT. Der gesamte Korrekturaufwand beträgt 6 MT.

Analyse der Ist-Situation

Eine Kostenreduktion wird am sinnvollsten durch Verbesserungen in der Definitionsphase erreicht, da hier der größte Teil der Korrekturkosten

Identifikation von Maßnahmen

7.10 Fallstudie zur Software-Messung

265

lfd. Nr.

Problembeschreibung

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

…

Datum der Meldung

Korrigiert am

07.03.01 11.04.01 13.04.01 04.05.01 23.05.01 01.06.01 02.06.01 15.06.01 01.07.01 03.07.01 02.08.01 29.08.01 04.09.01 28.09.01 11.11.01 20.12.01 02.01.02 13.02.02

20.04.01 13.04.01 05.05.01 06.05.01 05.06.01 28.06.01 15.06.01 18.06.01 10.07.01 30.08.01 05.08.01 01.09.01 06.09.01 18.11.01 10.12.01 23.12.01 31.01.02 15.02.02

Korrekturzeit (Werktage) 25 0,5 5 0,3 7 15 0,2 0,4 2,5 28 0,6 0,8 1 22 13 0,2 9 1

Korrekturaufwand (MT) 50 0,5 5 0,3 7 15 0,2 0,4 5 35 0,6 0,4 1 22 13 0,2 2 0,4

Fehlerursache Fehlerhafte Anforderung Codierfehler (Schleife) Modulspezifikation Falsche Pfadbedingung Schnittstelle zw. Modulen Fehlende Funktionalität Fehlende Initialisierung Folgefehler durch Fehlerkorrektur Falsche Modularisierung Zu gering definierte Performance Frühere Fehlerkorrektur Falscher Datentyp verwendet Algorithmischer Fehler Anforderung mißverstanden Anforderung falsch Erforderl. Daten nicht vorgesehen Programmierfehler Fehlende Initialisierung

Tabelle 7.2 Fehlerliste über 343 Tage

verursacht wird, obwohl die Mehrzahl der Fehler in der Implementierungsphase entstehen. Eine Reduktion der Fehleranzahl wird daher geeignet durch Verbesserungen in der Implementierungs- bzw. Modultestphase erreicht. Die gewünschten Verbesserungen werden durch Auswahl und Einführung von konstruktiven und/oder analytischer Qualitätssicherungstechniken für die Definitionsphase (z. B. Strukturierte Analyse, Objektorientierte Analyse, Reviewtechniken) und für die Implementierungsphase (z. B. Strukturiertes Programmieren, Generierungstechniken, systematisches Modultesten) erreicht. Erfolgskontrolle

Nach dem Abklingen der Einschwingvorgänge ist eine Erfolgskontrolle mit Hilfe der bereits genutzten Maße erforderlich.

7.11

Erst Ziele festlegen; dann Maße definieren

Es existiert kein universell geeignetes Maß.

266

Bewertung der Software-Messung

Keine systematische Disziplin kann ohne quantitative Informationen auskommen. Die Verwendung von Maßen in der Software-Entwicklung ist ohne Zweifel unverzichtbar. Bei der Einführung von Maßen ist darauf zu achten, dass dies sorgfältig im Hinblick auf die Erreichung definierter Ziele geschieht. Darüber hinaus ist es notwendig, die Funktionsfähigkeit der Maße zu validieren und gegebenenfalls zu optimieren. Messwerte liefern von sich aus in der Regel keine hinreichende Aussage. Für eine systematische Auswertung von Messungen ist daher Sorge zu tragen. In diesem Zusammenhang besitzen auch statistische Verfahren eine hohe Bedeutung. Es ist zu beachten, dass eine Lernkurve durchlaufen werden muss, bevor auf Basis von Messungen sinnvolle Entscheidungen herbeigeführt werden können. Dies erfordert finanziellen und zeitlichen Aufwand. Ein Universalsoftwaremaß gibt es trotz der verbreiteten Nutzung bestimmter Maße nicht. Verlässliche Aussagen über Software erfordern in der Regel die Verwendung eines Satzes von Maßen, wobei jedes Maß

7 Software-Messung

eine spezifische Eigenschaft erfasst. Die zyklomatische Zahl ist als Kontrollflussmaß verbreitet. Sie erfasst aber z. B. keine Komplexitäten im Bereich der Daten. Datenbasierte Komplexitätsmaße – z. B. Live Variables – sind im Wesentlichen blind gegenüber Kontrollflusskomplexitäten. Lines of code (LOC) ist ein seit langem verbreitetes Umfangsmaß. Ein weiteres geeignetes Umfangsmaß ist das Halstead-Maß N (Länge der Implementation). Es ist eine Alternative zur Benutzung von LOC. Vorteilhaft ist insbesondere die große Unempfindlichkeit gegenüber unterschiedlichen Programmierstilen. Diese haben ggf. einen deutlichen Einfluss auf die Anzahl der Programmzeilen, aber kaum Einfluss auf die Anzahl der verwendeten Operatoren und Operanden. Bei der Auswertung von Messungen sollten einfache, auf Plausibilität beruhende Regeln mit großer Zurückhaltung verwendet werden. Viele auf den ersten Blick einleuchtende Regeln halten einer empirischen Überprüfung nicht stand. In /Basili, Perricone 84/ sind Ergebnisse einer empirischen Untersuchung publiziert, die in Abb. 7.17 zusammenfassend dargestellt sind. Verblüffend ist, dass die Anzahl der gefundenen Fehler pro Line of Code mit der Modulgröße abnimmt. Intuitiv würde man vermutlich eher erwarten, dass ein Anstieg zu verzeichnen sein wird. Das Ergebnis der Studie von Basili und Perricone mag einen realen Effekt zeigen. Es ist aber auch denkbar, dass die Fehler in den wenig umfangreichen Modulen einfacher zu finden waren, während in den umfangreicheren Modulen nur ein geringerer Anteil der Fehler erkannt wurde. Entscheidend ist, dass bei der Auswertung von Messungen sorgfältig vorzugehen ist und die Verwendung plausibel erscheinender aber unbewiesener Regeln als kritisch anzusehen ist.

Abbildung 7.17 Empirische Messergebnisse

7.11 Bewertung der Software-Messung

267

CHECKLISTE

268

>

Die ersten in der Software-Entwicklung verwendeten Maße betreffen erfahrungsgemäß die Projektplanung und -kontrolle. Sie sollten prüfen, ob in diesem Anwendungsbereich ein funktionierendes Messsystem installiert ist und gegebenenfalls Verbesserungen durchführen.

>

Die Identifikation von Maßen für technische Eigenschaften – z. B. Komplexität und Qualität – muss zielgerichtet erfolgen. Es empfiehlt sich die Nutzung des GQM-Verfahrens.

>

Identifizieren Sie einige wenige Maße, mit denen Sie genau definierte Ziele erreichen möchten. Dies ist wesentlich besser als die Definition eines überdimensionierten Messsystems ohne genaue Zielvorstellung.

>

Überlegen Sie sich bei jedem Maß genau, wie Sie feststellen können, dass die Messwerte die gewünschte Information tragen.

>

Legen Sie fest, auf welche Weise Messungen ausgewertet werden sollen. Insbesondere bei komplizierten Abhängigkeiten sollte die Benutzung statistischer Auswertemodelle erwogen werden.

>

Dass bestimmte Maße von vielen Werkzeugen angeboten werden, sagt im Einzelfall wenig über ihre Nützlichkeit aus. Sie sollten daher Ihre Maße passend zu den Zielen wählen und nicht umgekehrt.

7 Software-Messung

8 Werkzeugunterstützte statische Codeanalyse In diesem Kapitel werden Ihnen Techniken vorgestellt, deren Eigenschaften gut zu den Rahmenbedingungen der Praxis passen: Ihre Nutzung erfordert nur wenig Zeit und einen geringen Aufwand, weil sie umfassend durch Werkzeuge automatisiert werden können. Der Aufwand bei der Nutzung dieser Werkzeuge ist vergleichbar mit dem Aufwand eines Compileraufrufs, d. h. verschwindend gering. Das Gleiche gilt für den Schwierigkeitsgrad der Auswertung der Ergebnisse. Jeder, der in der Lage ist, einen Compiler zu bedienen, kann daher auch diese Techniken verwenden. Mit einer werkzeugunterstützten statischen Codeanalyse können unterschiedliche Ziele verfolgt werden. Neben der Überprüfung von Programmierkonventionen können Informationen in Form von Grafiken oder Tabellen aufbereitet dargestellt werden. Es ist sogar möglich, bestimmte Fehler sicher zu erkennen oder nach dem Auftreten eines Fehlverhaltens – etwa beim dynamischen Testen – die Fehlersuche zu unterstützen. Ein gemeinsames Kennzeichen der hier vorgestellten Techniken ist, dass sie mit Ausnahme des so genannten dynamischen Slicings keine Ausführung der zu prüfenden Software verlangen.

Übersicht 8.1

Eigenschaften und Ziele der werkzeugunterstützten statischen Codeanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

8.2

Stilanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

8.3

Diagramme und Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

8.4

Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

8.5

Datenflussanomalieanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

8.6

Bewertung der werkzeugunterstützten statischen Codeanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

269

8.1

Werkzeugunterstützung ist unbedingt notwendig.

Die Werkzeuge arbeiten ähnlich wie Compiler.

Werkzeugunterstützte statische Codeanalyse entlastet den Prüfer.

270

Eigenschaften und Ziele der werkzeugunterstützten statischen Codeanalyse

Dieses Kapitel trägt den Namen „Werkzeugunterstützte statische Codeanalyse“, um zu betonen, dass die beschriebenen Techniken unbedingt werkzeugunterstützt durchgeführt werden sollen. Grundsätzlich können alle statischen Analysen auch von Hand durchgeführt werden. Eine manuelle Durchführung besitzt aber deutliche Nachteile: Neben dem hohen Zeitbedarf und dem erforderlichen Aufwand ist damit zu rechnen, dass die Analyseergebnisse eine schlechtere Qualität besitzen werden als automatisch erzeugte Ergebnisse. Die Ursache ist die Art der Tätigkeit. Statische Codeanalyse verlangt ein stures, monotones Anwenden von relativ einfachen Regeln auf oft umfangreichen Code. Diese Aufgabe erfordert keinerlei Kreativität aber eine sehr große Übersicht und Kontrolle. Beides können Menschen insbesondere dann nicht garantieren, wenn das zu analysierende Objekt umfangreich und kompliziert ist. Statische Codeanalyse ist daher prädestiniert zur Automatisierung durch Werkzeuge. Ich empfehle Ihnen, diese Techniken entweder werkzeugunterstützt oder gar nicht einzusetzen. Die Aufgaben der statischen Codeanalyse besitzen starke Ähnlichkeiten zu den Aufgaben von Compilern. Die unterstützenden Werkzeuge sind daher ähnlich aufgebaut wie Compiler. So ist z. B. als erster Schritt eine Analyse der Struktur des zu untersuchenden Codes erforderlich. Diese so genannte lexikalische und syntaktische Analyse entspricht im Wesentlichen den Schritten, die auch Compiler durchführen. Es existieren Compiler, in die bestimmte statische Codeanalysen integriert sind. Darüber hinaus sind auf dem Markt eigenständige Werkzeuge verfügbar. Zum Teil sind statische Codeanalysen als Komponente in andere Qualitätssicherungswerkzeuge integriert. Die statischen Codeanalysen sind durch die folgenden gemeinsamen Eigenschaften charakterisiert: >

Verzicht auf die Programmausführung

>

Analyse des Quellcodes

>

Kein Korrektheitsnachweis

>

Garantiert vollständige Aussagen in Bezug auf die betrachtete Eigenschaft (z. B. garantierte Erkennung so genannter Datenflussanomalien)

>

Umfassende Automatisierbarkeit

Die im Folgenden beschriebenen Techniken verfolgen das Ziel, bestimmte Prüfungen, die eine strenge Systematik besitzen, zu automatisieren. Dies entlastet den Prüfer. Ihm werden entsprechende Informationen in verdichteter, aufbereiteter Form durch die Analysewerkzeuge zur Verfügung gestellt. Es ist sichergestellt, dass diese Informationen vollständig sind.

8 Werkzeugunterstützte statische Codeanalyse

Die Aufgabe des Prüfers ist die Auswertung der automatisch erzeugten Informationen. Typische Fragestellungen sind: >

Soll ein erkannter Verstoß gegen eine Programmierkonvention gestattet werden, oder muss der Code entsprechend geändert werden?

>

Ist die Struktur eines automatisch generierten Kontrollflussgraphen akzeptabel oder zu kompliziert?

>

Wie wird ein so genannter Slice nach dem auslösenden Fehler für ein erkanntes Fehlverhalten durchsucht?

>

Soll eine so genannte dd-Datenflussanomalie beseitigt werden, oder wird diese akzeptiert?

Zusammenfassend kann man formulieren: Das Ziel der statischen Codeanalyse ist eine möglichst umfassende Automatisierung systematischer Prüfungen, um den Prüfer von dieser Tätigkeit zu befreien und so seine Kreativität für wichtigere Aufgaben freizuhalten.

8.2 8.2.1

Ziel der statischen Codeanalyse

Stilanalyse Eigenschaften und Ziele der Stilanalyse

In vielen Firmen existiert ein Regelwerk, das die Programmierer beim Codieren zu beachten haben. Man bezeichnet diese Programmierregeln auch als Programmierkonventionen. Mit Programmierkonventionen können unterschiedliche Ziele verfolgt werden. Häufig soll die Einhaltung bestimmter Qualitätseigenschaften unterstützt werden. Man versucht in der Programmierung z. B. Konstrukte zu vermeiden, die Fehler begünstigen, die Portabilität der Software behindern oder die Verständlichkeit des Codes reduzieren. Neben Beschränkungen der erlaubten Syntax sind aber auch zusätzliche Forderungen verbreitet. So ist es üblich, im Kopf eines Moduls eine Änderungshistorie zu führen. Der Zwang, zu Beginn und am Ende einer Operation so genannte Zusicherungen anzugeben, ist ein weiteres Beispiel. Einerseits kann die Einhaltung derartiger Regeln manuell im Rahmen einer Codeinspektion geprüft werden. Andererseits bietet sich eine Automatisierung der Prüfung über einschlägige Werkzeuge an.

Firmeninterne Programmierkonventionen

Neben firmeneigenen Programmierkonventionen existieren Regeln, die für bestimmte Programmiersprachen grundsätzlich akzeptiert werden. Dies gilt insbesondere für Sprachen aus der C-Familie. Ziel ist es, bei Sprachen, deren Syntax qualitätsmindernde Bestandteile enthält, eine Prüfung vorzusehen, die diese Konstrukte erkennt und ausweist. Das erste allgemein übliche Werkzeug für diese Aufgabe war lint für C unter UNIX.

Programmiersprachenspezifische Programmierkonventionen

8.2 Stilanalyse

Zusicherung = Assertion

271

8.2.2 Syntax = Form Semantik = Inhalt

Syntaktische Programmierkonventionen können automatisch überprüft werden.

Semantische Programmierkonventionen müssen von Menschen geprüft werden.

Prüfung der Einhaltung von Programmierkonventionen

Programmierkonventionen können syntaktische oder semantische Inhalte besitzen. Diese Unterscheidung ist wichtig, weil erstere automatisch durch Werkzeuge geprüft werden können, während letztere eine Überprüfung durch den Menschen erfordern. Ein Beispiel für syntaktische Programmierkonventionen sind z. B. die Forderungen, dass goto-Anweisungen nicht verwendet werden dürfen, oder dass Prä- und Post-Inkrementier- sowie Prä- und Post-Dekremetier-Anweisungen nicht erlaubt sind. Die Überprüfung der Einhaltung dieser Regeln erfordert ein Werkzeug, das den Quellcode der Software nach den Symbolen „goto“, „++“ und „- -“ durchsucht. Die Überprüfung syntaktischer Programmierkonventionen erfordert daher nur einen geringen Aufwand. Beispiele für semantische Programmierkonventionen sind die Forderungen nach einer aussagekräftigen Namensgebung – z. B. für Variablen – und nach geeigneten Kommentaren. Die erforderliche Bewertung der Inhalte kann ein Werkzeug nicht leisten. An dieser Stelle ist eine Interpretation durch Menschen erforderlich. Während die Prüfung von syntaktischen Programmierkonventionen Gegenstand der werkzeugunterstützten statischen Codeanalyse ist, prüft man semantische Programmierkonventionen oft im Rahmen von Code-Inspektionen. Die Regeln können zu diesem Zweck in eine Checkliste umgesetzt werden, die bei der Inspektion abgearbeitet wird. Da manuelle Prüfungen zeit- und kostenaufwändiger sind als automatische Prüfungen, ist darauf zu achten, dass nur die semantischen Prüfungen manuell erfolgen. Im Folgenden werden allein syntaktische Konventionen dargestellt und diskutiert. Es handelt sich dabei um ausgewählte Regeln. Umfassende Regelwerke sind insbesondere zu den Programmiersprachen C, C++ und Java publiziert (z. B. /van Meegen, Schless 92/, /Schaefer et al. 98/) und können auch im Internet gefunden werden. Insbesondere bei den im Internet verfügbaren Regelwerken ist eine kritische Betrachtung der Inhalte angebracht. Zum Teil sind Regeln zu finden, die einer näheren Analyse nicht standhalten. So halte ich z. B. die folgende Regel aus dem Internet für falsch: „... Es gibt einen Nachteil, falls jede Klammer in einer separaten Zeile steht: Dies fügt keinerlei Information ein, aber verringert die Menge Code, die gleichzeitig auf dem Bildschirm sichtbar ist ... Öffnende Klammern werden in die gleiche Zeile geschrieben, in der die Bedingung steht, an die der folgende Block geknüpft ist. Schließende Klammern, die nicht vor einem else oder while stehen, werden in eine separate Zeile auf Höhe des Anfangs der Bedingung geschrieben. Ansonsten werden schließende Klammern vor dem else oder while positioniert ...“

272

8 Werkzeugunterstützte statische Codeanalyse

if ( a == a b } else { b } // if

b ) { = 3; = 5;

BEISPIEL 1

= 7;

Nicht ohne Grund existieren in Programmiersprachen wie Modula-2 und ADA qualifizierende Blockendebezeichner z. B. end if oder end loop, die die Zuordnung zwischen dem schließenden Bezeichner und dem geschlossenen Block erleichtern und typischerweise die gleiche Einrückung besitzen wie das Schlüsselwort, das den Block eröffnet hat. if Line_Too_Short then raise Layout_Error; elsif Line_Full then New_Line; Put(Item); else Put(Item); end if;

BEISPIEL 2

Ich halte bei dem angegebenen Beispiel 1 die folgende Schreibweise für besser: if ( a == { a b } else { b } // if

b ) = 3; = 5;

BEISPIEL 1: Bessere Alternative

= 7;

Meine Regel lautet daher: Öffnende und schließende Klammern eines Blocks stehen stets allein in einer Zeile und besitzen die gleiche Einrückung wie das dem Block zugeordnete eröffnende Schlüsselwort. Der Inhalt des Blocks ist um einen Schritt tiefer eingerückt. Im Folgenden wird eine Auswahl von syntaktischen – also automatisch prüfbaren – Programmierkonventionen für C-Programme angegeben:

8.2 Stilanalyse

Programmierkonventionen für C

273

a) Kontrollstrukturen: >

> >

>

Bei Mehrfachauswahlkonstrukten (switch-Anweisung) ist darauf zu achten, dass – jeder Fall, der Anweisungen enthält, mit einer break-Anweisung abgeschlossen wird, – jeder Fall, der keine Anweisungen enthält, nicht mit einer break-Anweisung abgeschlossen wird (Verweis auf den nächsten Fall) und – notwendig ein – möglicherweise leerer – default-Fall enthalten ist. return-Anweisungen sollen pro Funktion nur einmal vorkommen. Die bedingte Bewertung soll nicht verwendet werden, d. h. var = (bedingung) ? wert1 : wert2; soll als if -Konstrukt formuliert werden. Schleifen mit mehrfachen Ausgängen sind möglichst nicht zu verwenden. Falls Sie auftreten, so ist darauf zu achten, dass zum Schleifenende hin abgebrochen wird.

b) Operationen: >

> >

>

c)

Datentypen, Variablen und Bezeichner: > > > >

Zusicherungen in C

274

peratoren, die aus einer Kombination von Verknüpfung und Zuweisung bestehen, sind zu vermeiden. Statt x += y; sollte x = x + y; geschrieben werden. Zuweisungen in Ausdrücken sind verboten. Mehrfachzuweisungen sind verboten, z. B. x = y + (z = 2);. Post- und Prä-Inkrementier- sowie Post- und Prä-Dekrementier-Operationen sind zu vermeiden. Eine Ausnahme bildet die Steuerung von for-Schleifen. Es ist darauf zu achten, dass Kongruenz zwischen Operationen und Datentypen herrscht (z. B. Anwendung der Operation mod nur auf positive Integerwerte).

Typkonvertierungen sind explizit durchzuführen. Bezeichner dürfen nicht mit einem Unterstrich beginnen. Variablen sind stets zu initialisieren. Ungültige Zeiger sind als Null-Zeiger zu belegen.

Neben derartigen einschränkenden Regeln sind häufig auch erweiternde Regeln vorhanden. Ein Beispiel ist der Zwang zur Benutzung von Eingangs- und Ausgangszusicherungen. Man bezeichnet Zusicherungen auch als Assertions. Sie werden in C durch den Makro void assert (int expression) realisiert. Hat expression bei der Ausführung des Makros den Wert falsch, dann wird diese Verletzung der Zusicherung berichtet, und die Programmausführung gestoppt.

8 Werkzeugunterstützte statische Codeanalyse

Zusicherungen sind besonders geeignet, um die Erfüllung von Eingabebedingungen zu überprüfen. Dazu gehört z. B. die Prüfung auf gültige Parameterwerte. Ausgangsseitig bieten sich Zusicherungen für die Überprüfung des Ergebnisses an. Daher ist die Formulierung von Eingangs- und Ausgangszusicherungen sinnvoll. Ob zu jeder Funktion eine Eingangsund eine Ausgangszusicherung vorliegt, kann automatisch geprüft werden.

Eine Quadratwurzelfunktion Qwurzel(x), die reelle Wurzeln berechnet, erwartet einen nicht-negativen Eingabewert x. Die Eingangszusicherung ist also assert (x >= 0). Für die berechneten Ergebnisse gilt dann, dass sie ebenfalls nicht-negativ sein müssen. Falls y die Ergebnisvariable ist, so lautet die Ausgangszusicherung daher assert (y >= 0).

8.2.3

BEISPIEL zu Zusicherungen

Bewertung der Stilanalyse

Die Prüfung der Einhaltung von Programmierkonventionen ist ein etabliertes Verfahren im Bereich der Qualitätssicherung. Ob die Durchführung einer Stilanalyse freiwillig oder notwendig ist, entscheiden insbesondere die verwendete Programmiersprache und der Anwendungsbereich der Software. So enthält z. B. die Norm EN 50128 „Bahnanwendungen, Software für Eisenbahnsteuerungs- und Überwachungssysteme“ die folgenden Forderungen:

Es gibt Standards, die die Nutzung von Programmierkonventionen fordern.

Für Software, die kritische Funktionen steuert, wird C als Programmiersprache nicht empfohlen. Eine Untermenge von C in Kombination mit Codierstandards wird empfohlen. Dies ist eine explizite Forderung zur Verwendung der Stilanalyse. Andere Programmiersprachen (z. B. Ada und Pascal) werden für kritische Software auch ohne zusätzliche Codierstandards empfohlen. Die Stilanalyse ist bei Verwendung von Programmiersprachen mit einer liberalen, qualitätsmindernden Syntax (z. B. C) unverzichtbar. Werden Programmiersprachen verwendet, die über eine restriktive Syntax verfügen (z. B. Pascal), so kann auf die Stilanalyse verzichtet werden. Dies gilt aber nur im Hinblick auf die Überprüfung einschränkender Regeln. Die Überprüfung erweiternder Regeln (z. B. Verwendung von Zusicherungen) ist auch in Programmiersprachen wie Ada und Pascal sinnvoll. Einschlägige Werkzeuge sind zu moderaten Kosten auf dem Markt verfügbar. Unbedingt notwendig ist es, die entsprechenden Prüfungen des Compilers umfassend zu nutzen.

8.2 Stilanalyse

275

8.3 8.3.1 Die Nutzung von Diagrammen und Tabellen ist Stand der Technik.

Diagramme und Tabellen Eigenschaften und Ziele der Nutzung von Diagrammen und Tabellen

Die Verwendung grafischer und tabellarischer Darstellungen ist in der Software-Entwicklung heute als Stand der Technik zu werten. Dies gilt insbesondere für die frühen Phasen der Software-Entwicklung. So verwendet die Analysemethodik Structured Analysis nach Tom DeMarco z. B. Datenflussdiagramme. Für den Entwurf relationaler Datenbanksysteme werden so genannte Entity-Relationship-Diagramme verwendet. In objektorientierten Analyse- und Entwurfstechniken (z. B. UML) werden z. B. Kollaborationsdiagramme, Sequence Charts und Zustandsautomaten verwendet. Beim strukturierten Entwurf von Software können so genannte SD-Diagramme verwendet werden. Zur Darstellung der Kontrolllogik von Software-Modulen wurden früher Programmablaufpläne verwendet. Strukturorientierte dynamische Testtechniken sind auf Basis von Kontrollflussgraphen definiert, und zur Beschreibung linearer Kontrollflüsse haben sich Nassi-Shneiderman-Diagramme etabliert. Grafiken bieten in der Regel einen leichter verständlichen Zugang zu komplizierten Informationen als andere Darstellungsformen. Viele der genannten Grafiken können aus dem Quellcode automatisch erzeugt werden. Dies gilt insbesondere für diejenigen Grafiken, die die technische Realisierung einer Software betreffen. Beispiele dafür sind die bereits vorgestellten Kontrollflussgraphen als Basis für den Modultest. Des Weiteren können Aufrufgraphen zur Darstellung der Software-Architektur erzeugt werden. Sie bilden eine geeignete Basis im Rahmen des Integrationstests.

8.3.2 Grafiken stellen komplizierte Sachverhalte leicht verständlich dar.

Diagramme

Grafische Darstellungen werden in der Software-Qualitätssicherung häufig verwendet, um komplizierte Informationen in leicht zugänglicher Form zur Verfügung zu stellen. Besonders häufig werden grafische Darstellungen der Programmstruktur als Hilfsmittel des Software-Tests verwendet. In Abhängigkeit der Prüfphase werden unterschiedliche Grafiken benutzt. So werden bei der Überprüfung von Software-Modulen sehr häufig verschiedene Ausprägungen von Kontrollflussgraphen verwendet. Im Bereich der Integrationsprüfung findet man verbreitet so genannte Aufrufdiagramme, SD-Diagramme oder in der objektorientierten Software-Entwicklung Kollaborationsdiagramme. Da es sich insbesondere bei jenen Diagrammen, die die Struktur des Software-Quellcodes darstellen, um alternative Darstellungen für Programmtext handelt, können die grafischen Darstellungen automatisch aus dem Software-Quellcode extrahiert werden. Dies geschieht durch statische

276

8 Werkzeugunterstützte statische Codeanalyse

Analyse. Andererseits ist es grundsätzlich auch möglich, zunächst einmal z. B. einen Kontrollflussgraphen zu entwerfen, und diesen dann automatisch in entsprechenden Software-Quellcode umzusetzen. Da die Prüfung von Software an dieser Stelle Gegenstand sein soll, wird die Erzeugung von Grafiken aus vorliegendem Software-Quellcode betrachtet und die Erzeugung von Software-Quellcode aus Grafiken nicht weiter diskutiert. 8.3.2.1

Kontrollflussgraph

Der Kontrollflussgraph ist neben dem Programmablaufplan eine häufig verwendete Methode zur Darstellung von Programmen Er wird im Folgenden häufig im Zusammenhang mit der Definition strukturorientierter Testverfahren verwendet.

Kontrollflussgraphen sind wichtig im Zusammenhang mit Software-Tests.

Ein Kontrollflussgraph ist ein gerichteter Graph G = (N, E, nstart , n f inal ). N ist die endliche Menge der Knoten. E ⊆ N × N ist die Menge der gerichteten Kanten. nstart ∈ N ist der Startknoten. n f inal ∈ N ist der Endeknoten. Knoten stellen Anweisungen dar. Eine gerichtete Kante von einem Knoten i zu einem Knoten j beschreibt einen möglichen Kontrollfluss von Knoten i zu Knoten j (Abb. 8.1).

Knoten = Kreis = Anweisung

Die gerichteten Kanten werden als Zweige bezeichnet. Eine alternierende Sequenz aus Knoten und Anweisungen, die mit dem Startknoten nstart beginnt und mit dem Endeknoten nfinal endet, heißt Pfad. Der Pfad nstart , n1 , n2 , n f inal ist in Abb. 8.1 fett dargestellt.

Kante = Pfeil = Zweig

Ein Segment – auch Block genannt – ist eine alternierende Folge von Knoten und Kanten mit maximaler Länge, die folgende Eigenschaften besitzt:

Segment = Anweisungssequenz ohne Verzweigung

>

Sie kann ausschließlich über den ersten Knoten des Segments betreten werden.

>

Falls der erste Knoten des Segments durchlaufen wird, so werden alle Knoten des Segments in der vorgesehenen Reihenfolge genau einmal durchlaufen.

Für einige Anwendungen ist eine modifizierte Form des Kontrollflussgraphen erforderlich. Aus diesem Grund sind unterschiedliche Ausprägungen entstanden. Eine häufig benutzte Darstellung fasst Segmente zu einem Knoten zusammen. Dabei bleiben die Knoten nstart und n f inal jeweils einzeln stehen. Eine weitere Vereinfachung des Kontrollflussgraphen entsteht durch Verzicht auf jene Knoten, die keiner Anweisung entsprechen sondern lediglich zur Zusammenführung von Ästen des Kontrollflussgraphen dienen. Für den dynamischen Test ist es sinnvoll, dass jeder Knoten des Kontrollflussgraphen eine ausführbare Anweisung darstellt. Diese Form wird in Kapitel 3 zur Verdeutlichung der kontrollflussorientierten Testverfahren verwendet (Abb. 8.2).

8.3 Diagramme und Tabellen

277

Pfad

nstart Segment

void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl) { char Zchn; cin >> Zchn;

n1

Zweig, Kante Anweisung, Knoten

while ((Zchn >=‘A‘) && (Zchn > Zchn; } nfinal

}

Abbildung 8.1 Kontrollflussgraph zu ZaehleZchn

n1

nstart void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl) { char Zchn; cin >> Zchn; while ((Zchn >=‘A‘) && (Zchn > Zchn;

n5

} nfinal }

Abbildung 8.2 Kontrollflussgraph – komprimierte Segmente

278

8 Werkzeugunterstützte statische Codeanalyse

nstart

void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl)

nin

{ n1

char Zchn; cin >> Zchn;

n2

while ((Zchn >=‘A‘) && (Zchn > Zchn;

n6

} }

nout

nfinal

Abbildung 8.3 Kontrollflussgraph – Datenflussform ohne Datenflussattribute

Eine weitere Form des Kontrollflussgraphen führt die zusätzlichen Knoten nin und nout ein. Dies ist insbesondere für datenflussorientierte Prüfverfahren notwendig, um Zugriffe auf globale Variablen oder Parameterübergaben an eine Funktion zu beschreiben. Werden einer Funktion Daten aus der Umgebung über globale Variablen oder eine Parameterschnittstelle übergeben, so wird nach dem Knoten nstart der Knoten nin eingefügt, dem die Definitionen der entsprechenden Variablen zugeordnet werden. Exportiert eine Prozedur Daten, so wird vor dem Knoten n f inal der Knoten nout angeordnet, der eine Benutzung der entsprechenden Variablen enthält. Die datenflussorientierten Testverfahren fordern eine Darstellung entsprechend Abb. 8.3. Auch diese Datenflussform des Kontrollflussgraphen kann in den bereits dargestellten Ausprägungen vorliegen. So besteht z. B. die Möglichkeit Segmente zu jeweils einem Knoten zusammenzufassen.

Eingabeparameter = Definition (def) in nin Ausgabeparameter = Referenz (r, c-use) in nout

Die datenflussorientierten Testverfahren verwenden die Zugriffe auf Variablen zur Erzeugung von Testfällen /Rapps, Weyuker 82/, /Rapps, Wey-

8.3 Diagramme und Tabellen

279

Datenflussform des Kontrollflussgraphen

Datenflussattribute

uker 85/, /Ntafos 84/, /Laski, Korel 83/, /Clarke et al. 89/. Dieser Bezug auf die Daten setzt eine grundsätzlich andere Sichtweise des Programms voraus. Jedes Software-Modul verwendet Kontrollstrukturen zur Verarbeitung von Daten. Die Definition von Testverfahren, die sich auf die Daten – oder genauer den Datenfluss – stützen, ist daher eine Alternative zu Tests, die die Kontrollstrukturen nutzen. Zur Verdeutlichung der Arbeitsweise der datenflussorientierten Testverfahren wird eine modifizierte Form des Kontrollflussgraphen verwendet, der in Abhängigkeit des gewählten Testverfahrens in unterschiedlichen Ausprägungen vorliegen kann. Die Datenflussdarstellung des Kontrollflussgraphen besitzt die folgenden zusätzlichen Merkmale im Vergleich zu der Grundform, die im Rahmen der kontrollflussorientierten Tests verwendet wird: >

Es werden so genannte Datenflussattribute hinzugefügt, die den Knoten bzw. Kanten des Kontrollflussgraphen zugeordnet sind und angeben, welche Variablen in welcher Weise zugegriffen werden.

>

Man unterscheidet:

>

–

Schreibende Zugriffe (def)

–

Lesende Zugriffe in Berechnungen (c-use)

–

Lesende Zugriffe in Entscheidungen (p-use)

Definitionen (defs) und c-uses werden den Knoten des Kontrollflussgraphen zugeordnet. p-uses ordnet man den Kanten des Kontrollflussgraphen zu, die den Knoten verlassen, in dem der Variablenzugriff innerhalb einer Entscheidung stattfindet. –

BEISPIEL

Die Knoten nin und nout werden zur Beschreibung des Informationsimports und des Informationsexports über Parameter oder globale Variablen hinzugefügt (Abb. 8.4).

Dem Knoten 3 des Kontrollflussgraphen in Abb. 8.4 sind die Datenflussattribute c-use (Gesamtzahl) und def (Gesamtzahl) zugeordnet. Zunächst wird der Wert der Variablen Gesamtzahl auf der rechten Seite der Zuweisung gelesen, ohne ihn zu verändern (c-use). Anschließend wird der Variablen Gesamtzahl auf der linken Seite der Zuweisung ein neuer Wert zugeordnet (def). Den Kanten zwischen den Knoten 4 und 5 und den Knoten 4 und 6 sind p-uses der Variable Zchn zugeordnet, da sie den Knoten 4 verlassen. Dieser Knoten stellt die Entscheidung dar, in der der Wert der Variable Zchn gelesen wird.

280

8 Werkzeugunterstützte statische Codeanalyse

nstart

def (Gesamtzahl) def (VokalAnzahl)

nin

void ZaehleZchn (int &VokalAnzahl, int & Gesamtzahl) {

def (Zchn)

p-use (Zchn) p-use (Gesamtzahl) c-use (Gesamtzahl) def (Gesamtzahl)

n1

char Zchn; cin >> Zchn;

n2

while ((Zchn >=‘A‘) && (Zchn > Zchn;

n6

} c-use (VokalAnzahl) c-use (Gesamtzahl)

nout

}

nfinal

Abbildung 8.4 Kontrollflussgraph – Datenflussdarstellung

8.3.2.2

Programmablaufplan

Der Programmablaufplan (PAP) – auch Flussdiagramm genannt – ist dem Kontrollflussgraphen ähnlich. Berechnungen werden durch rechteckige Felder dargestellt. Eingabe- oder Ausgabeanweisungen werden durch ein Parallelogramm beschrieben. Häufig findet keine Differenzierung zwischen Berechnungen und Ein-/Ausgabeanweisungen statt, so dass beides als Rechteck dargestellt wird. Verzweigungen werden als Rauten notiert. Kontrollflüsse zwischen Anweisungen, Verzweigungen oder Anweisungen und Verzweigungen werden durch gerichtete Kanten beschrieben. Ovale Felder dienen zur Aufnahme des Startsymbols und des Stopsymbols. Umfangreiche Programmablaufpläne können zerteilt werden. Die Zuordnung der losen Enden geschieht durch kreisförmige Verbinder. Die Verwendung des Programmablaufplans ist im Rahmen des strukturorientieren Tests unüblich. Sowohl Programmablaufpläne als auch Kontrollflussdiagramme gestalten die Darstellung nicht linearer Kontrollstrukturen (beliebige Sprünge der Verarbeitungslogik). Abb. 8.5 zeigt die Darstellung von ZaehleZchn als Programmablaufplan.

8.3 Diagramme und Tabellen

Programmablaufpläne sind im Test unüblich.

281

Abbildung 8.5 Programmablaufplan zu ZaehleZchn

8.3.2.3 Nassi-ShneidermanDiagramme erzwingen einen linearen Kontrollfluss.

Nassi-Shneiderman-Diagramm

Nassi-Shneiderman-Diagramme (Abb. 8.6) bieten Beschreibungsmöglichkeiten für die strukturierten Sprachkonstrukte Sequenz, Aufruf, Auswahl und Wiederholung /Nassi, Shneiderman 73/. Da sie andere Konstrukte nicht bieten, stellt die Verwendung von Nassi-Shneiderman-Diagrammen im Vorfeld einer Implementation die Realisierung eines strukturierten Programms sicher. Sie eignen sich leider nur unzureichend zur Verdeutlichung der Arbeitsweise von Prüfverfahren. Sie gestatten keine direkte Identifikation von Programmelementen, die für die Prüfung der Software wichtig sind, wie z. B. Zweige. Da dieser Aspekt insbesondere für die strukturorientierten Testverfahren wesentlich ist, wird auch für strukturierte Sprachen im Rahmen eines strukturorientierten Tests der Kontrollflussgraph benutzt. 8.3.2.4

Strukturdiagramm = Aufrufdiagramm = structure chart

282

Strukturdiagramm

Strukturdiagramme (structure charts) werden auch als Aufrufdiagramme bezeichnet. Sie dienen der Darstellung von Aufrufbeziehungen zwischen Funktionen und werden als Darstellungsmittel im Bereich des Integrationstests verwendet. Funktionen werden als benannte Rechtecke dar-

8 Werkzeugunterstützte statische Codeanalyse

Abbildung 8.6 Nassi-Shneiderman-Diagramm zu ZaehleZchn

gestellt. Pfeile repräsentieren Aufrufbeziehungen. Die Pfeilspitze ist auf den jeweiligen Dienstanbieter gerichtet. Zusätzliche Notationselemente gestatten es, bedingte und wiederholte Aufrufe zu beschreiben. Außerdem können die entlang einer Aufrufbeziehung fließenden Daten und Kontrollinformationen dargestellt werden. Daten sind anhand des nicht ausgefüllten Kreises am Pfeilende erkennbar. Eine Kontrollinformation besitzt einen ausgefüllten (schwarzen) Kreis am Pfeilende. Abb. 8.7 beschreibt die folgende Situation: Modul A ruft Modul B auf. Dabei wird das Datum w übergeben. Das Kontrollflag f wird zurückgeliefert. Anschließend wird in Abhängigkeit von einer Bedingung ggf. Modul C aufgerufen. Dabei wird das Datum x übergeben und das Datum y zurückgeliefert. Schließlich wird ggf. wiederholt das Modul D aufgerufen, dem das Datum z übergeben wird, das mit einem ggf. modifizierten Wert zurückgeliefert wird. Strukturdiagramme werden verbreitet als Entwurfshilfsmittel verwendet. Die entsprechende Entwurfstechnik heißt strukturierter Entwurf (Structured Design (SD). Einige Testwerkzeuge erzeugen Strukturdiagramme als Hilfsmittel für den Integrationstest automatisch aus Quellcode. Es werden jedoch in der Regel nur grundsätzliche Aufrufbeziehungen dargestellt. Bedingte oder iterative Aufrufe werden in der Regel von einfachen Aufrufen nicht unterschieden. Außerdem werden die übergebenen Daten und Steuerinformationen nicht ausgewiesen. Eine automatische Unter-

Abbildung 8.7 Strukturdiagramm

8.3 Diagramme und Tabellen

283

scheidung von Daten und Steuerinformationen ist mit Mitteln der statischen Analyse grundsätzlich schwierig.

8.3.3 Tabellarische Darstellungen werden verbreitet genutzt.

Variablen-CrossReference-Tabelle

Tabellen

Im Bereich der statischen Analyse werden zahlreiche tabellarische Darstellungen verwendet. Aus der Vielzahl der Möglichkeiten wird im Folgenden beispielhaft eine Tabelle ausgewählt, für deren Erzeugung zahlreiche Werkzeuge verfügbar sind. Es handelt sich um die so genannte Variablen-Cross-Reference-Tabelle. Die Variablen-Cross-Reference-Tabelle ordnet z. B. den Spalten der Tabelle die verwendeten Variablen und den Zeilen der Tabelle die existierenden Module (Funktionen) zu. Ein Tabelleneintrag gibt jeweils an, ob eine Funktion eine Variable >

liest,

>

schreibt,

>

liest und schreibt oder

>

nicht zugreift.

In Tab. 8.1 ist ein Beispiel einer Variablen-Cross-Reference-Tabelle angegeben. Besonders hilfreich ist es, wenn in dieser tabellarischen Darstellung zusätzlich die Sichtbarkeitsbereiche von Variablen unterschieden werden. Für den Fall, dass eine Variable von einer Funktion nicht zugegriffen wird, wird folglich angegeben, ob ein Zugriff möglich wäre und nicht erfolgt, oder ob auf Grund von Sichtbarkeitsgrenzen ein Zugriff prinzipiell nicht möglich ist. Variablen-Cross-Reference-Tabellen sind ein hervorragendes Hilfsmittel für die Fehlersuche auf dem Integrationstestniveau. So kann z. B. mit einem Blick festgestellt werden, welche Funktionen eine bestimmte Variable schreiben (definieren) und aus diesem Grund als Verursacher eines falschen Wertes in Frage kommen.

Tabelle 8.1 Variablen-Cross-Referenz-Tabelle

284

8 Werkzeugunterstützte statische Codeanalyse

8.3.4

Bewertung der Nutzung von Diagrammen und Tabellen

Die Verwendung von grafischen Beschreibungsmitteln ist Stand der Technik bei der Entwicklung und Prüfung von Software. Bei der Entwicklung werden jedoch häufig andere Grafiken verwendet als bei der Prüfung. So wird man z. B. bei der Konzeption der Verarbeitungslogik eines Moduls Nassi-Shneiderman-Diagramme verwenden, um einen linearen Kontrollfluss zu garantieren. Als Hilfsmittel zur Darstellung eines so genannten Zweigüberdeckungstests wird man Kontrollflussgraphen vorziehen, die automatisch aus dem Software-Quellcode erzeugt werden können und eine gute Erkennung der zu überdeckenden Zweige ermöglichen. Dass Kontrollflussgraphen grundsätzlich auch nicht-lineare Kontrollflüsse darstellen können, wirkt nicht nachteilig, da sie nur zur Darstellung vorhandener Kontrollstrukturen dienen. Eine Visualisierung von Informationen mit Grafiken ist insbesondere als Bestandteil dynamischer Tests unverzichtbar. Die Generierung der entsprechenden grafischen Darstellungen ist als Bestandteil in die Testwerkzeuge integriert. Die Verwendung tabellarischer Darstellungen – z. B. der Variablen-Cross-Reference-Tabelle – ist üblich. Die automatische Erzeugung entsprechender Tabellen erfordert einen sehr geringen Aufwand. Sie enthalten Informationen, die z. B. im Falle der Variablen-Cross-Reference-Tabelle sehr hilfreich für die Fehlersuche sind.

8.4 8.4.1

Slicing Eigenschaften und Ziele des Slicings

Slicing zielt auf die weitgehend automatische Bereitstellung von Informationen über Wirkzusammenhänge in einem betrachteten Programm. Die Arbeitsweise ist vergleichbar mit der manuellen Fehlersuche (Debugging) nach dem Auftreten eines Fehlverhaltens. Debugging ist auch der typische Anwendungsbereich für automatisches Slicing.

Slicing besitzt Ähnlichkeiten zum manuellen Debugging.

Ein Program Slice in dem hier verwendeten Sinne beschreibt, welche Anweisungen auf welche Weise einen betrachteten Wert beeinflussen. Ein Slice wird also stets in Bezug auf einen betrachteten Wert an einer bestimmten Stelle des Programms angegeben. Streng genommen ist dies die Definition des so genannten rückwärtsgerichteten (backward) Slicing. Es gibt auch forward Slicing. Ein derartiger Slice stellt dar, welche Anweisungen auf welche Weise von einem betrachteten Wert beeinflusst werden. Rückwärtsgerichtetes Slicing entspricht der Analyse, die bei der manuellen Ursachensuche für ein betrachtetes Fehlverhalten durchgeführt wird. Zunächst wird man prüfen, ob das Fehlverhalten durch die aktuell betrachtete Anweisung verursacht wurde. Ist das nicht der Fall, so werden die Anweisungen überprüft, die für die Anweisung Daten liefern

Backward Slicing vs. Forward Slicing

8.4 Slicing

285

oder ihre Ausführung steuern. Dieses Verfahren kann fortgesetzt werden, bis keine Vorgänger mehr existieren, also Eingabeanweisungen erreicht werden. Der so erzeugte Slice enthält alle potentiellen Verursacher des fehlerhaften Wertes an der betrachteten Stelle. Durch das Slicing liegt die folgende Information in komprimierter Form vor:

Slicing reduziert den Aufwand bei der Fehlersuche.

>

Anweisungen, die den Wert einer betrachteten Variable an einer bestimmten Stelle beeinflussen können

>

Beteiligte Variablen und Datenflüsse

>

Kontrolleinflüsse

Alle Anweisungen, die nicht Bestandteil des Slices sind, müssen bei der Fehlersuche nicht geprüft werden. Durch automatisches Slicing kann daher der Aufwand der Fehlersuche reduziert werden.

8.4.2

Statisches Slicing

Man unterscheidet statisches und dynamisches Slicing /Korel, Laski 88/. Statisches Slicing kann im Sinne der statischen Analyse durchgeführt werden. Es ist nicht erforderlich, das Programm auszuführen oder Annahmen über Werte von Variablen zu treffen. Das ist kritisch, wenn sich Abhängigkeiten nur aus dem konkreten Wert eines Datums ergeben. Derartige Situationen entstehen z. B. im Zusammenhang mit der Verwendung von Zeigern oder Feldern. Abhilfe bietet das so genannte dynamische Slicing, das in Unterabschnitt 8.4.3 diskutiert wird. Ausgangsbasis: Kontrollflussgraph mit Datenflussattributen

Eine geeignete Ausgangsbasis für die Darstellung des statischen Slicings bildet der durch statische Analyse erzeugbare, um Datenflussattribute erweiterte Kontrollflussgraph, der auch als Basis für datenflussorientiertes Testen verwendet wird (siehe 8.3.2.1). Den Anweisungen (Knoten) des Kontrollflussgraphen werden Datenflussattribute zugeordnet, die die Art der in den Anweisungen enthaltenen Datenzugriffe beschreiben. Es werden schreibende Zugriffe und lesende Zugriffe unterschieden. Schreibzugriffe werden als Definition (def, d) bezeichnet. Lesende Zugriffe heißen Referenz. Erfolgt ein lesender Zugriff in einer Entscheidung, so spricht man von einer prädikativen Referenz (p-use, predicate use, p). Ein lesender Zugriff in einer Berechnung wird als berechnende Referenz (c-use, computational use, c) bezeichnet. Der Kontrollflussgraph in Abb. 8.8 ist an ein Beispiel aus /Korel 87/ angelehnt. Der Slice wird oft ebenfalls grafisch notiert. Die Anweisungen werden als Knoten mit der gleichen Nummerierung angegeben wie im Kontrollflussgraph. Durchgezogene Kanten stellen eine Datenabhängigkeit dar. Kontrollabhängigkeiten werden mit gestrichelten Kanten angegeben. Für die beiden Kantentypen gelten die folgenden Definitionen:

286

8 Werkzeugunterstützte statische Codeanalyse

input(n);

1

d(n)

input(a);

2

d(a)

max :=0;

3

d(max)

sum :=0;

4

d(sum)

i := 1;

5

d(i)

WHILE i

Kontrollkanten sind von Anweisungen, die eine prädikative Referenz enthalten (Auswahlkonstrukte, Schleifensteuerung), auf die unmittelbar kontrollierten Anweisungen gerichtet, d. h. auf jene Anweisungen, die nur ausgeführt werden, wenn das Prädikat einen bestimmten Wert hat. Kontrollkanten werden nur zwischen der kontrollierenden Anweisung und unmittelbar eingeschachtelten Anweisungen gezogen. Ist in einem kontrollierten Block eine weitere Kontrollebene eingeschachtelt, so werden keine Kontrollkanten gezogen, die mehr als eine Ebene überstreichen. Da die Kontrollbeziehung transitiv ist, kann diese mittelbare Kontrolle aus dem Slice durch Ausnutzung der Transitivität geschlossen werden.

Kontrollkanten eines Slices

>

Datenflusskanten sind von Anweisungen, in denen eine Variable definiert wird, auf Anweisungen gerichtet, in denen diese Variable referenziert wird. Die betrachtete Variable darf zwischen der Definition und der Referenz nicht erneut definiert werden. Man bezeichnet das als definitionsfreien Pfad bezüglich der betrachteten Variablen.

Datenflusskanten eines Slices

8.4 Slicing

287

Algorithmus für die Erzeugung von Slices

BEISPIEL

Der rückwärtsgerichtete Slice wird ermittelt, indem ausgehend von der Anweisung mit der betrachteten Variablenreferenz der Kontrollflussgraph gegen die Kantenrichtung nach Definitionen der betrachteten Variable durchsucht wird. Existieren zu den Definitionen berechnende Referenzen, so wird das Verfahren rekursiv fortgesetzt, bis keine zusätzlichen Knoten mehr gefunden werden. Die so gefundenen Abhängigkeiten zwischen Anweisungen sind Datenabhängigkeiten. Befindet sich ein betrachteter Knoten in einem Block, dessen Ausführung von einer Entscheidung direkt gesteuert wird, so ist dies eine Kontrollabhängigkeit. Für die prädikativen Referenzen der in der Entscheidung beteiligten Variablen werden Knoten mit entsprechenden Definitionen – also Datenflussabhängigkeiten – rekursiv gesucht, die eventuell weitere Kontrollabhängigkeiten besitzen.

Für die Ausgaben des in Abb. 8.8 als Kontrollflussgraph dargestellten Softwaremoduls erhält man die rückwärtsgerichteten Slices nach Abb. 8.9 und Abb. 8.10. Abb 8.9 stellt den rückwärtsgerichteten Slice für die Variable max in Knoten 12 dar. Man erkennt, dass der Wert der Variable max von den Anweisungen 4, 9, 11 und 13 nicht beeinflusst wird, weil diese Knoten nicht Bestandteil des Slices sind. Bei der Suche nach fehlerhaften Anweisungen, die den Wert von max verfälschen, können diese Anweisungen unberücksichtigt bleiben. Abb. 8.10 gibt den rückwärtsgerichteten Slice für die Variable avr in Knoten 13 an. Auch hier ist der Suchraum für Fehler eingeschränkt, da die Anweisungen 3, 7, 8 und 12 ohne Wirkung auf den Wert der Variable avr sind.

Abbildung 8.9 Slice der Ausgabe max

Abb. 8.11 stellt den vorwärtsgerichteten Slice der Variable sum in Knoten 4 dar. Fehler in dieser Anweisung könnten lediglich Werte beeinflussen, die in den Anweisungen 9, 11 und 13 bestimmt werden. Fehler in Anweisung 4 könnten den Ausgabewert von avr in Knoten 13 beeinflussen. Ein Einfluss auf den Ausgabewert max ist dagegen ausgeschlossen.

288

8 Werkzeugunterstützte statische Codeanalyse

Abbildung 8.10 Slice der Ausgabe avr 4

d(sum)

9

c(sum) d(sum)

11

c(sum) d(avr)

13

c(avr)

Abbildung 8.11 Vorwärts-Slice zu sum in Knoten 4

8.4.3

Dynamisches Slicing

Ein gemeinsamer Nachteil aller statischer Verfahren ist, dass Informationen, die erst zur Laufzeit dynamisch entstehen, nicht vollständig beachtet werden können. Dieser Nachteil betrifft auch das statische Slicing. Effekte, die z. B. durch dynamische Datenstrukturen oder strukturierte Datentypen entstehen, werden nicht korrekt berücksichtigt. Der Slice ist in derartigen Situationen oft erheblich zu umfangreich.

Statisches Slicing kann einige Aspekte nicht korrekt beachten.

Darüber hinaus existieren weitere Schwierigkeiten, die durch die Verarbeitungslogik verursacht werden. Im Einzelnen betrifft das die Bestimmung von komponentenübergreifenden Slices und die Berücksichtigung von Sprunganweisungen. Beide Probleme können gelöst werden. Ferner ist davon auszugehen, dass in moderner, mit linearen Kontrollstrukturen erstellter Software Sprunganweisungen keine wesentliche Bedeutung besitzen. In Sprunganweisungen sind keine Variablen beteiligt, so dass sie durch das beschriebene Verfahren zur Erzeugung von Slices nicht erkannt werden. Eine Lösungsmöglichkeit für dieses Problem ist in /Agrawal 94/ beschrieben.

Dynamisches Slicing ist für eine bestimmte betrachtete Situation genauer, dafür aber weniger allgemeingültig als statisches Slicing.

8.4 Slicing

289

Die Schwierigkeiten, die z. B. dynamische Datenstrukturen im statischen Slicing verursachen, sind mit statischen Techniken prinzipiell nicht vollständig lösbar. Einen Ausweg bietet die Betrachtung einer bestimmten Programmausführung mit konkreten Eingabewerten, im Sinne eines dynamischen Testfalls. Da in diesem Fall eine eindeutig festgelegte Situation auch für die beteiligten dynamischen Datenstrukturen oder strukturierte Daten (z. B. Felder) vorliegt, können die Wirkzusammenhänge zwischen Anweisungen korrekt als Slice extrahiert werden. Einerseits beseitigt dynamisches Slicing die beschriebenen Probleme des statischen Slicings. Andererseits gehört diese Technik streng genommen nicht mehr zur statischen Analyse. Der dynamische Slice ist nur für die betrachtete Situation gültig. Er stellt einen Sonderfall dar. Dynamisches Slicing löst im Vergleich zum statischen Slicing einige Probleme. Es verliert aber die Allgemeingültigkeit der erzeugten Aussagen.

Abbildung 8.12 Ausschnitt eines Kontrollflussgraphen

Abb. 8.12 zeigt einen Ausschnitt eines Kontrollflussgraphen mit Datenflussattributen. Zunächst werden die Werte der Elemente des Feldes a eingegeben. Anschließend werden die Werte i und j eingegeben, die später als Indizes für Feldzugriffe verwendet werden, sowie ein Wert x. Abb. 8.13 zeigt den statischen Slice für die Variable y in Anweisung 6. Einerseits kann nicht ausgeschlossen werden, dass bei der Ausführung des Programms die Werte der Variablen i und j identisch sind. Darum existiert eine Datenflussabhängigkeit zwischen den Knoten 5 und 6. Andererseits ist es möglich, dass die Werte von i und j unterschiedlich sind. In diesem Fall wird y ein in Anweisung 1 eingegebener Wert zugewiesen. Daher existiert eine Datenflussabhängigkeit zwischen den Knoten 1 und 6. Da die beiden Bedingungen i = j und i = j einander ausschließen, ist der statische Slice für jede konkrete Programmausführung zu

290

8 Werkzeugunterstützte statische Codeanalyse

2

d (i)

4

d (x)

3

d (j)

5

c (x, i) d (a)

6

c (a, j) d (y)

1

d (a)

Abbildung 8.13 Statischer Slice für y in Knoten 6

umfangreich. Für alle Programmausführungen, bei denen i und j identische Werte besitzen, gilt der dynamische Slice nach Abb. 8.14, der die Anweisungen 2, 3, 4, 5 und 6 enthält. Für alle anderen Programmausführungen gilt der dynamische Slice nach Abb. 8.15, der die Anweisungen 1, 3 und 6 enthält. Durch die Betrachtung konkreter Situationen kann der Umfang des Slices jeweils deutlich reduziert werden. 2

d (i)

4

d (x)

3

d (j)

5

c (x, i) d (a)

6

c (a, j) d (y)

Bedingung: i=j

Abbildung 8.14 Dynamischer Slice für y in Knoten 6 mit i = j

Abbildung 8.15 Dynamischer Slice für y in Knoten 6 mit i = j

8.4.4

Bewertung des Slicings

Slicing ist besonders bei komplizierten, unübersichtlichen Programmen ein geeignetes Analysemittel. In erster Linie kann Slicing die Fehlersuche unterstützen. Darüber hinaus ist Slicing ein Hilfsmittel für die Identifikation von Verarbeitungssträngen in Programmen. Dieses Einsatzgebiet

8.4 Slicing

Slicing unterstützt die Fehlersuche

291

Slicing unterstützt das Verstehen von Programmen

Statisches Slicing für das Verstehen; dynamisches Slicing für die Fehlersuche

tritt in der Wartungsprogrammierung oder bei der Restrukturierung von Software auf; also stets dort, wo das Ziel das Verstehen von Software ist. Slicing ist ein recht universelles Analyseinstrument für Software. Eine Anwendung aus der Sicherheitstechnik ist in /Liggesmeyer 00/ beschrieben. Dort wird Slicing eingesetzt, um so genannte Fehlerbäume für Steuerungssoftware zu erzeugen. Bei der Verwendung des Slicings zum Verstehen von Programmen wird man statisches Slicing anwenden. So ist die Antwort auf die Frage, welche Anweisungen grundsätzlich zur Berechnung eines bestimmten Ausgabewertes beitragen können, nicht an eine bestimmte Verarbeitung geknüpft. Wird Slicing als Hilfsmittel zur Fehlersuche verwendet, so ist dynamisches Slicing besser geeignet. Das Fehlverhalten ist schließlich bei einem ganz bestimmten Fall der Programmausführung aufgetreten. Für diese Ausführung muss der Slice ermittelt werden, so dass dem Slicing die konkreten Werte der beteiligten Variablen zugrunde gelegt werden können.

8.5 8.5.1

Datenflussanomalieanalyse Eigenschaften und Ziele der Datenflussanomalieanalyse

Statische Fehleranalyse: Fehlerfindung ohne Programmausführung

Bestimmte Software-Fehler können ohne Programmausführung rein statisch – quasi durch sorgfältiges Hinsehen – erkannt werden. Man bezeichnet diese Techniken als statische Fehleranalysen. Ein gewisser Teil dieser statischen Prüfungen wird bereits von Compilern durchgeführt. Dies gilt z. B. für die Überprüfung der Schnittstellen von Operationen auf Konsistenz zwischen formalen und aktuellen Parametern.

Programmiersprachen ermöglichen durch Redundanz Fehlererkennung.

Die automatische, statische Fehlererkennung wird durch Eigenschaften moderner Programmiersprachen unterstützt. Durch gezielte Nutzung von Redundanz – die einen gewissen Mehraufwand in der Programmierung verursacht – werden automatische Prüfungen durch eine statische Fehleranalyse des Compilers möglich. So enthalten im Grunde kontextfreie Programmiersprachen – wie Pascal – kontextsensitive Elemente, die z. B. durch die Forderung zur Deklaration aller verwendeten Variablen entstehen. Dieser sprachliche Mehraufwand gestattet erst die Konsistenzprüfung zwischen Variablenbenutzungen und ihren Deklarationen. Fehler können so direkt entdeckt werden. Durch die Möglichkeit zur Bildung von Prozeduren und Funktionen mit formalen Parametern gestatten moderne Programmiersprachen die Entdeckung von Schnittstellenanomalien, also eine Inkonsistenz zwischen Art, Anzahl oder Form der Benutzung der formalen und aktuellen Parameter.

Anomalie = Abweichung

Eine Anomalie ist jede Abweichung bestimmter Eigenschaften eines Programms oder Moduls von der korrekten Ausprägung dieser Eigenschaf-

292

8 Werkzeugunterstützte statische Codeanalyse

ten. In einigen Fällen ist keine unmittelbare Fehlererkennung, jedoch eine Identifikation von Fehlersymptomen möglich. Eine Anomalie ist stets eine verdächtige Stelle in einem Programm. Eine Form der Anomalieprüfung, die auch von einigen Compilern durchgeführt wird, ist die Datenflussanomalieanalyse /Taylor, Osterweil 80/, /Wilson, Osterweil 85/. Datenflüsse kennen Sie bereits aus dem Kapitel über den datenflussorientierten dynamischen Test und den vorhergehenden Abschnitten dieses Kapitels. Zur Erinnerung: Datenflüsse entstehen durch die Umsetzung von Eingabewerten in Ausgabewerte über Zwischenergebnisse. Die Verarbeitungssteuerung übernehmen die Kontrollstrukturen der Software unter Nutzung der Datenwerte. Die Eingabedaten werden gelesen, um Zwischenergebnisse zu bestimmen, die in den Speicher geschrieben werden, um anschließend wieder gelesen und über weitere Zwischenschritte schließlich in Ausgabewerte umgesetzt zu werden. Die Daten „fließen“ quasi durch die Software; von Eingaben zu Ausgaben. In den Datenflüssen können Stellen enthalten sein, die fehlerhaft oder zumindest verdächtig sind. Diese Stellen werden als Datenflussanomalien bezeichnet. Nicht alle Datenflussanomalien bewirken notwendigerweise ein funktionales Fehlverhalten.

8.5.2

Datenflüsse

Durchführung der Datenflussanomalieanalyse

Der Datenfluss wird für eine bestimmte betrachtete Variable stets entlang einer Ausführung – also eines Pfades – betrachtet. Bei einer vollständigen Programmausführung vom Start des Programms bis zu seiner Terminierung sind alle Daten zu Beginn und am Ende undefiniert. Sie existieren nicht im Speicher. Mit dem Programmstart werden die ersten Variablen im Speicher angelegt, und mit dem Fortschritt der Programmabarbeitung kommen weitere hinzu, z. B. lokale Variablen in Funktionen, die typischerweise bereits am Ende der Abarbeitung der Funktion wieder zerstört werden. Der Speicherplatz wird wieder freigegeben; die Variable ist undefiniert. Dieser Sachverhalt gilt nicht nur für das Gesamtprogramm sondern auch für alle seine Teile (z. B. einzelne Funktionen). Eine Variable, die als Folge der Abarbeitung Ihrer Deklaration im Speicher angelegt worden ist, ist aber noch undefiniert. Ein Beispiel für diese Situation ist ein Zeiger (pointer), der im Speicher bereits angelegt ist aber noch keinen gültigen Wert besitzt. Er ist undefiniert. Definiert ist eine Variable erst nach der ersten Wertzuweisung, z. B. ihrer Initialisierung. Aus diesem Grund ist es sicher ein Fehler, den Wert einer im Speicher existierenden Variable zu lesen und weiterzuverarbeiten, bevor sie initialisiert wurde. Dies ist eine so genannte ur-Datenflussanomalie.

Undefinition: engl. undefinition kurz: u

ACHTUNG: Die Begriffe Deklaration und Definition werden teilweise auch anders gebraucht.

Der Datenfluss für eine Variable x ist auf einem Pfad des Kontrollflussgraphen durch die Aktionen, die mit x durchgeführt werden, festgelegt.

8.5 Datenflussanomalieanalyse

293

ACHTUNG: Deklarationen und Definitionen sind keine Synonyme.

Die Variable x kann entlang einer Programmausführung also angelegt oder zerstört werden und dazwischen schreibend oder lesend zugegriffen werden. Schreibende Zugriffe können den Wert der Variable verändern. Sie werden – wie beim datenflussorientierten dynamischen Test – als Definition bezeichnet. Lesende Zugriffe können den Wert der Variable nicht verändern. Man bezeichnet sie als Referenz. Die folgenden Datenflussattribute können den Knoten des Kontrollflussgraphen bezüglich der Variable x zugeordnet sein:

Definition; kurz: d

>

x wird definiert. Der Variable x wird ein Wert zugewiesen (z. B. x = 5;).

Referenz; kurz: r

>

x wird referenziert. Der Wert der Variable x wird in einer Berechnung oder einer Entscheidung gelesen, d. h. der Wert von x verändert sich nicht (z. B. y = x + 1; oder i f (x > 0) ...).

Undefinition; kurz: u

>

x wird undefiniert. Der Wert der Variable x wird zerstört (z. B. Zerstörung lokaler Variablen beim Beenden einer Funktion). Am Programmbeginn befinden sich alle Variablen im Zustand undefiniert.

>

x wird nicht benutzt (empty). Die Anweisung des Knotens beeinflusst die Variable x nicht. x wird nicht definiert, referenziert oder undefiniert.

Die Datenflussattribute werden abkürzend oft in der Form d (defined), r (referenced), u (undefined) und e (empty) notiert. Die leere Aktion (e) kann vernachlässigt werden, da sie für den Datenfluss keine Auswirkungen besitzt.

BEISPIEL

Betrachten wir die zwei folgenden Zugriffssequenzen auf eine Variable (u: Undefinition, d: Definition, r: Referenz): 1. u r d r u 2. u d d r d u Die Sequenz 1 beginnt mit ur. Die betrachtete Variable besitzt zum Zeitpunkt der Referenz einen zufälligen Wert, da sie nicht zuvor definiert wurde. Es liegt eine Datenflussanomalie des Typs ur vor; die Referenz einer Variable mit undefiniertem, zufälligem Wert. Die Sequenz 2 enthält zwei aufeinanderfolgende Variablendefinitionen. Die erste Definitionen besitzt keine Wirkung, da der Wert stets durch die zweite Definition überschrieben wird. Die Datenflussanomalie ist vom Typ dd.

294

8 Werkzeugunterstützte statische Codeanalyse

Die Sequenz 2 endet mit einer Definition gefolgt von einer Undefinition. Der durch die Definition zugewiesene Wert wird nicht benutzt, da er anschließend sofort zerstört wird. Diese Datenflussanomalie ist vom Typ du.

Betrachtet man die Ausführung eines Programms, so kann der Datenfluss bezüglich einer bestimmten Variablen durch eine Sequenz aus Definitionen, Referenzen und Undefinitionen dargestellt werden.

Abbildung 8.16 Zustandsautomat zur Datenflussanomalieanalyse

Der in Abb. 8.16 angegebene Zustandsautomat beschreibt den Vorgang der Datenflussanomalieanalyse. Ausgehend vom Startzustand S ist eine Variable zuerst undefiniert. Die Variable muss definiert werden, bevor sie referenziert werden darf. Ein korrekter Datenfluss verbleibt in den Zuständen definiert und referenziert, um mit einer Undefinition im Zustand undefiniert beendet zu werden. Jeder korrekte Datenfluss beginnt und endet im Zustand undefiniert und beachtet bestimmte Regeln, die der Zustandsautomat nach Abb. 8.16 beschreibt. Falls der Zustand Datenflussanomalie erreicht wird, oder am Ende einer Datenflussanomalieanalyse nicht der Zustand undefiniert erreicht wird, ist eine Datenflussanomalie erkannt. Der Zustandsautomat definiert eine so genannte reguläre Grammatik. Derartige Grammatiken sind ein Standardfall für Compilerbauer. Sie dienen in Compilern als Grundlage für die lexikalische Analyse. Daher kann die Datenflussanomalieanalyse durch compilerähnliche Werkzeuge durchgeführt werden oder als Teilfunktion in Compiler für Programmiersprachen integriert werden.

Zustandsautomat für die Datenflussanomalieanalyse

Im Folgenden ist als Beispiel die Operation MinMax angegeben. Diese Operation enthält Datenflussanomalien.

8.5 Datenflussanomalieanalyse

295

BEISPIEL

Die Operation MinMax erhält zwei Zahlen über eine Schnittstelle, die nach Größe sortiert zurückzugeben sind. void MinMax (int& Min, int& Max) { int Hilf; if (Min > Max) { Max = Hilf; Max = Min; Hilf = Min; } }

ur-Anomalie

dd-Anomalie

du-Anomalie

Die lokale Variable Hilf ist zunächst undefiniert. Falls Min größer als Max ist, so wird der Wert von Hilf der Variable Max zugewiesen. Der Wert von Hilf ist aber zufällig, da er weder initialisiert noch über die Schnittstelle übergeben worden ist. Diese Stelle der Operation ist also sicher fehlerhaft. Es liegt eine ur-Anomalie vor. Ebenfalls verdächtig sind die zwei direkt aufeinanderfolgenden Wertzuweisungen an die Variable Max. Die erste Wertzuweisung wird stets von der zweiten Wertzuweisung überschrieben, so dass die erste Wertzuweisung sinnlos ist. Es liegt eine dd-Anomalie vor. Eine zur ur-Anomalie spiegelsymmetrische Situation kommt durch die Wertzuweisung an Hilf zustande. Da Hilf nicht ausgegeben sondern am Ende der Operation zerstört wird, liegt hier eine du-Anomalie vor.

Abbildung 8.17 Kontrollflussgraph zur Operation MinMax

296

8 Werkzeugunterstützte statische Codeanalyse

Abb. 8.17 zeigt den Kontrollflussgraph mit Datenflussattributen zu MinMax. Da die Werte der Variablen Min und Max über die Schnittstelle in die Operation importiert werden, ist die Datenflussform des Kontrollflussgraphen zu wählen. Dem Knoten nin sind Definitionen von Min und Max zuzuordnen. Der Export von Min und Max beim Beenden der Operation wird durch die Zuordnung der entsprechenden Variablenreferenzen zum Knoten nout dargestellt. Den Knoten nstart und n f inal sind Undefinitionen aller Variablen zugeordnet. Auf diese Weise wird dargestellt, dass die Variablen am Prozedurbeginn einen undefinierten Wert besitzen und die Werte beim Verlassen der Prozedur zerstört werden. Die Operation MinMax enthält zwei Pfade. Tab. 8.2 stellt die Datenflussattribute der Variablen über den Pfaden dar. Die Sequenzen der Datenflussattribute sind nun für die zwei Pfade auf die Datenflussanomalien ur, dd und du zu durchsuchen. Da diese Suche für alle Variablen auf allen Pfaden durchgeführt wird, werden Anomalien sicher erkannt. Die Sequenz udrddru für die Variable Max enthält zwei direkt aufeinander folgende Definitionen – also eine Anomalie der Form dd. Die Sequenz urdu für Hilf beginnt mit einer ur-Anomalie – der Referenz einer undefinierten Variablen – und endet mit einer du-Anomalie – also einer Definition, die durch unmittelbar anschließende Zerstörung des Wertes unwirksam ist.

Import und Export Knoten

Sichere Erkennung von Datenflussanomalien

Tabelle 8.2 Datenflusstabelle der Operation MinMax

Die korrigierte Fassung der Operation lautet folgendermaßen: void MinMax (int& Min, int& Max) { int Hilf; if (Min > Max) { Hilf = Min; Min = Max; Max = Hilf; } }

Abb. 8.18 gibt den Kontrollflussgraphen dieser Operation an. Die Datenflüsse in Tab. 8.3 enthalten keine Anomalien.

8.5 Datenflussanomalieanalyse

297

Abbildung 8.18 Kontrollflussgraph zur korrigierten Operation MinMax

Tabelle 8.3 Datenflusstabelle der korrigierten Operation MinMax

8.5.3 Datenflussanomalieanalyse funktioniert auch bei unbeschränkter Pfadzahl.

298

Mögliche Probleme der Datenflussanomalieanalyse und ihre Behebung

Bisher ist davon ausgegangen worden, dass die Datenflussanomalieanalyse für alle Pfade durchgeführt werden muss. Dies ist aber glücklicherweise nicht korrekt. Sonst wäre das Verfahren bereits für kleine Software-Komponenten nicht mehr einsetzbar, weil die Anzahl der Pfade bereits in recht einfachen Programmen unbeherrschbar groß sein kann. Eine Ursache für die Explosion der Anzahl der Pfade sind Schleifen. Bei der Datenflussanomalienanalyse reicht es aus, die Pfade bis zum zweiten Schleifendurchlauf zu analysieren. Sind bis dort keine Datenflussanomalien aufgetreten, so ist sichergestellt, dass auch auf den Pfaden mit einer höheren Anzahl von Schleifeniterationen keine Anomalien auftreten werden. Dieser Sachverhalt wird im Folgenden verdeutlicht.

8 Werkzeugunterstützte statische Codeanalyse

Es wird eine Operation zur Bestimmung der Quadratwurzel durch das Näherungsverfahren der Newton’schen Iteration betrachtet. Die Operation soll für nicht-negative Eingaben die Quadratwurzel bestimmen. Für negative Eingaben soll der Wert 0.0 zurückgeliefert werden. Aufgrund des Näherungsverfahrens ist es schwierig, eine Abschätzung für die maximale Anzahl der Schleifenwiederholungen anzugeben. Dies verursacht eine potenziell unendliche Anzahl von Pfaden. double Sqrt(double X) { double returnValue; if (X > 0.0) { double W; while (ABS (W { W = W } returnValue = } else { returnValue = } return (returnValue); }

* W - X) > 0.01) - ((W * W - X) / (2.0 * W)); W;

0.0;

Abb. 8.19 zeigt den Kontrollflussgraphen mit Datenflussattributen der Operation Sqrt. Die Analyse des Pfades, der für nicht-positive Eingabewerte durchlaufen wird, ist recht einfach. Dies ist ein Beispiel für die Abweichung der Fallunterscheidung des Programms von den Fällen, die in der Spezifikation betrachtet werden. Die Spezifikation unterscheidet negative und nicht-negative Eingaben, während der Code nicht-positive und positive Eingaben unterscheidet. Die Eingabe 0 wird also unterschiedlich behandelt. Man erhält die folgenden Datenflüsse, die keine Anomalien enthalten: >

X: udru

>

W: uu

>

returnValue: udru

Für positive Eingaben wird das iterative Näherungsverfahren durchgeführt. Der Datenfluss für die Variable X beginnt mit der Teilsequenz udrr bis zur Schleifenentscheidung. Wird die Schleife nicht betreten, so schließt sich direkt die Teilsequenz u an. Wird die Schleife betreten, so schiebt sich die Teilsequenz rr dazwischen. Diese Teilsequenz wiederholt sich bei jedem weiteren Schleifendurchlauf. Daher können die Datenflüsse auf diesen Pfaden in geschlossener Form angegeben werden. Für die Variable X gilt der Datenfluss udrr(rr)n u mit n ≥ 0. Der Wert n gibt die

8.5 Datenflussanomalieanalyse

299

nstart

u (X), u (W), u (returnValue)

nin

d (X)

if (X > 0.0) ...

r (X)

while (ABS (W * W) – X) > 0.01 ...

W = W – ((W * W – X) / (2.0 * W))

returnValue = W

r (X), r (W)

r (X), r (W), d (W)

r (W), d (returnValue)

else returnValue = 0.0

d (returnValue)

return (returnValue)

r (returnValue)

nout

nfinal

u (X), u (W), u (returnValue)

Abbildung 8.19 Kontrollflussgraph zur Operation Sqrt

Anzahl der Schleifendurchläufe an. Für die Variablen W und returnValue erhält man auf die gleiche Weise ebenfalls geschlossene Ausdrücke für die Datenflüsse.

Bei abweisenden Schleifen müssen die Fälle n = 0 und n = 2 untersucht werden. Bei nicht abweisenden Schleifen reicht die Untersuchung des Falls n = 2 aus.

300

>

X: udrr(rr)n u mit n ≥ 0

>

W: ur(rdr)n ru mit n ≥ 0

>

returnValue: udru

Es stellt sich die Frage, welche Werte n bei der Datenflussanomalieanalyse betrachtet werden müssen. Sicherlich muss bei abweisenden Schleifen der Fall n = 0 betrachtet werden, da sich durch das Verschwinden der geklammerten Teilsequenz ein neuer Anschluss ergibt. Dieser könnte eine Datenflussanomalie entstehen lassen. Der Fall n = 1 kann ebenfalls betrachtet werden, da zwei neue Anschlüsse am Beginn des geklammerten Ausdrucks und an seinem Ende entstehen. Diese sind auch im Fall n = 2 enthalten, so dass auf die Betrachtung von n = 1 verzichtet werden kann. Außerdem können im Fall n = 2 weitere Datenflussanomalien auftreten. Zur Verdeutlichung betrachte man die Sequenz ... r(drd)n r ..., die für n = 0 und n = 1 keine Datenflussanomalien besitzt, für n = 2 (... rdrddrdr ...) aber eine dd-Anomalie zeigt. Für größere Werte n ergeben sich keine potentiellen neuen Datenflussanomalien. Ist also auf den Pfaden bis zum

8 Werkzeugunterstützte statische Codeanalyse

zweiten Schleifendurchlauf noch keine Datenflussanomalie aufgetreten, so wird auch keine mehr auftreten. Die unbegrenzte Pfadanzahl besitzt darauf keinerlei Einfluss.

Dieser Sachverhalt besitzt Ähnlichkeit zu der Forderung des boundary interior-Pfadtests, der für den Test von Schleifen die gleichen Fälle unterscheidet.

Die Operation Sqrt weist für die Variable W eine Datenflussanomalie auf. Der Datenfluss ur(rdr)n ru, n ≥ 0 beginnt mit einer ur-Anomalie. Der Wert der Variable W ist zum Zeitpunkt des ersten lesenden Zugriffs noch nicht initialisiert worden. Die Operation funktioniert aber für zufällig positive Initialwerte von W korrekt, so dass ein dynamischer Test den Fehler nicht sicher erkennt. Für negative Initialwerte von W wird die negative Wurzel bestimmt. Ist W zufällig initial gleich Null, so „stürzt das Programm ab“, da durch W dividiert wird. Während durch dynamisches Testen dieser Fehler nur unzuverlässig gefunden werden kann, ist er durch Datenflussanomalieanalyse sicher und mit geringem Aufwand erkennbar. Abb. 8.20 zeigt die korrigierte Fassung des Kontrollflussgraphen. Häufig ist ein Teil der theoretisch konstruierbaren Pfade nicht ausführbar, da keine entsprechenden Eingabedaten bzw. Betriebssituationen existieren. Datenflussanomalien auf derartigen nicht ausführbaren Pfaden sind nicht ungewöhnlich, obwohl sie vermeidbar sind. Sie treten während der Programmausführung nicht in Erscheinung und können daher auch kein Fehlverhalten verursachen. Datenflussanomalieanalysen fördern aber auch Anomalien auf nicht ausführbaren Pfaden zutage. Da die Bewertung der Ausführbarkeit eines Pfades oft kompliziert ist, sollten derartige Anomalien im Zweifel auch beseitigt werden. Besitzt eine Operation eine Parameterschnittstelle, so müssen für die übergebenen bzw. zurückgegebenen Variablen Definitionen bzw. Referenzen in den Knoten nin und nout des Kontrollflussgraphen angeordnet werden. Entsprechende Variablendefinitionen und -referenzen sind für Zugriffe auf globale Variablen zu berücksichtigen. Die korrekte Zuordnung von Definitionen zu nin ist allein aufgrund des Quellcodes einer Operation nicht immer möglich. Wird eine Variable durch Wertübergabe (call by value) einer Operation zur Verfügung gestellt, so ist in jedem Fall eine Definition dieser Variablen in nin vorzusehen. Da Modifikationen an derartig übergebenen Variablen nicht möglich sind, wird in nout keine Referenz der Variablen angeordnet. Eine Variablenübergabe über die Adresse (call by reference) sollte nur dann erfolgen, falls eine Rückgabe eines modifizierten Wertes dieser Variablen möglich sein soll. Dem Knoten nout wird eine entsprechende Variablenreferenz zugeordnet. Unklar ist, ob dem Knoten nin die Definition einer durch Referenz übergebenen Variablen zugeordnet werden muss. Es ist nicht allein anhand der

8.5 Datenflussanomalieanalyse

ANMERKUNG

Datenflussanomalien werden durch dynamisches Testen nicht sicher gefunden.

Datenflussanomalien auf nicht ausführbaren Pfaden

PROBLEM: Unterscheidung von Ausgabeparametern und transienten Parametern

301

nstart

u (X), u (W), u (returnValue)

nin

d (X)

if (X > 0.0) ...

r (X)

W = 1.0

d (W)

while (ABS (W * W) – X) > 0.01 ...

W = W – ((W * W – X) / (2.0 * W))

returnValue = W

r (X), r (W)

r (X), r (W), d (W)

r (W), d (returnValue)

else returnValue = 0.0

d (returnValue)

return (returnValue)

r (returnValue)

nout

nfinal

u (X), u (W), u (returnValue)

Abbildung 8.20 Kontrollflussgraph zur korrigierten Operation Sqrt

Kenntnis des Programmtextes entscheidbar, ob die Variable einen Eingabe- und einen Ausgabewert der Operation darstellt oder ob sie nur ein Ausgabewert ist. Für die drei Parametertypen Eingabeparameter, Ausgabeparameter und Ein-/Ausgabeparameter stehen nur zwei Übergabetechniken zur Verfügung. Ein-/Ausgabeparameter und reine Ausgabeparameter sind daher nicht einwandfrei unterscheidbar; insbesondere dann nicht, wenn die Existenz von Datenflussanomalien vermutet wird.

8.5.4

ANMERKUNG: Das ist nicht erstaunlich, weil diese Fehler Datenflussanomalien erzeugen.

302

Bewertung der Datenflussanomalieanalyse

Da die Datenflussanomalieanalyse eine unmittelbare Fehlererkennung gestattet, kann man ihre Leistungsfähigkeit analog zu den dynamischen Testverfahren empirisch ermitteln. Die Studie von /Girgis, Woodward 86/ untersucht neben der Leistungsfähigkeit einiger dynamischer Testverfahren auch die Datenflussanomalieanalyse. Die entdeckten Fehler gehören ausschließlich der Kategorie Berechnungsfehler an. In der Studie sind Wertzuweisungen an falsche Variablen, Anweisungen an unkorrekter Stelle und fehlende Anweisungen entdeckt worden.

8 Werkzeugunterstützte statische Codeanalyse

Die Analyse der Datenflussanomalien ist beschränkt auf einen schmalen Fehlerbereich, der durch andere Prüftechniken (z. B. dynamisches Testen) nicht genügend abgedeckt ist. Fehler können sicher erkannt werden. Datenflussanomalieanalyse bietet sich ergänzend zu dynamischen Testverfahren an. Aufgrund des im Vergleich zu dynamischen Tests geringen Aufwands und der direkten Fehlerlokalisierung ist die Datenflussanomalieanalyse ein für die Praxis äußerst interessantes Prüfverfahren. Die optimale Werkzeugunterstützung ist eine in den Compiler integrierte Datenflussanomalieanalysekomponente. Einige Compiler unterstützen das bereits. Praktiker haben mir in Industrieseminaren berichtet, dass sie diese Prüfungen des Compilers abschalten, weil sie die langen Ausgabelisten stören! Einerseits ist eine unzureichende Anpassbarkeit der Compilerwarnungen sicherlich unangenehm. Andererseits halte ich es für kritisch, eine leistungsfähige Prüfung aus diesem Grund nicht zu nutzen. Viele auf dem Markt erhältliche Prüfwerkzeuge enthalten heute bereits eine Möglichkeit, Datenflussanomalieanalysen durchzuführen. Falls Ihr Compiler Datenflussanomalieanalysen nicht unterstützt, so empfehle ich Ihnen die Beschaffung eines expliziten Werkzeugs, das diese Technik unterstützt.

8.6

Bewertung der werkzeugunterstützten statischen Codeanalyse

In vielen Anwendungsbereichen von Software werden bestimmte statische Codeanalysen durch Standards gefordert. Aber auch in vielen Anwendungsbereichen für die das nicht gilt, gebietet die Sorgfaltspflicht die Nutzung der beschriebenen Techniken. Dies gilt insbesondere auch im Hinblick auf den geringen Aufwand, den die beschriebenen Techniken aufgrund ihrer umfassenden Automatisierung benötigen. Ich empfehle Ihnen, die Punkte der folgenden Checkliste zu prüfen:

>

Wenn Sie eine Programmiersprache aus der C-Familie (z. B. C, C++, Java) verwenden, sollten Sie über die statische Prüfung von Programmierkonventionen nachdenken. Das Gleiche gilt für „alte“ Programmiersprachen, z. B. Fortran.

>

Auch wenn Sie moderne Programmiersprachen – z. B. ADA – verwenden, kann die statische Prüfung von Programmierkonventionen sinnvoll sein, soweit Sie ergänzende Forderungen betrifft, die der Compiler nicht bereits prüft.

>

In technischen Anwendungsbereichen von Software kann die Verwendung der statischen Analyse von Programmierkonventionen für bestimmte kritische Software-Module verbindlich

8.6 Bewertung der werkzeugunterstützten statischen Codeanalyse

CHECKLISTE

303

sein. Sie sollten das anhand der in Ihrem Bereich gültigen Standards prüfen.

304

>

Die Verwendung von grafischen und tabellarischen Darstellungen ist Stand der Technik. Wenn Sie Testwerkzeuge beschaffen, sollten Sie darauf achten, dass die gewünschten Darstellungen erzeugt werden. Entsprechende Werkzeuge sind aber auch getrennt erhältlich.

>

Falls Sie sich mit Wartungsprogrammierung oder Debugging befassen, so sollten Sie die Beschaffung eines Slicing-Werkzeugs erwägen.

>

Datenflussanomalieanalyse eignet sich besonders und als Ergänzung des dynamischen Tests. Prüfen Sie, ob Ihr Compiler das anbietet. Falls nicht, beschaffen Sie ein entsprechendes Werkzeug.

8 Werkzeugunterstützte statische Codeanalyse

9 Software-Inspektionen und Reviews Manuelle Prüfungen von Dokumenten und Code sind eine in der Praxis verbreitete Technik. Sie existieren in zahlreichen Ausprägungen. Typische Bezeichnungen sind z. B. Inspektion, Review, Peer Review oder Structured Walkthrough. Im Folgenden werden die drei Hauptformen manueller Prüfungen dargestellt. Es gibt manuelle Prüfungen in Sitzungstechnik und Kommentartechnik. Bei den in Sitzungstechnik durchgeführten Verfahren unterscheidet man anhand der Formalität des Vorgehens formale Inspektionen und konventionelle Reviews oder Structured Walkthroughs. Formale Inspektionen sind ein besonders effektives Mittel zur Fehlerfindung. Daher werden sie im Folgenden ausführlich dargestellt. Da formale Inspektionen in der Regel recht aufwendig sind, kann auf die einfacheren Reviewtechniken jedoch insgesamt nicht verzichtet werden. Manuelle Prüfungen sind besonders in frühen Phasen der Software-Entwicklung, z. B. für die Überprüfung von Entwurfsdokumenten wichtig. Sie können auch ergänzend zu dynamischen Tests auf Quellcode angewendet werden. Seit einiger Zeit wird an speziellen Inspektionstechniken für besondere Anwendungen gearbeitet, z. B. Safety-Inspektionen /Denger et al. 08/.

Übersicht 9.1

Eigenschaften und Ziele von Software-Inspektionen und Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

9.2

Formale Inspektionstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

9.3

Konventionelles Review in Sitzungstechnik: Structured Walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

9.4

Review in Kommentartechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

9.5

Bewertung von Software-Inspektionen und Reviews . . . . . . . . 318 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

305

9.1 Die drei Varianten manueller Prüfungen unterscheiden sich in Aufwand und Leistungsfähigkeit.

Eigenschaften und Ziele von Software-Inspektionen und Reviews

Manuell durchgeführte Prüfungen von Software existieren in drei Hauptvarianten: Reviews in Kommentartechnik, informale Reviews in Sitzungstechnik und formale Inspektionen in Sitzungstechnik. Bei den informalen Reviews in Sitzungstechnik finden sich in der Literatur diverse Ausprägungen. Einige Autoren unterscheiden Reviews, Peer Reviews und Structured Walkthroughs. Ein Structured Walkthrough wird oft als „weniger sorgfältiges“ Review gesehen. Im Folgenden findet eine Beschränkung auf die drei Hauptvarianten statt. Die formale Inspektion in Sitzungstechnik (Fagan Inspection) wird ausführlich dargestellt. Die drei manuellen Prüftechniken besitzen unterschiedliche Leistungsfähigkeiten und verursachen unterschiedliche Aufwände. Die leistungsfähigste Technik ist die formale Inspektion. Sie ist besonders gründlich, aber leider zeitaufwendig und teuer. Man wird daher nicht alle Teile einer Software einer formalen Inspektion unterziehen wollen. Informale Reviews in Sitzungstechnik nehmen eine mittlere Stellung ein. Sie verlangen einen geringeren Ressourceneinsatz als formale Inspektionstechniken. Die Aufwandsreduktion wird jedoch mit einer verringerten Leistungsfähigkeit erkauft. Die einfachste manuelle Prüfung ist das Review in Kommentartechnik. Es ist unkompliziert, kann schnell und flexibel durchgeführt werden und verlangt nur einen geringen Aufwand. Negativ ist die eingeschränkte Leistungsfähigkeit dieser Technik. Daher wird man Reviews in Kommentartechnik nur für unkritische Aufgaben einsetzen.

Die Semantik kann nur manuell geprüft werden.

306

Alle manuell durchgeführten Prüfungen besitzen ähnliche Eigenschaften und Ziele. Eine positive Eigenschaft von manuellen Prüfungen ist, dass sie in der Lage sind, semantische Aspekte zu beachten. Durch die Nutzung der Expertise der Teilnehmer können inhaltliche Aspekte von Dokumenten bewertet werden. Die Qualität vieler Merkmale – z. B. Verständlichkeit, Änderbarkeit, Aussagefähigkeit von Bezeichnern und Kommentaren – kann nur manuell geprüft werden. Derartige Tätigkeiten können nicht durch Werkzeuge automatisiert werden. Empirische Untersuchungen (z. B. /Möller 96/) belegen, dass Fehler, die in einer frühen Phase der Software-Entwicklung – z. B. in der Definitions- oder Entwurfsphase – entstanden sind, sehr hohe Korrekturkosten verursachen. Die Aufwendungen für Fehlerkorrekturen werden umso höher, je größer die Distanz zwischen der Fehlerentstehung und Fehlerfindung ist. Daher ist es sinnvoll, die Dokumente der frühen Entwicklungsphasen einer Prüfung zu unterziehen. Syntaktische Prüfungen können durch CASE-Werkzeuge durchgeführt werden. Semantische Prüfungen erfordern eine manuelle Bewertung durch Menschen. Hier spielen Inspektions- und Reviewtechniken eine bedeutende Rolle. Es bietet sich an, eine Inspektion bzw. ein Review am Ende jeder frühen Entwicklungsphase als Zwischenabnahme zu verwenden. So wird sichergestellt, dass ein qualitätsgerech-

9 Software-Inspektionen und Reviews

tes Ergebnis in die nachfolgende Software-Entwicklungsphase übergeben wird. Das Bestehen der Prüfung kann als Meilenstein genutzt werden. Da in allen Review- und Inspektionstechniken die Teilnahme weiterer Personen neben dem Autor des inspizierten Dokuments gefordert ist, realisieren diese Techniken das Prinzip der externen Qualitätskontrolle. Dieses Prinzip verlangt eine Qualitätskontrolle durch Personen, die nicht mit der Erstellung des begutachteten Dokuments direkt befasst waren. Die Einbindung mehrerer Personen in Inspektions- und Reviewteams besitzt einen weiteren positiven Aspekt. Durch die Notwendigkeit, sich in Arbeitsergebnisse von Kollegen einzuarbeiten, wird die fachliche Wissensbasis im Team verbreitet. Darüber hinaus lernt man gegebenenfalls abweichende Arbeitsmethodiken von Kollegen näher kennen. Diese können eventuell für die eigene Arbeit übernommen werden. Darüber hinaus wird die Verantwortung für die Qualität der Produkte vom ganzen Entwicklungsteam getragen. Falls in einem Produkt nach einer bestandenen Inspektion noch gravierende Fehler auftreten, so kann die Verantwortung dafür nicht dem Autor allein angelastet werden. Das Inspektionsteam trägt insgesamt die Verantwortung. Das Qualitätsbewusstsein wandelt sich von der Zuständigkeit für das eigene Teilprodukt hin zu einem Verantwortungsgefühl gegenüber dem Gesamtprodukt des Entwicklungsteams. Die Durchführung von Reviews und Inspektionen wirkt bereits im Vorfeld qualitätssteigernd. Erfahrungsgemäß bemühen sich die Autoren um eine verständliche Ausdrucksweise bei der Abfassung von Dokumenten, da mehrere Personen die Produkte begutachten müssen. Ein verständlicher, leicht erläuterbarer Stil wird bevorzugt. Durch die frühzeitige Nutzung von Inspektions- und Reviewtechniken während der Entwicklung werden kritische Komponenten früh identifiziert. Dies ist eine wichtige Information im Hinblick auf ein geeignetes Risikomanagement.

Prinzip der externen Qualitätskontrolle

In der Vergangenheit gab es Diskussionen darüber, ob manuelles Prüfen oder dynamisches Testen das bessere Mittel zur Fehlerfindung sei. Die Erfahrung zeigt, dass es sich bei den zwei unterschiedlichen Ansätzen nicht um Alternativen handelt. Manuelle Prüfungen in Form von Reviews oder Inspektionen sind eine sinnvolle Ergänzung werkzeugunterstützter Prüfungen. Man wird weder werkzeugunterstützte statische Analysen noch dynamisches Testen durch Review- oder Inspektionstechniken ersetzen können. Dort, wo eine werkzeugunterstützte statische Analyse möglich ist, kann sie mit weniger Aufwand und höherer Qualität als eine manuelle Prüfung durchgeführt werden. Als Beispiel sei hier die werkzeugunterstützte Datenflussanomalieanalyse (siehe Kapitel 8) genannt. Ein manuelles Aufspüren von Datenflussanomalien bei einer Codeinspektion ist möglich aber nicht sinnvoll, da die werkzeugunterstützte Datenflussanomalieanalyse zuverlässiger funktioniert und weniger Aufwand verursacht. Beim dynamischen Test werden ausschließlich Fehler gefunden, die zu Fehlverhalten führen. Abweichungen von Standards – z. B. die Verletzung einer Programmierkonvention – werden nicht erkannt, falls sie nicht direkt zu Fehlern führen. Derartige Fehler werden bei manuel-

Inspektionen und Reviews ergänzen andere Prüftechniken.

9.1 Eigenschaften und Ziele von Software-Inspektionen und Reviews

307

len Prüfungen entdeckt. Bei manuellen Prüfungen werden in der Regel „lokale“ Fehler erkannt. Fehlverhalten, die durch das Zusammenwirken weit entfernter Codeteile – z. B. mehrerer Module – zustandekommen, werden vermutlich kaum gefunden. Ein dynamischer Test wird derartige Fehlverhalten zuverlässiger erkennen. Daher sind dynamische Testtechniken, werkzeugunterstützte statische Analysen und manuelle Prüfungen in Form von Reviews und Inspektionen Techniken, die einander ergänzen. Empirische Untersuchungen zeigen, dass insbesondere formale Inspektionen ein sehr effektives Mittel zur Fehlerfindung sind.

9.2

Formale Inspektionstechniken

9.2.1 Formale Inspektion = Fagan Inspection

Formale Inspektionstechniken sind 1976 und 1986 von Michael Fagan vorgeschlagen worden /Fagan 76, Fagan 86/. In /Gilb, Graham 93/ sind sie umfassend beschrieben. Man bezeichnet sie daher auch als Fagan Inspection, Intensiv-Inspektion oder einfach als Software Inspection. Das Ziel der formalen Inspektionen ist die Erhöhung der Effektivität und Effizienz bei der Fehlerfindung durch Einhaltung eines genau definierten Inspektionsprozesses. Kennzeichnend für formale Inspektionstechniken ist, dass sie in genau definierten Phasen, mit definierten Eingangs- und Ausgangskriterien, Soll-Vorgaben für Geschwindigkeiten und zu erreichenden Zielen sowie mit verteilten Rollen durchgeführt werden.

Inspektionen erfordern Planung.

Der zeitliche Aufwand für Inspektionen ist hoch. Daher muss die notwenige Zeit im Projektplan fest eingeplant sein. Die Teilnehmer müssen ihre Aufgaben im Rahmen des formalen Ablaufs kennen und beherrschen. Inspektionen erfordern Schulung. Der streng geregelte Ablauf der Durchführung einer Inspektion verlangt einen entsprechend wohlstrukturierten Rahmen. Erfolgreiche Inspektionen benötigen einen definierten, gesteuert ablaufenden Prozess, in den sie eingebettet werden können. Darüber hinaus muss es einen Qualitätsmanagementprozess mit definierten Qualitätszielen geben, aus denen die Zielvorgaben für die Inspektionen abgeleitet werden können.

9.2.2 Inspektionen basieren auf einem formalen Prozess.

Beschreibung der formalen Inspektionstechniken

Wie bereits geschildert, ist der Hauptunterschied der formalen Inspektionstechniken gegenüber den übrigen Reviewtechniken die Durchführung als formaler Prozess. Inspektionen sind durch die folgenden Eigenschaften charakterisiert: >

308

Eigenschaften und Ziele der formalen Inspektionstechniken

Festgelegte Eingangs- und Ausgangskriterien

9 Software-Inspektionen und Reviews

>

Definierte Inspektionsphasen

>

Geschulte Teilnehmer mit festgelegten, verteilten Rollen

>

Sammlung und Analyse von Inspektionsdaten einschließlich Rückkopplung auf den Inspektionsprozess

>

Explizite Dokumentation der erkannten Fehler

>

Vorgaben für die Vorbereitungsraten und die Inspektionsgeschwindigkeit

>

Zielvorgaben für Ergebnisse

Ursprünglich waren Inspektionen als Prüftechnik für Entwürfe und für Quellcode vorgesehen. Mittlerweile werden Inspektionen jedoch in allen Phasen einer Software-Entwicklung eingesetzt. Es gibt Inspektionen von Anforderungsdokumenten, von Entwürfen, von Quelltexten und auch von Testfällen. Inspektionen werden in sechs Phasen durchgeführt:

Phasen einer Inspektion

1. Planung: Organisatorische Vorbereitung 2. Überblicksveranstaltung: Informationsverteilung über das Produkt 3. Vorbereitung: Jeder Inspektor bereitet sich getrennt von den anderen

Inspektoren vor. 4. Inspektionssitzung: Durchführung der Inspektion in Sitzungstech-

nik 5. Nacharbeit: Durchführung der Fehlerkorrekturen 6. Follow-up: Überprüfung der Fehlerkorrekturen und Anfertigung der

Inspektionsberichte Die Überblicksveranstaltung ist optional. Falls keine Überblicksveranstaltung erforderlich ist, so kann und soll sie entfallen. Dies erhöht die Effizienz der Inspektion, da der entsprechende Aufwand entfällt. Die Planungsphase dient der organisatorischen Vorbereitung der Inspektion. So wie für alle anderen Tätigkeiten der Software-Entwicklung wird auch für Inspektionen zu Beginn eines Projekts ein Plan erstellt, der Zeit-, Aufwands- und Ressourcenaspekte enthält. Ist der geplante Zeitpunkt erreicht, und hat der Autor sein zu inspizierendes Produkt fertiggestellt, so meldet er die Inspektion beim Moderator an. Der Moderator prüft, ob das Produkt die Eingangskriterien erfüllt. Falls das Produkt die Eingangskriterien nicht erfüllt, so informiert der Moderator den Autor über die erforderlichen Änderungen oder Ergänzungen. Bei den Eingangskriterien handelt es sich typischerweise um einfach prüfbare,

9.2 Formale Inspektionstechniken

1. Planungsphase

309

syntaktische Regeln. So wird man als Eingangskriterium für eine Codeinspektion z. B. verlangen, dass der Code frei von Syntaxfehlern ist. Bei der Inspektion von Entwicklungsdokumenten, die computerunterstützt erstellt wurden, d. h. mit so genannten CASE-Werkzeugen, wird man verlangen, dass die Prüfungen der Werkzeuge fehlerfrei durchlaufen. Falls das Produkt die Eingangskriterien erfüllt, so kann es, wie im Projektplan vorgesehen, inspiziert werden. 2. Überblicksveranstaltung

Die Überblicksveranstaltung ist, wie bereits dargestellt, optional. Sie dient zur Information der Inspektoren über das Produkt. Die kann z. B. aus den folgenden Gründen sinnvoll sein: >

Das Produkt ist umfangreich, kompliziert oder steht mit zahlreichen anderen Produktteilen in Beziehung.

>

Die verwendete Technik ist neu.

>

Das Produkt entstammt einem „Ein-Mann-Projekt“. Die anderen Inspektoren benötigen daher Hintergrundwissen.

Falls eine Überblicksveranstaltung durchgeführt wird, so soll sie in der Regel nicht länger als zwei bis drei Stunden dauern. Werden bereits während der Überblicksveranstaltung Fehler erkannt, so müssen diese vor der Verteilung des Materials an die Inspektoren zur Vorbereitung korrigiert werden. In der Regel wird die Überblicksveranstaltung vom Autor durchgeführt. In besonderen Fällen kann es jedoch sinnvoll sein, die Überblicksveranstaltung von einer anderen Person durchführen zu lassen. Falls die Überblicksveranstaltung z. B. wegen einer neu verwendeten Technik durchgeführt wird, so könnte ein interner Methodenberater als Durchführender in Frage kommen. Falls die Überblicksveranstaltung unnötig ist, so sollte sie entfallen. 3. Vorbereitung

310

Die Inspektoren sollen sich auf die Inspektionssitzung vorbereiten. Zu diesem Zweck erhält jeder Inspektor einen vollständigen Satz der erforderlichen Unterlagen. Diese Unterlagen dürfen bis zur Durchführung der Inspektion nicht mehr verändert werden. Man verhindert so, dass in der Inspektionssitzung über einen alten Stand des Produkts diskutiert wird. Da die Fortführung der Arbeiten an dem Produkt bis zur Durchführung der Inspektionssitzung eingestellt ist, muss die Inspektion mit hoher Priorität durchgeführt werden. Jeder Inspektor bereitet sich individuell anhand der Unterlagen auf die Inspektionssitzung vor. Er notiert sich alle gefundenen Fehler und Unklarheiten. Für die Vorbereitungsrate existieren Richtwerte, anhand derer die Vorbereitungszeit geplant wird. Ein zu geringer Vorbereitungsaufwand führt zu einem zu geringen Wissen der Inspektoren währen der Inspektionssitzung. Sie sind praktisch unvorbereitet und lernen das Produkt erst während der eigentlichen Inspektionssitzung kennen. Daher finden sie relativ wenige Fehler. Dies reduziert die Effizienz der Inspektion. Ein zu hoher Vorbereitungsaufwand reduziert die Effizienz ebenfalls, da dieser Aufwand der Inspektion

9 Software-Inspektionen und Reviews

zugerechnet werden muss. Die Effizienz lässt sich als Quotient aus gefundener Fehleranzahl und den dafür eingesetzten Aufwand ausdrücken. Für die Vorbereitungsrate muss es einen mittleren, optimalen Wert geben. Dieser Wert mag für jede Organisation und jede unterschiedliche Sorte von Inspektion verschieden sein. In der Literatur findet man jedoch Richtwerte, die im Folgenden angegeben werden (siehe 9.2.3). Das Hauptziel der Vorbereitung der Inspektion ist die Gewinnung von Produktverständnis. Das Ziel ist nicht in erster Linie Fehlerfindung. Werden Fehler gefunden, so ist das ein gewünschter Nebeneffekt. Entscheidend ist jedoch, dass jeder Inspektor nach der Vorbereitung ein gutes Verständnis der Funktionsweise des zu inspizierenden Produkts besitzt. Die Durchführung der Inspektionssitzung ist die zentrale Phase einer formalen Inspektion. Die Teilnehmer der Inspektionssitzung agieren mit den folgenden verteilten Rollen: >

Moderator

>

Autor

>

Leser

>

Protokollführer

>

Weitere Inspektoren

Der Moderator soll ein anerkannter Fachmann mit einer speziellen Ausbildung zum Moderator von Inspektionen sein. In der Primärliteratur wird zum Teil gefordert, dass der Moderator in technischer Hinsicht fachkompetent sein soll. Das würde bedeuten, dass der Moderator einer Codeinspektion z. B. die verwendete Programmiersprache beherrschen sollte. Dies ist sicherlich wünschenswert aber nach meiner Erfahrung nicht zwingend notwendig. Entscheidender als technische Fachkenntnis ist die Beherrschung der Fähigkeit des Moderierens. Der Moderator leitet die Sitzung und gewährleistet, dass die Inspektion entsprechend des vorgesehenen Ablaufs durchgeführt wird. Seine Aufgabe ist insbesondere, dafür zu sorgen, dass alle Inspektoren entsprechend ihrer Kompetenzen mitarbeiten können. Der Moderator muss verhindern, dass einzelne Inspektoren das Inspektionsteam dominieren und andere Inspektoren nicht zu Wort kommen. Die Hauptaufgabe des Moderators ist die Schaffung von Synergie. Er muss dafür sorgen, dass das Inspektionsteam „in Fahrt kommt“. Dieses synergetische Miteinander der Inspektoren ist erfahrungsgemäß eine wichtige Voraussetzung für hohe Effizienz. Der Moderator muss sicherstellen, dass sich alle Inspektoren auf die Fehlererkennung konzentrieren. Diskussionen sind nur zu Fehlern und Fehlerarten erlaubt. Erfahrungsgemäß haben Inspektionen eine Tendenz, nach der Findung einiger Fehler in eine Diskussion der Lösungskonzepte abzugleiten. Dies ist unerwünscht, da es die Effizienz der Inspektion reduziert. Der Moderator muss dies verhindern.

9.2 Formale Inspektionstechniken

4. Inspektionssitzung

Der Moderator sollte eine spezielle Ausbildung absolviert haben.

311

Der Autor übt keine weitere Rolle aus.

Der Autor ist der Ersteller des inspizierten Produkts. Er ist für die Korrektur der während der Inspektion gefundenen Fehler zuständig. Als Fachmann für die technische Realisierung des Produkts beantwortet der Autor die Fragen der anderen Inspektoren. Der Autor darf niemals Moderator, Leser oder Protokollführer sein.

Der Leser leitet die Sitzung in technischer Hinsicht.

Der Leser führt das Inspektionsteam durch die Sitzung. Er trägt die technischen Inhalte erläuternd vor. Daher muss der Leser in der Lage sein, die unterschiedlichen Teile der Arbeit zu beschreiben. Er muss also im Unterschied zum Moderator notwendig ein technischer Fachmann sein. Der Leser ist niemals identisch mit dem Autor. Durch diese Regel erzielt man zwei positive Effekte. Zum Ersten wird verhindert, dass der Autor, der mit den Details seiner Arbeit bestens vertraut ist, das Inspektionsteam dominiert, indem er dem Inspektionsteam seine technische Sicht in seiner spezifischen Lesegeschwindigkeit aufzwingt. Zum Zweiten wird durch den technischen Vortrag einer anderen Person erreicht, dass der Autor von einem quasi externen Standpunkt auf seine eigene Arbeit blickt. Dies bietet die Chance, dass er bestimmte Fehler in seinem eigenen Produkt erkennt. Für die Lesegeschwindigkeit – die so genannte Inspektionsrate – gilt das Gleiche wie für die Vorbereitungsrate. Eine zu hohe Lesegeschwindigkeit verursacht eine oberflächliche Inspektion. Eine zu niedrige Lesegeschwindigkeit verursacht einen zu hohen Inspektionsaufwand und damit eine zu geringe Effizienz. Aussagen zur optimalen Lesegeschwindigkeit können in der Literatur gefunden werden. Sie werden im Folgenden angegeben.

Der Protokollführer dokumentiert die Ergebnisse.

Der Protokollführer notiert und klassifiziert alle Fehler, die in der Inspektion gefunden werden. Darüber hinaus unterstützt er den Moderator bei der Anfertigung der Inspektionsberichte.

Alle Teammitglieder inspizieren.

Alle Mitglieder des Inspektionsteams – auch der Moderator, Autor, Leser und Protokollführer – sind Inspektoren, deren Ziel es sein muss, Fehler zu finden. Als weitere Inspektoren kommen z. B. die folgenden Personen in Frage:

Kleine Inspektionsteams erhöhen die Effizienz.

312

>

Projektmitarbeiter aus dem gleichen Projekt

>

Methodenberater (Einhaltung der Standards)

>

Systemspezialist

>

Datenschutzbeauftragter

Das Inspektionsteam soll möglichst klein sein. In der Regel soll es zwischen drei und sieben Personen umfassen. Es soll nur so umfangreich sein, dass die notwendige Expertise für die Inspektion im Team vorhanden ist. Kleine Inspektionsteams erhöhen die Effizienz der Inspektion, da die Anzahl der Mitglieder des Inspektionsteams in den Inspektionsaufwand linear eingeht. Ein 6-Personen-Team müsste daher in der gleichen Zeit doppelt so viele Fehler erkennen wie ein 3-Personen-Team, um gleich

9 Software-Inspektionen und Reviews

effizient zu sein. Dies ist nicht zu erwarten. Die minimale Teilnehmeranzahl bei Inspektionen ist drei. Falls nur drei Personen ein Inspektionsteam bilden, führt der Moderator gleichzeitig Protokoll. Die verbleibenden zwei Personen sind der Autor und der Leser. Es ist extrem wichtig, dass die Ergebnisse von Inspektionen (und auch der anderen Reviewtechniken) nicht zur Beurteilung von Mitarbeitern herangezogen werden. Die Durchführung einer Inspektion ist für den Autor eines Produkts gegebenenfalls eine etwas unangenehme Situation. Eine Gruppe von Kollegen kritisiert seine Arbeit. Man kann jedoch aus der Erfahrung mit Inspektionen lernen, dass die Ergebnisse der Inspektion die eigene Arbeit verbessern und Probleme zu einem späteren Zeitpunkt reduzieren helfen. Eine Voraussetzung für diese Einschätzung ist jedoch, dass Inspektionen als ein rein fachliches Instrument verstanden werden. Die persönliche Wertschätzung von Mitarbeitern muss von den Inspektionsergebnissen vollständig abgekoppelt sein. Wird die Menge der in Inspektionen gefundenen Fehler als Indikator für die Leistungsfähigkeit von Mitarbeitern verwendet, so werden Inspektionen nicht als technisches Qualitätssicherungsinstrument sondern als Bewertungsverfahren für die eigene Leistungsfähigkeit verstanden. Dies führt dazu, dass der Autor versuchen wird, möglichst viele Fehler abzustreiten. Das reduziert die Effizienz der Inspektion und macht die Technik weitestgehend nutzlos. Eine einfache Regel, die dazu dient, eine persönliche Bewertung des Autors in der Inspektion zu verhindern, ist die Forderung, ausschließlich gleichberechtigte Personen in Inspektionen mitwirken zu lassen. Dispositiv Vorgesetzte nehmen an Inspektionen keinesfalls teil. Ein guter Vorgesetzter sollte das wissen und beherzigen. Er hat in der Inspektionssitzung – auch als Gast – nichts zu suchen. Seine Nichtteilnahme wirkt qualitätssteigernd. Die während der Inspektionssitzung gefundenen Fehler sollen, so weit möglich, klassifiziert werden. Es bietet sich an, dass der Protokollführer zu diesem Zweck ein vorgegebenes Klassifikationsschema verwendet. Außerdem ist es sinnvoll, Checklisten zu verwenden. Zum einen stellt dies sicher, dass keine Prüfungen vergessen werden. Zum anderen lässt die Abarbeitung einer Checkliste erkennen, ob die Inspektion kontinuierlich voranschreitet oder sich im Kreis dreht. Dies ist für den Moderator ein Indikator, den derzeitig bearbeiteten Punkt der Checkliste hinten anzustellen und zunächst mit dem folgenden Punkt fortzufahren. Eine zielgerichtet entsprechend dieses Verfahrens durchgeführte Inspektion ist anstrengend. Das synergetische Arbeiten kann nicht ohne Erschöpfung über einen längeren Zeitraum aufrechterhalten werden. Erfahrungsgemäß sollte die maximale Dauer einer Inspektion zwei bis drei Stunden nicht überschreiten. Am Ende der Inspektionssitzung wird festgelegt, ob das Produkt akzeptiert ist, bedingt akzeptiert ist oder eine Re-Inspektion notwendig ist.

9.2 Formale Inspektionstechniken

WICHTIG: Inspektionsergebnisse dürfen nicht zur Mitarbeiterbeurteilung verwendet werden.

KEINE dispositiv vorgesetzten Personen als Teammitglieder

Checklisten sind sinnvoll.

313

5. Nacharbeit

6. Follow-Up

314

Anschließend muss die Nacharbeit der Inspektion geleistet werden. Der Autor arbeitet die im Inspektionsprotokoll notierten Fehler ab. Im einfachsten Fall bedeutet dies die Durchführung einer Fehlerkorrektur. Es ist jedoch auch möglich, dass Fehler nicht unmittelbar korrigiert werden können. Der Fehler muss dann in das Änderungsmanagement eingestellt werden, um eine entsprechende Entscheidung über seine Korrektur herbeizuführen. Ein Beispiel für eine derartige Situation ist die Erkennung eines Entwurfsfehlers während einer Codeinspektion. Die Entwurfsdokumente sind zu diesem Zeitpunkt bereits unter Konfigurationskontrolle und können nicht verändert werden. Die Fehlerkorrektur muss daher über das Änderungsmanagement erfolgen. Darüber hinaus kann sich bei der Fehlerkorrektur herausstellen, dass eine vermeintlich fehlerhafte Stelle entgegen der Sichtweise während der Inspektion doch korrekt ist. In solchen Fällen ist eine Stellungnahme des Autors im so genannten Follow-up notwendig. Nach der Abarbeitung der Fehlerliste durch den Autor kann das Produkt unter Konfigurationskontrolle gebracht werden, falls es in der Inspektionssitzung akzeptiert wurde. Es ist üblich, Produkte, die nur wenige kleine Fehler enthalten, unter der Auflage zu akzeptieren, dass diese Fehler vom Autor abgestellt werden. Eine Überprüfung der Fehlerkorrekturen ist in diesem Fall nicht erforderlich. Falls das Produkt in der Inspektionssitzung bedingt akzeptiert wurde oder Re-Inspektion erforderlich ist, so sind weitere Schritte notwendig. Diese Schritte finden in der letzten Inspektionsphase, dem Follow-up, statt. Falls das Produkt währen der Inspektionssitzung bedingt akzeptiert wurde, so kann der Moderator die Korrekturen bilateral mit dem Autor überprüfen. Diese Aussage findet sich verschiedentlich in der Literatur. Falls der Moderator jedoch kein technischer Fachmann ist, so wird er kein geeigneter Partner zur Durchführung der Prüfung sein. In diesem Fall ist es sinnvoller, eine andere Person aus dem Inspektionsteam für die Überprüfung der Fehlerkorrekturen festzulegen. In der Regel wird man aufgrund der geforderten technischen Fachkompetenz den Leser wählen. Ich empfehle, dass im Regelfall bei einer bedingten Akzeptanz des Produkts die Fehlerkorrekturen bilateral von Autor und Leser überprüft werden. Falls in der Inspektion die Durchführung einer Re-Inspektion beschlossen wurde, so muss eine erneute Inspektionssitzung durchgeführt werden. An dieser Sitzung sind dieselben Inspektoren beteiligt. Die Sitzung ist auf die in den vorherigen Inspektionssitzungen gefundenen Fehler fokussiert. Man verwendet das Fehlerprotokoll der Inspektionssitzung und überprüft die Modifikationen am Produkt. Re-Inspektionen sind in der Regel kritisch, weil sie im Projektplan nicht berücksichtigt sind und daher oft zu Zeitverzügen in der Projektabwicklung führen. Im Follow-up werden noch ausstehende Inspektionsberichte erstellt. Dies sind insbesondere technische Berichte zu gefundenen Fehlern, eingesetzten Aufwänden und verwendeten Vorbereitungs- und Inspektionsraten.

9 Software-Inspektionen und Reviews

9.2.3

Bewertung der formalen Inspektionstechniken

Zahlreiche Veröffentlichungen zeigen, dass formale Software-Inspektionen sowohl ein sehr effektives als auch ein effizientes Mittel zur Fehlerfindung sind. Einschlägige empirische Daten finden sich z. B. in /Thaler, Utesch 96/ und in /Ebert 00/. Weitere Daten sind in /Fagan 76/ und /Fagan 86/ enthalten. Mit der Effektivität gibt man die Anzahl gefundener Fehler bezogen auf den betrachteten Umfang an. Effektivität ist ein Maß für die Leistungsfähigkeit einer Prüftechnik. Die Effizienz ist hier der Quotient aus der Anzahl der gefundenen Fehler und dem für die Fehlerfindung benötigten Aufwand. Effizienz ist daher ein Maß für die Wirtschaftlichkeit eines Prüfverfahrens. Thaler und Utesch haben die Effizienz und Effektivität von Software-Inspektionen mit konventionellen Reviewtechniken und dem dynamischen Test verglichen. Die Ergebnisse sind in Tab. 9.1 dargestellt.

Inspektionen sind effizient und effektiv, aber aufwändig.

Einerseits zeigen sich die Software-Inspektionen bezüglich ihrer Effizienz und Effektivität den konventionellen Reviewtechniken (Walkthrough) und den Testtechniken überlegen. Andererseits zeigt Tab. 9.1 das Hauptproblem der formalen Inspektionstechniken. Sie sind absolut betrachtet sehr aufwendig. Daher können sie nur auf relativ kleine Teile von Produkten angewendet werden. Trotz ihrer hohen Leistungsfähigkeit und guten Wirtschaftlichkeit sind formale Inspektionstechniken flächendeckend eingesetzt in der Regel zu aufwändig. Weitere Aussagen zur Leistungsfähigkeit von Inspektionstechniken findet man bei /Russell 91/, /Schnurrer 88/ und /Kosman, Restivo 92/. Aufgrund des relativ hohen Aufwands, den formale Inspektionstechniken verursachen, wird man auf den Einsatz konventioneller Reviewtechniken und auf Reviews in Kommentartechnik nicht verzichten wollen. Fagan gibt in /Fagan 86/ für die Überblicksveranstaltung eine Rate von 500 Netto-Quellcodezeilen pro Stunde an. Netto-Quellcodezeilen verstehen sich in diesem Zusammenhang als Quellcodezeilen ohne Kommentare. Für die Vorbereitungsrate gibt Fagan 125 Netto-Quellcodezeilen pro Stunde an. Die Inspektionsgeschwindigkeit soll 90 Netto-Quellcodezeilen pro Stunde betragen. Die maximale Inspektionsrate soll 125 Netto-Quellcodezeilen pro Stunde nicht überschreiten. Abb. 9.1 stellt empirische Ergebnisse aus /Thaler, Utesch 96/ dar. Es ist deutlich erkennbar, dass mit sinkender Inspektionsrate die Effektivität der Inspektion steigt. Dennoch Effizienz in

(

Empirische Daten

Effektivität in

)(

)

Tabelle 9.1 Effizienz- und Effektivitäts-Vergleich von Prüftechniken aus /Thaler, Utesch 96/

9.2 Formale Inspektionstechniken

315

NLOC = Netto Lines of Code

Abbildung 9.1 Empirische Daten zur Inspektionsrate aus /Thaler, Utesch 96/

ist aus wirtschaftlichen Gründen eine extrem geringe Inspektionsrate nicht anzustreben. Abb. 9.2 zeigt empirische Daten aus /Ebert 00/. Wie das obere Diagramm zeigt, steigt auch hier die Effektivität mit sinkender Inspektionsrate an. Der im unteren Diagramm aufgetragene Kehrwert der Effizienz zeigt jedoch ein Minimum. Anders formuliert: Die Effizienz steigt mit sinkender Inspektionsrate bis zu einem Maximalwert an und

Ph = Person hour Stmt = Statement

Abbildung 9.2 Empirische Daten zur Inspektionsrate aus /Ebert 00/

316

9 Software-Inspektionen und Reviews

fällt dann mit weiter sinkender Inspektionsrate wieder ab. Nach /Ebert 00/ liegt das Optimum bei etwa 90 Anweisungen pro Mitarbeiterstunde.

9.3

Konventionelles Review in Sitzungstechnik: Structured Walkthrough

Die informalen Reviews in Sitzungstechnik nehmen im Hinblick auf Leistungsfähigkeit, Wirtschaftlichkeit und Ressourceneinsatz eine Mittelstellung zwischen den formalen Inspektionstechniken und den Reviews in Kommentartechnik ein. Einerseits verfügen sie über eine geringere Effizienz und Effektivität als formale Inspektionen. Andererseits ist der Zeit-, Kosten- und Ressourceneinsatz ebenfalls gegenüber den formalen Inspektionstechniken reduziert. Reviews und Inspektionen verlangen die Durchführung einer Inspektionssitzung. Man spricht daher auch von manuellen Prüfungen in Sitzungstechnik. Der wesentliche Unterschied zwischen formalen Inspektionen und Reviews ist, dass die Reviews nicht nach einem formalen Ablauf durchgeführt werden und für die Teamteilnehmer in der Regel keine Rollenverteilung vorliegt. Darüber hinaus werden Reviewdaten oft nicht aufgezeichnet und analysiert. Ferner sind quantitative Zielvorgaben sowie Eingangs- und Ausgangskriterien in der Regel nicht definiert. Während formale Inspektionen allein auf das Finden von Fehlern ausgerichtet sind, dienen konventionelle Reviews z. B. auch als Mittel für Entscheidungsfindungen, für das Auflösen von Konflikten, für den Austausch von Informationen oder für das Brainstorming in Zusammenhang mit der Lösung von Problemen. Konventionelle Reviewtechniken gibt es unter einer Vielzahl von Bezeichnungen mit zum Teil unklaren Abgrenzungen und oft nur geringfügigen Unterschieden. Typische Bezeichnungen sind Peer Review und Structured Walkthrough. Diese Techniken besitzen, wie einschlägige empirische Untersuchungen zeigen, eine hohe Verbreitung in der Praxis. Trotz ihrer geringeren Leistungsfähigkeit im Vergleich mit den formalen Inspektionstechniken wird man sie weiterhin nutzen wollen. Neben dem bereits beschriebenen Aspekt der Aufwandsreduktion spielen ihre vielfältigen Einsatzmöglichkeiten und die hohe Flexibilität eine wesentliche Rolle. Für die Durchführung konventioneller Reviews gelten grundsätzlich die gleichen Rahmenbedingungen wie bei den formalen Inspektionstechniken. Insbesondere ist darauf zu achten, dass die Reviewteams klein sind, ohne auf notwendige Expertise zu verzichten. Besonders wichtig ist auch bei konventionellen Reviews die Schaffung einer fachlichen Atmosphäre. Werden konventionelle Reviews zur Fehlerfindung genutzt, so ist auf die Teilnahme dispositiv Vorgesetzter zu verzichten. Konventionelle Reviewtechniken werden ausführlich in /Yourdon 89/ beschrieben. Empirische Daten zur Leistungsfähigkeit konventioneller Reviewtechniken sind in /Thaler, Utesch 96/ enthalten.

9.3 Konventionelles Review in Sitzungstechnik: Structured Walkthrough

Informale Reviews sind ein Kompromiss aus Aufwand und Leistungsfähigkeit.

Informale Reviews sind flexibel.

317

9.4 Reviews in Kommentartechnik verursachen wenig Aufwand.

Review in Kommentartechnik

Reviews in Kommentartechnik bilden bei den manuellen Prüftechniken das untere Ende der Skala in Bezug auf Leistungsfähigkeit und Wirtschaftlichkeit. Diesem Nachteil steht der Vorteil des geringen Aufwands gegenüber. Charakteristisch für Reviews in Kommentartechnik ist, dass keine Inspektionssitzung stattfindet. Die zu prüfenden Dokumente werden an die Reviewer verteilt. Früher wurde das typischerweise durch Versand mit der Hauspost erledigt. Heute wird in der Regel E-Mail oder das Intranet verwendet. Da bei Reviews in Kommentartechnik keine einheitliche Vorgehensweise durch die Sitzung erreicht wird, bietet sich hier besonders die Verwendung von Checklisten an. Diese Checklisten dienen zur Festlegung der zu überprüfenden Eigenschaften. Sie sollten daher beim Versand der Dokumente beigelegt werden. Für das Review in Kommentartechnik wird in der Regel eine Frist gesetzt, bis zu der das Review durchzuführen ist. In der Regel wird davon ausgegangen, dass eine Überschreitung der Frist einer impliziten Zustimmung entspricht. Bei Reviews in Kommentartechnik besteht daher die Gefahr, dass, z. B. aufgrund von Arbeitsüberlastung, Reviewfristen verstreichen und einige der Dokumente gar nicht geprüft werden. Reviews in Kommentartechnik wird man daher nur für relativ unkritische Produktteile anwenden. Dies können z. B. geringfügig modifizierte, periphere Software-Module sein, bei denen keine größeren Probleme erwartet werden. Träten dennoch Probleme auf, so wären auch diese vergleichsweise tolerierbar.

9.5

Bewertung von Software-Inspektionen und Reviews

Manuelle Überprüfungen sind eine unverzichtbare Ergänzung dynamischer Tests und werkzeugunterstützter, statischer Analysen bei der Überprüfung von Code. Mindestens genauso wichtig sind sie als Prüftechniken für Dokumente der frühen Phasen. Die fachlichen Inhalte von Analyse- und Entwurfsdokumenten können werkzeugunterstützt nicht geprüft werden. Hier sind Inspektions- und Reviewtechniken die einzig sinnvolle Prüfmöglichkeit. Reviews und Inspektionstechniken sind keine Alternative zu anderen Ansätzen wie dynamischem Testen, statischen Analysen oder formalen Techniken. Sie sind eine leistungsfähige Ergänzung. /Thaler, Utesch 96/ geben die in Tab. 9.2 aufgeführten Daten zur Effizienz und Effektivität unterschiedlicher Review- und Inspektionstechniken an. Man erkennt, dass sowohl Effizienz als auch Effektivität in der Reihenfolge Kommentartechnik, konventionelles Review und Software-Inspektion zunehmen. Aufgrund der steigenden absoluten Aufwendungen für die Durchführung der Inspektion bzw. des Reviews ist es dennoch sinnvoll, die jeweils angemessene dieser drei Techniken auszuwählen und einzusetzen. Software-Inspektionen wird man insbesondere auf kritische

318

9 Software-Inspektionen und Reviews

Software-Komponenten mit einer zentralen Stellung anwenden. Der hohe Aufwand für die Inspektion wird hier durch die potentiell kritischen Auswirkungen unerkannter Fehler gerechtfertigt. Software-Teile mit durchschnittlicher Kritikalität wird man mit konventionellen Reviewtechniken prüfen. Die Durchführung einer formalen Inspektion wird hier oft zu aufwendig sein. Ein Review in Kommentartechnik wird häufig eine zu geringe Leistungsfähigkeit besitzen. Bei Software-Teilen, bei denen man keine Probleme erwartet, dürfte oft ein Review in Kommentartechnik ausreichen.

(

)(

)

Tabelle 9.2 Vergleich von Review-Techniken

>

Sie sollten Inspektions- und Reviewtechniken insbesondere zur Prüfung von Dokumenten aus frühen Entwicklungsphasen nutzen.

>

Die Durchführung von Code-Inspektionen empfiehlt sich besonders für kritische Software-Komponenten.

>

Eine Nutzung von formalen Inspektionstechniken, konventionellen Reviews und Reviews in Kommentartechnik ist insbesondere aus Effizienzgründen sinnvoll.

>

Um die richtige Inspektions- oder Reviewtechnik auswählen zu können, müssen Sie Risiken systematisch identifizieren.

9.5 Bewertung von Software-Inspektionen und Reviews

CHECKLISTE

319

“This page left intentionally blank.”

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis Formale Techniken sind eine wichtige Ergänzung informaler Prüfungen. Dies gilt besonders für kritische Anwendungsbereiche /Liggesmeyer 07/. Falls Software-Fehler gravierende Sicherheitsrisiken hervorrufen können, so sind Restfehler nicht akzeptabel. Die informalen Prüftechniken liefern die benötigten vollständigen Aussagen nicht. Ein wichtiger Vorteil der formalen Techniken ist die Vollständigkeit der erzielten Ergebnisse. Im Folgenden werden der symbolische Test als Verallgemeinerung des dynamischen Tests, sowie das Floyd’sche Zusicherungsverfahren, der Hoare-Kalkül, algebraische Techniken und automatenbasierte Verfahren diskutiert. Die Techniken besitzen jeweils spezifische Eigenschaften. Ihre Anwendung erfordert eine sorgfältige Analyse der Rahmenbedingungen und gegebenenfalls eine Schaffung notwendiger Voraussetzungen. Die Nutzung formaler Techniken muss daher zu Beginn einer Entwicklung entschieden werden. Ein nachträglicher unvorbereiteter Einsatz ist kaum möglich.

Übersicht 10.1

Eigenschaften und Ziele der formalen Techniken . . . . . . . . . . . . 322

10.2

Symbolischer Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

10.3

Formaler Korrektheitsbeweis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

10.4

Bewertung der formalen Techniken . . . . . . . . . . . . . . . . . . . . . . . . 358 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

321

10.1

Formale Techniken besitzen im Allgemeinen keinen Stichprobencharakter.

Eigenschaften und Ziele der formalen Techniken

Der Programmcode enthält im Prinzip alle Informationen, die zur Ermittlung der fachlichen Wirkungen einer Programmausführung notwendig sind. Formale Techniken nutzen diesen Sachverhalt. Sie verzichten darauf, das Verhalten einer Software mit dynamischen Testfällen konkret stichprobenhaft zu prüfen. Stattdessen werden die Wirkungen auf einem höheren Abstraktionsniveau allgemein ermittelt. Der symbolische Test erreicht das durch Einführen von symbolischen Stellvertretern für konkrete Variablenwerte. Auf diese Weise erhält man symbolische Ergebnisse, die eine sehr große Anzahl konkreter dynamischer Testfälle ersetzen. Der Vorteil der allgemeineren Aussagen muss mit einigen Nachteilen erkauft werden. So können z. B. bestimmte Datentypen und Datenstrukturen nicht geeignet beachtet werden. Darüber hinaus ist es oft schwierig, die Korrektheit symbolischer Ergebnisse zu beurteilen. Beim formalen Korrektheitsbeweis liegt die Spezifikation in formaler Form vor. Man versucht, einen im Wesentlichen automatischen Beweis der Konsistenz des Programmcodes und der formalen Spezifikation zu führen. Auch formale Beweistechniken besitzen charakteristische Vorund Nachteile. Das im Vergleich zum dynamischen Test höhere Abstraktionsniveau, das bei der Anwendung formaler Techniken gewählt wird, verursacht ein gravierendes Problem. Alle erzeugten Aussagen beziehen sich auf dieses Niveau. In der Regel werden Eigenschaften des Quellcodes bewiesen. Werden Fehler zu einem späteren Zeitpunkt eingefügt – z. B. bei der Erzeugung von Maschinencode aus dem Quellcode – so können formale Techniken das nicht erkennen.

Der symbolische Test müsste richtiger als symbolische Analyse oder symbolische Interpretation bezeichnet werden.

322

10.2

Symbolischer Test

10.2.1

Eigenschaften und Ziele des symbolischen Tests

Der symbolische Test ist kein Testverfahren im herkömmlichen Sinne, sondern eine analytische Technik, die unter bestimmten Bedingungen geeignet ist, die Korrektheit eines Software-Moduls sicherzustellen – eine Eigenschaft, die dynamische Testtechniken nicht besitzen. Symbolisches Testen besitzt die folgenden Eigenschaften: >

Der Quellcode des symbolisch zu testenden Software-Moduls wird mit allgemeinen symbolischen Werten durch einen Interpreter ausgeführt.

>

Der symbolische Test prüft in einer künstlichen Umgebung.

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Bild der Spezifikation

Abbildung 10.1 Arbeitsweise des symbolischen Tests

>

Der symbolische Test gewinnt allgemeine Aussagen über die Korrektheit für ganze Eingabebereiche.

>

Der symbolische Test ist im Allgemeinen kein Stichprobenverfahren.

>

Er kann für bestimmte Software-Module die Korrektheit beweisen.

>

Der symbolische Test nimmt eine Stellung zwischen dem dynamischen Test, der statischen Analyse und der Verifikation ein.

Abb. 10.1 zeigt das Prinzip des symbolischen Tests. Er verlangt im Unterschied zu den dynamischen Testtechniken keine Testläufe eines übersetzten Programms in einer realen Testumgebung. Stattdessen führt ein Interpreter das Quellprogramm mit symbolischen Werten aus. Bei dieser Interpretation des Quellcodes entstehen Paare von Ausdrücken. Jedes Paar ist genau einem Pfad zugeordnet. Es besteht aus einer Pfadbedingung und dem Ergebnis. Die Pfadbedingung gibt an, wie die Eingaben beschaffen sein müssen, um den betrachteten Pfad auszuführen. Das Ergebnis ist dem betrachteten Pfad zugeordnet. Es gibt die Werte der Ausgabevariablen unter der Voraussetzung an, dass die Eingabewerte die Pfadbedingung erfüllen. Alle Ausdrücke sind symbolische Ausdrücke aus Operatoren, Konstanten und Eingabevariablen bzw. den initial gewählten symbolischen Werten der Eingabevariablen.

10.2 Symbolischer Test

Das Prinzip des symbolischen Tests.

323

Der symbolische Test kann – falls die entsprechenden Voraussetzungen erfüllt sind – die Korrektheit beweisen.

Überdecken die Pfadbedingungen den gesamten Eingabebereich und sind die Ergebnisausdrücke gemessen an der Spezifikation korrekt, so ist für das Quellprogramm die Korrektheit gezeigt. Man hat in diesem Fall demonstriert, dass man für alle möglichen Eingaben das korrekte Ergebnis erhält. Der symbolische Test kann aus diesem Grund als formales Beweisverfahren betrachtet werden. Die Abdeckung des gesamten Eingabebereichs durch Pfadbedingungen kann – wie leicht einzusehen ist – nur gelingen, wenn das symbolisch zu testende Software-Modul eine hinreichend kleine Anzahl von Pfaden besitzt. Bei einer zu großen oder gar unendlichen Pfadanzahl können nicht alle Pfade berücksichtigt werden. In diesem Fall gelingt der Korrektheitsnachweis durch symbolisches Testen nicht. Neben einer zu großen Pfadanzahl existieren weitere Probleme des symbolischen Tests, die im folgenden noch näher ausgeführt werden.

Der dynamischer Test verhält sich zur Zahlenarithmetik wie der symbolischer Test zur Algebra.

Eine sinnvollere Bezeichnung für den symbolischen Test ist der Begriff symbolische Interpretation. Da die Bezeichnung symbolischer Test allgemein üblich ist, wird sie im weiteren dennoch verwendet. Das Verhältnis zwischen dem klassischen dynamischen Test und dem symbolischen Test ist vergleichbar mit dem Verhältnis zwischen der einfachen Arithmetik für Zahlen und der Algebra. Während der dynamische Test und die Zahlenarithmetik Aussagen nur für einzelne konkrete Werte liefern können, sind der symbolische Test und die Algebra in der Lage Ergebnisse für allgemeinere symbolische Werte zu gewinnen.

Testdatengeneratoren sind oft symbolisch arbeitende Werkzeuge.

Ein Bindeglied zwischen dem symbolischen und dem dynamischen Test sind die Testdatengeneratoren, die in der Regel durch symbolische Ausführung Unterstützung für die Erzeugung von Testdaten für den dynamischen Test bieten /Ramamoorthy et al. 76/. Diese Vorgehensweise erscheint zunächst unlogisch, da der symbolische Test durch die allgemeineren Aussagen, die er gewinnen kann, eine höhere Leistungsfähigkeit als der dynamische Test zu besitzen scheint. Darüber hinaus ist die Anwendung von Testdatengeneratoren zur Unterstützung dynamischer Tests umstritten, da eine automatische Testdatengenerierung für die Fehlerentdeckung kontraproduktiv wirken kann. Der Tester muss sich nicht mehr mit dem Quellcode befassen. Die automatisch erzeugten Testfälle sind oft trivial und daher wenig aussagefähig. Durch einen dynamischen Testlauf wird die korrekte Arbeitsweise ausschließlich für den durchgeführten Testfall sichergestellt. Symbolische Interpretation erzeugt im Gegensatz dazu Aussagen bezüglich ganzer Eingabedatenbereiche. Die Einschätzung des symbolischen Tests als leistungsfähigeres Verfahren ist folglich durchaus berechtigt. Andererseits besitzt auch der symbolische Test seine spezifischen Schwächen.

Die Probleme des symbolischen Tests

324

Da symbolische Ergebnisse stets einem Pfad zugeordnet sind, ist für Programme mit unbeschränkter Pfadanzahl auch die Anzahl der symbolischen Ausdrücke unbeschränkt. Der symbolische Test kommt in diesem Fall zu keiner vollständigen Aussage. Ist die Zielsetzung lediglich die Erzeugung von Testdaten für einige konkrete Pfade im Rahmen eines dyna-

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

mischen Tests, so kann der symbolische Test für diese Pfade durchaus zu einem Ergebnis führen. Ein weiteres Problem sind die gerade in modernen Programmiersprachen verfügbaren Datenstrukturen, wie Felder oder Zeiger. Wird auf ein Feld zugegriffen, so besitzt während der symbolischen Ausführung auch der Feldindex oft nur einen symbolischen Wert, so dass recht schnell die Anzahl der in Frage kommenden Möglichkeiten des Zugriffs von Feldelementen unhandhabbar wird. Dies führt in diesem Fall zu einer Unpraktikabilität genereller symbolischer Aussagen. Die Beschränkung auf einige wenige Testpfade für den dynamischen Test bietet die Möglichkeit zur Vereinfachung des Problems durch Wahl von konkreten Werten, die den geforderten Pfad ausführen. Auf die Berücksichtigung aller möglichen konkreten Werte z. B. für den symbolischen Wert eines Feldindexes kann verzichtet werden. Kann ein Software-Modul durch symbolischen Test verifiziert werden, so scheint der dynamische Test überflüssig. Diese Annahme ist jedoch nicht korrekt. Der symbolische Test prüft ein Quellprogramm. Ein korrektes Quellprogramm muss jedoch nicht notwendig in der übersetzten, lauffähigen Form korrekt arbeiten. Gründe für dieses Verhalten sind die Möglichkeit von Compilerfehlern, die zu einer fehlerhaften Übersetzung des Quellprogramms und Schwierigkeiten mit bestimmten Datentypen führen. Ein weiteres Problem ist die Zugrundelegung einer künstlichen Umgebung im Rahmen des symbolischen Tests, die von der realen Umgebung des letztendlich installierten Programms abweichen kann. Schließlich können durch den symbolischen Test keine Aussagen über das Laufzeitverhalten (Echtzeitfähigkeit) gewonnen werden. Derartige Daten können nur durch einen dynamischen Test des ablauffähigen Programms in der realen Laufzeitumgebung gewonnen werden.

10.2.2

Beschreibung des symbolischen Tests

Im Prinzip ist ein symbolischer Test nichts anderes als ein Pfadüberdeckungstest mit symbolischen Werten auf dem Quellcodeniveau. Durch den Verzicht auf konkrete Werte können durch einen symbolischen Testfall sehr viele – manchmal unendlich viele – dynamische Testfälle ersetzt werden. Das Prinzip kann man sich anhand eines einfachen Beispiels aus der Mathematik verdeutlichen:

Ein quadratischer Zusammenhang kann für eine kleine Menge von Zahlen – z. B. alle natürlichen Zahlen zwischen 1 und 5 – noch vollständig in Form einer Aufzählung dargestellt werden:

Symbolischer Test = Pfadüberdeckungstest mit symbolischen Werten

BEISPIEL

12 = 1, 22 = 4, 32 = 9, 42 = 16, 52 = 25

10.2 Symbolischer Test

325

Dies gelingt nicht mehr, wenn der Zusammenhang für alle natürlichen Zahlen dargestellt werden soll, weil diese nicht vollständig aufgezählt werden können. Aber auch bei der Betrachtung einer großen endlichen Menge – z. B. alle natürlichen Zahlen zwischen 1 und 1.000.000 – wird man die Aufzählung jedes einzelnen Falles als unpraktikabel empfinden. Ganz unmöglich wird die Darstellung als Aufzählung, wenn man als Definitionsbereich z. B. die positiven reellen Zahlen wählt. Jeder konkrete Fall, der angegeben wird √ 2 (z. B. 2 = 2), ist nur ein Beispiel aus einer unendlich großen Grundmenge. In der Mathematik nutzt man Variablen, um nicht mit konkreten Werten hantieren zu müssen, sondern allgemeine Zusammenhänge darstellen zu können. Man führt z. B. die Variablen x und y ein und schreibt einfach x2 = y. Weil nun keine konkreten Werte gegeben sind, muss festgelegt werden, welche Werte für x eingesetzt werden dürfen. Man muss den Definitionsbereich angeben. Man könnte z. B. x2 = y für alle x ∈ R fordern. Auf diese Weise stellt man für eine definierte unendlich große Menge von Fällen einen allgemeinen Zusammenhang geschlossen dar. Beim symbolischen Testen wird ganz analog vorgegangen, um mit der oft sehr großen Menge von Testdaten umgehen zu können. Die oben eingeführten Variablen x und y würde man beim symbolischen Testen als symbolische Werte bezeichnen, da der Begriff der Variablen in der Programmierung bereits belegt ist. Symbolische Werte sind wie die Variablen x und y Stellvertreter für eine eventuell sehr große, genau definierte Menge konkreter Werte. Mit symbolischen Werten kann grundsätzlich genau so „gerechnet“ werden, wie mit konkreten Werten. So kann z. B. der Ausdruck 2x = y umgeformt y werden in x = . 2

Variablenname = Benennung einer Speicherstelle

Symbolischer Wert = Inhalt einer Speicherstelle

Es ist wichtig, beim symbolischen Test sicher zwischen Variablennamen und ihren symbolischen Werten unterscheiden zu können. Ein Variablenname ist im Prinzip die Benennung einer Speicherstelle. Diese Benennung ist während der Existenz der Variablen im Speicher unveränderlich. Variablen besitzen Werte. Werte sind die Inhalte von Speicherstellen. Diese Inhalte verändern sich im Allgemeinen während der Programmausführung. Das gilt für konkrete und symbolische Werte gleichermaßen. Betrachten wir die Variable mit Namen x. Ihr Wert – also der Inhalt der Speicherstelle x – mag aktuell 4 sein. Zu einem anderen Zeitpunkt der Programmausführung hat er sich auf den Wert 5 verändert. Die Variable heißt aber unverändert x. Führen wir für den Initialwert der Variable x den symbolischen Wert X ein, so wird die Variable x zu einem späteren Zeitpunkt der symbolischen Programmausführung möglicherweise den Wert X + 1 besitzen. Die symbolischen Werte der Variablen verändern sich; der Variablenname ist unveränderlich.

326

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Beim symbolischen Test werden die Werte der Programmvariablen durch symbolische Ausdrücke dargestellt /King 76/. Zu Beginn der symbolischen Ausführung des Quellprogramms werden den Eingabevariablen symbolische Werte zugewiesen. So kann ein symbolisches Testwerkzeug einer Variablen x den symbolischen Wert X zuweisen. Die Unterscheidung von Variablen und ihren symbolischen Werten ist wichtig. Die symbolischen Werte der Variablen sind Ausdrücke aus den symbolischen Anfangswerten der Variablen, Konstanten und Operatoren. Mit fortschreitender symbolischer Ausführung werden diese Ausdrücke zunehmend umfangreicher. Da auf symbolische Ausdrücke algebraische Umformungen anwendbar sind, ist glücklicherweise häufig eine Reduktion dieser Komplexität möglich. So kann z. B. der symbolische Ausdruck Z + X +Y − 1 −Y vereinfacht werden zu Z + X − 1. Die symbolische Vereinfachung von Ausdrücken birgt insbesondere bei Beteilung von Fließpunktdatentypen Risiken, da Rundungsungenauigkeiten, die bei der realen Ausführung auftreten, bei der symbolischen Ausführung unterdrückt werden. Dies kann Abweichungen zwischen dem symbolischen und dem konkreten Ergebnis verursachen. Trifft der Interpreter bei der symbolischen Programmausführung auf eine Verzweigung, so kann in der Regel nicht entschieden werden, welcher Zweig für die weitere Programmausführung zu wählen ist, da der weitere Kontrollfluss von den konkreten Werten der Programmvariablen bestimmt wird. Verfügbar sind nur abstrakte symbolische Werte. In dieser Situation sind alle Programmzweige weiter zu verfolgen. Die Bedingung an der Verzweigungsstelle ist mit den symbolischen Werten der beteiligten Variablen zu evaluieren und der Pfadbedingung durch UNDVerknüpfung hinzuzufügen. Der Anfangswert der Pfadbedingung ist die Vorbedingung des betrachteten Programms bzw. die Boolesche Konstante wahr, falls keine Vorbedingung existiert. Ausgehend vom Programmbeginn entsteht ein Baum aus Anweisungen. Ein Pfad von der Wurzel – dem Programmbeginn – zu einem Blatt des Baums entspricht einem vollständigen Pfad durch das Programm. Die jedem Blatt zugeordnete Pfadbedingung legt die Eingabedaten fest, die eine Programmausführung entlang des Pfades bewirken, der in dem betrachteten Blatt endet. Ferner ist jedem Blatt ein Ausdruck mit den symbolischen Werten der Ausgabevariablen zugeordnet.

Durchführung der symbolischen Interpretation

Neben der Vorbedingung, die die Eigenschaften der Variablenwerte zu Beginn beschreibt, existiert die Nachbedingung – die Spezifikation – , die die Eigenschaften der Variablenwerte nach der Ausführung des Programms darstellt. Sie beschreibt die Funktionalität des Programms. Ein Programm ist dann mittels symbolischem Test als korrekt bewiesen, falls aufgrund der symbolischen Ergebnisse am Ende aller Programmpfade gezeigt werden kann, dass die Nachbedingung wahr ist.

10.2 Symbolischer Test

327

BEISPIEL

Für die Eingabevariablen Min und Max der Operation MinMax nach Abb. 10.2 existiert keine Vorbedingung. Daher wird für die Vorbedingung die Boolesche Konstante true (wahr) verwendet. Im Folgenden werden Variablennamen mit Groß- und Kleinbuchstaben geschrieben. Symbolische Werte werden ausschließlich mit Großbuchstaben notiert.

Abbildung 10.2 Symbolische Ausführung der Operation „MinMax“

Die aus der Spezifikation gewonnene Nachbedingung muss zum Ausdruck bringen, dass nach Ausführung der Prozedur die Variable Min stets einen Wert besitzt, der kleiner oder gleich dem Wert der Variablen Max ist. Außerdem dürfen die Eingabewerte der Variablen höchstens vertauscht, nicht jedoch abgeändert worden sein. Verwenden wir die symbolischen Eingabewerte MIN bzw. MAX für die Variablen Min bzw. Max, so kann die Nachbedingung folgendermaßen formuliert werden: Min ≤ Max ∧ [(Min = MIN ∧ Max = MAX) ∨ (Min = MAX ∧ Max = MIN)] Zu Beginn der symbolischen Ausführung wählt der Interpreter symbolische Werte für die Eingabevariablen Min und Max und initialisiert die Pfadbedingung (Path Condition; kurz: PC) (1. in Abb. 10.2). Die Variable Hilf ist zu diesem Zeitpunkt noch nicht angelegt. Anschließend wird die Variable Hilf angelegt (2. in Abb. 10.2). Da es sich um eine uninitialisierte, lokale Variable handelt wird kein symbolischer Wert gewählt. Es ist sinnvoll, Variablen mit einem definierten, beliebigen Wert von Variablen mit einem undefinierten Wert zu unterscheiden. Letztere werden durch ein „?“ anstelle eines symbolischen Werts gekennzeichnet. Die Überprüfung der Entscheidung if (Min > Max) ... führt zu der folgenden Situation: Es werden die symbolischen Werte der Variablen eingesetzt, d. h. Min wird durch MIN und Max wird durch MAX ersetzt. Man erhält if (MIN > MAX) .... Ob diese Entscheidung das Ergebnis wahr oder falsch ergibt, ist anhand der symbolischen Werte nicht bestimmbar. Offensichtlich existieren beide Möglichkeiten. Daher müssen beide Möglichkeiten wei-

328

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

terverfolgt werden. Die symbolische Ausführung verzweigt an dieser Stelle (3. in Abb. 10.2). Zunächst soll der Fall untersucht werden, dass die Entscheidung das Ergebnis wahr liefert. Dies geschieht, falls gilt: MIN > MAX. Die getroffene Wahl muss festgehalten werden, da sie den ausgeführten Pfad beeinflusst. Diejenigen konkreten Werte von MIN und MAX, die eingesetzt in MIN > MAX eine wahre Aussage ergeben, führen den zugeordneten Pfad aus. Daher ist die Forderung MIN > MAX Bestandteil der Pfadbedingung. In diesem Fall wird der Anweisungsteil des if -Konstrukts ausgeführt. Zunächst wird der Variable Hilf der symbolische Wert der Variablen Min zugewiesen. Hilf ist nun nicht mehr undefiniert, sondern besitzt den symbolischen Wert MIN (4. in Abb. 10.2). Anschließend wird der symbolische Wert der Variable Max der Variable Min zugewiesen (5. in Abb. 10.2). Schließlich erhält Max den symbolischen Wert der Variable Hilf (6. in Abb. 10.2). Am Ende dieses Pfades erhält man das folgende Ergebnis (7. in Abb. 10.2): MIN > MAX ∧ Min = MAX ∧ Max = MIN ∧ Hilf = MIN MIN > MAX ist die Pfadbedingung. Min = MAX, Max = MIN und Hilf = MIN sind die Ergebnisausdrücke. Durch Ersetzung und Verzicht auf die Variable Hilf folgt: Max > Min ∧ Min = MAX ∧ Max = MIN Nun ist noch der Fall zu untersuchen, dass die Entscheidung if (MIN > MAX) .... das Ergebnis falsch liefert. Dies geschieht, falls gilt: ¬ (MIN > MAX), also (MIN ≤ MAX). In diesem Fall wird der Anweisungsteil des if -Konstrukts nicht ausgeführt (8. in Abb. 10.2). Am Ende dieses Pfades erhält man das folgende Ergebnis (9. in Abb. 10.2): MIN ≤ MAX ∧ Min = MIN ∧ Max = MAX Durch Ersetzung folgt: Min ≤ Max ∧ Min = MIN ∧ Max = MAX Da die unterschiedlichen Programmpfade Alternativen darstellen, müssen die symbolischen Ausdrücke aller Pfade disjunktiv verknüpft werden. Die Verknüpfung ergibt: (Max > Min ∧ Min = MAX ∧ Max = MIN) ∨ (Min ≤ Max ∧ Min = MIN ∧ Max = MAX) ⇒ Min ≤ Max ∧ [(Min = MAX ∧ Max = MIN) ∨ (Min = MIN ∧ Max = MAX)] (Nachbedingung) Die Ergebnisse des symbolischen Tests implizieren die geforderte Nachbedingung. Die Korrektheit ist gezeigt.

Der symbolische Ausführungsbaum der Operation MinMax nach Abb. 10.3 enthält zu jeder Anweisung des Moduls einen Knoten. Jedem Knoten können die symbolischen Werte der Variablen und die Pfadbedingung zu-

10.2 Symbolischer Test

Symbolischer Ausführungsbaum

329

geordnet werden. In Abb. 10.3 sind diese Informationen nur an einigen Knoten angegeben. Der Ausführungsbaum verzweigt sich an Knoten, die eine verzweigende Kontrollstruktur des Programms darstellen, falls nicht bestimmt werden kann, ob die Verzweigungsbedingung wenn sie mit den symbolischen Werten der Variablen evaluiert wird, eine Boolesche Konstante ergibt. In Abb. 10.3 verzweigt sich der Ausführungsbaum in Knoten n1 . Die an den Blättern des Ausführungsbaums angegebenen symbolischen Variablenwerte und Pfadbedingungen geben das symbolische Ergebnis des Pfads von der Wurzel des Ausführungsbaums zum betrachteten Blatt an. Die Anzahl der Pfade des Kontrollflussgraphen entspricht der Anzahl der Blätter des Ausführungsbaumes.

Die Darstellung des symbolischen Tests als Ausführungsbaum zeigt direkt eines der Probleme des symbolischen Tests. Falls ein Software-Modul eine große Anzahl von Pfaden besitzt, so ist der Ausführungsbaum entsprechend kompliziert. Besonders störend ist eine unbeschränkte Pfadanzahl, die von Schleifen verursacht werden kann. Dies ist in der Regel dann gegeben, falls Schleifen verwendet werden, deren Termination von im Schleifenkörper modifizierten Variablen abhängig ist. Da die Variablen, deren Werte die Schleifentermination bestimmen, während der symbolischen Ausführung symbolische Werte besitzen, ist in der Regel nicht bestimmbar, ob eine Schleife abgebrochen wird oder weitere Iterationen stattfinden. Bei jeder Prüfung der Abbruchbedingung entsteht ein weiterer Ast des Ausführungsbaums, der demzufolge eine unbeschränkte Größe erhält.

Abbildung 10.3 Kontrollflussgraph und symbolischer Ausführungsbaum

330

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Abbildung 10.4 Kontrollflussgraph des Moduls zur ganzzahligen Division

Ein bekanntes Beispiel, das sich gut zur Demonstration der Arbeitsweise und zur Verdeutlichung der Problematiken des symbolischen Tests und der formalen Verifikation eignet, ist das in Abb. 10.4 angegebene Beispiel zur ganzzahligen Division mit Rest. Das Modul berechnet zu einem ganzzahligen Dividenden und Divisor den ganzzahligen Quotienten und den Divisionsrest. Die symbolischen Werte des Divisors und des Rests entscheiden über den Schleifenabbruch. Da zum Zeitpunkt der Evaluation der Schleifenbedingung nicht entschieden werden kann, ob die Bedingung wahr oder falsch ist, entsteht für jede Prüfung der Schleifenbedingung ein weiterer Ast des Ausführungsbaums. Es entsteht ein symbolischer Ausführungsbaum, der bis zur zweiten Schleifenausführung in Abb. 10.5 dargestellt ist. Der vollständige Ausführungsbaum ist nicht mehr sinnvoll darstellbar. Symbolische Testwerkzeuge sehen zur Behandlung dieser Problematik unterschiedliche Ansätze vor. Eine Möglichkeit ist die Beschränkung der Ausführung auf ausschließlich jene Pfade, die nicht mehr als eine bestimmte Anzahl von Schleifendurchläufen verursachen. Leider bewirkt die Beschränkung der symbolischen Ausführung auf wenige Pfade im gleichen Maße die Reduzierung der Allgemeingültigkeit der gewonnenen Aussagen.

10.2 Symbolischer Test

Beschränkung der Pfadanzahl durch Einschränkung bei der Schleifeninterpretation.

331

Abbildung 10.5 Symbolischer Ausführungsbaum

Felder und Zeiger verursachen Probleme beim symbolischen Test.

Die symbolische Programmausführung wird nicht nur durch die dargestellten Probleme im Zusammenhang mit Kontrollstrukturen erschwert, sondern auch durch Datenstrukturen wie Felder oder Zeiger. Benutzt ein Programm Felder, so ist während der symbolischen Ausführung der Feldindex in der Regel ein symbolischer Wert, so dass im Allgemeinen nicht entschieden werden kann, auf welches konkrete Feldelement zugegriffen wird. Diese Mehrdeutigkeiten in bezug auf die Datenzugriffe führt zu einem schnellen Anstieg der Komplexität, der mit dem durch Schleifen verursachten Komplexitätsanstieg vergleichbar ist. Ein zu der Mehrdeutigkeit von Feldzugriffen analoges Problem entsteht durch dynamische Datenstrukturen, die durch dynamisches Erzeugen von Variablen unter Verwendung von Zeigern entstehen. Die konkret zu einem Zeitpunkt existierende Datenstruktur ist stark von der Programm-

332

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

ausführung seit dem Programmstart abhängig und entsprechend mehrdeutig. Im Zusammenhang mit der Verwendung von Fließpunktdatentypen entstehen Schwierigkeiten durch die Diskrepanz zwischen der stets mit Darstellungsungenauigkeiten behafteten Arithmetik eines Computers und der beliebigen Darstellungsgenauigkeit reeller Zahlen. Im allgemeinen Fall gilt für die Programmausführung das folgende Kommutativgesetz: Die symbolische Ausführung gefolgt von der Ersetzung der symbolischen Werte durch konkrete Werte muss zu dem gleichen Ergebnis führen wie die Wahl konkreter Eingaben gefolgt von einer konventionellen Programmausführung (Abb. 10.6).

Abbildung 10.6 Kommutativgesetz der Programmausführung bei Abwesenheit von Fließpunktdaten

Diese Kommutativität geht in Gegenwart von Fließpunktdatentypen verloren. Die symbolische Ausführung beachtet den diskreten Charakter, den reelle Zahlen in der Computerarithmetik besitzen, in der Regel nicht und behandelt Fließpunktzahlen folglich als wertkontinuierlich. In der symbolischen Ausführung entstehen keine Rundungsfehler. Ein Einsetzen von konkreten Werten in die symbolischen Ergebnisse führt zu absolut genauen Werten. Wird ein Programm mit konkreten Eingaben konventionell ausgeführt, so entstehen zwangsläufig Rundungsfehler durch die Rechengenauigkeit mit Fließpunktdatentypen. Das Kommutativgesetz gilt in Gegenwart von Fließpunktdaten daher nicht (Abb. 10.7).

10.2.3

Fließpunktdaten werden im symbolischen Test oft nicht vollständig korrekt behandelt.

Bewertung des symbolischen Tests

Die im Vergleich zu dynamischen Tests zu erwartende höhere Leistungsfähigkeit des symbolischen Tests wird durch einige empirische Studien bestätigt. Howden hat in einer vergleichenden Untersuchung meh-

10.2 Symbolischer Test

Empirische Daten zur Leistungsfähigkeit des symbolischen Tests

333

Abbildung 10.7 Ungültigkeit des Kommutativgesetzes der Programmausführung in Gegenwart von Fließpunktdaten

rerer dynamischer Testverfahren, der statischen Anomalieanalyse und des symbolischen Tests eine um 10 bis 20 Prozent höhere Fehlerentdeckungsrate für den symbolischen Test als für den strukturierten Pfadtest erhalten. Diese Studie /Howden 78a, Howden 78b, Howden 78c/ bezieht sich auf sechs Programme in unterschiedlichen Programmiersprachen. Die Pfadanzahl wird für die symbolische Ausführung durch Beschränkung der Anzahl der Schleifendurchläufe endlich gehalten. Die symbolische Programmausführung entspricht demzufolge einem strukturierten Pfadtest mit symbolischen Werten. Ein Vergleich zu dem dynamischen, strukturierten Pfadtest mit konkreten Eingabewerten bietet sich aus diesem Grunde an. Die höhere Aussagekraft des symbolischen Tests wird in diesem Fall allein durch die allgemeineren Aussagen der symbolischen Ergebnisse erreicht. Die Bewertung symbolischer Ausdrücke kann schwierig sein.

334

Nicht in jedem Fall ist diese größere Allgemeinheit symbolischer Ergebnisse nützlich. Eine empirische Studie /Howden 77/ zeigt, dass die Fehlererkennung anhand von symbolischen Ausdrücken oft kompliziert ist. Ist ein Fehler im Quelltext des Programms nicht erkannt worden, so ist es wahrscheinlich, dass er in einem symbolischen Ausdruck ebenfalls nicht als fehlerhaft registriert wird. Als Beispiel nennt Howden in diesem Zusammenhang vergessene Klammern oder die Verwendung von Fließpunktvariablen in Pfadbedingungen, die einen Gleichheitsoperator verwenden. Es ist nicht anzunehmen, dass ein Entwickler, dem derartige Fehler während der Software-Erstellung entgangen sind, diese Fehler in der symbolischen Ausgabe eines Testwerkzeugs erkennt. In der Studie ist die Mehrzahl der entdeckten Fehler vom Typ Berechnungsfehler. Die Mehrzahl der unentdeckten Fehler sind Pfadbereichsfehler. Howden ist der Ansicht, dass die symbolische Pfadbedingung keinen deutlicheren Hinweis auf den Fehler gibt als der Programmtext selbst: „... the symbolic systems of predicates for the domains do not contain anything that is any

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

more likely to catch the programmer’s attention than the error in the original program“ /Howden 77/. Die Gewinnung umfassender, allgemeiner Aussagen für ganze Eingabeklassen durch die weitgehende Abkehr vom Stichprobencharakter des dynamischen Tests ist eine positive Eigenschaft des symbolischen Tests. Leider kann dieser Vorteil in der Praxis oft nicht vollständig ausgeschöpft werden, weil zu hohe Pfadanzahlen und bestimmte Datenstrukturen oder Datentypen dies verhindern. Nachteilig sind die genannten Schwierigkeiten beim Umgang mit Fließpunktdaten sowie die Nichtbeachtung der realen Systemsoftware- und Hardware-Plattform. Darüber hinaus sind Aussagen über das Zeitverhalten nicht möglich. Professionelle Werkzeugunterstützung wird nur in geringem Umfang angeboten. Einerseits ist der symbolische Test theoretisch leistungsfähig. Andererseits bereitet seine praktische Umsetzung Schwierigkeiten.

10.3

Formaler Korrektheitsbeweis

10.3.1

Eigenschaften und Ziele des formalen Korrektheitsbeweises

Der formale Korrektheitsbeweis demonstriert mit formalen Mitteln die Konsistenz zwischen einer Spezifikation und ihrer Realisierung. Hier ist die Realisierung oft der Programmcode. Es ist eine formale Spezifikation erforderlich. Formale Spezifikationen können z. B. In der Sprache Z erstellt werden. Der Korrektheitsbeweis „vergleicht“ die Spezifikation und ihre Realisierung, die je nach Verfahren unterschiedlich repräsentiert sein können. Zusicherungsverfahren verwenden eine Eingangs- und eine Ausgangszusicherung als Spezifikation und verifizieren den Quellcode des Programms. Automatenbasierte Techniken weisen nach, dass ein Zustandsautomat spezifizierte Eigenschaften besitzt, die z. B. als temporallogische Formel gegeben sein können. Prinzipiell kann durch einen formalen Korrektheitsbeweis eine vollständige Aussage zur Korrektheit erzeugt werden. In der Praxis existieren jedoch Einschränkungen. Formale Korrektheitsbeweise können häufig automatisiert werden. Oft gelingt das aber nicht vollständig. So können z. B. die bei den Zusicherungsverfahren benötigten Schleifeninvarianten nicht automatisch gefunden werden, so dass ein manueller Eingriff erforderlich ist (Abb. 10.8).

10.3.2

Zusicherungsverfahren

10.3.2.1

Das Floyd’sche Verifikationsverfahren

Die Basis der formalen Verifikation bildet die formale Beschreibung der Semantik der Programmiersprache. Floyd hat bereits 1967 die Idee entwi-

10.3 Formaler Korrektheitsbeweis

Formale Beschreibungen der Semantik sind die Basis der formalen Verifikation. 335

Abbildung 10.8 Prinzip der formalen Verifikation

ckelt, die Semantik von Programmiersprachen unabhängig von den Prozessoren für Sprachen zu beschreiben. Die Basis für die Semantikdefinition eines Programms bilden die Daten. Sieht man die Funktionalität eines Programms in der Transformation von Eingaben in Ausgaben, so kann die Semantik des Programms durch die Formulierung von Relationen über die Eingaben und Relationen über die Ausgaben dargestellt werden. Diese Semantikbeschreibung besitzt die Form: Falls die Eingabewerte des Programms die Relation R1 erfüllen, so erfüllen die Ausgabewerte die Relation R2 . Diese Beschreibungsform ist auch zur Definition der Semantik von Programmelementen – z. B. Anweisungen, Auswahlkonstrukten und Schleifen – geeignet. Floyd bezieht seinen Ansatz auf Flussgraphen. Man kann auch Programm-Ablauf-Pläne oder Kontrollflussgraphen verwenden. Die Grundidee aller so genannten induktiven Zusicherungsverfahren ist die Beschreibung der Wirkung eines Verarbeitungsschritts durch seine Einflussnahme auf den Zustand des Programms, der z. B. durch die Werte der Variablen dargestellt werden kann. Man kann sich das anhand eines einfachen Beispiels verdeutlichen.

336

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Betrachten wir die Zuweisung y = x, d. h. der Wert der Variable x wird der Variable y zugewiesen. Offensichtlich werden nach der Ausführung dieser Anweisung all jene Eigenschaften, die vor der Ausführung der Anweisung für die Variable x gültig waren, nun auch für die Variable y gültig sein. Falls z. B. vor Ausführung der Zuweisung bekannt ist, dass die Variable x einen positiven Wert besitzt, so kann man sicher sein, dass nach der Ausführung der Zuweisung auch die Variable y einen positiven Wert besitzen wird. Und weil der Wert der Variable x dabei nicht verändert wird, besitzt sie nach wie vor ebenfalls einen positiven Wert, und die Werte von x und y werden identisch sein. Das funktioniert aber nur, wenn der Zustand des Programms vor der Ausführung der Zuweisung bekannt ist. Falls über die Variable x vor der Zuweisung nichts bekannt ist, so kann auch keine Aussage über y nach der Zuweisung gemacht werden, außer dass x und y identisch sein werden. Die Wirkung der Zuweisung besitzt zwei Aspekte. Sie „kopiert“ alle Eigenschaften der Variable x auf die Variable y, und sie „erzwingt“, dass x und y anschließend identische Werte besitzen. Die Situation vor dem Verarbeitungsschritt wird aus der Situation danach abgeleitet.

Die vor und nach einem Verarbeitungsschritt gültigen Situationen können in Form von sogenannten Zusicherungen (assertions) angegeben werden. Beim Floyd’schen Verfahren schreibt man die Zusicherungen an Flussgraphen. Abb. 10.9 zeigt einen Ausschnitt eines Programm-AblaufPlans mit Zusicherungen, der dem angegebenen Beispiel entspricht.

BEISPIEL

Zusicherung = assertion

Abbildung 10.9 Zusicherungen (ein Verarbeitungsschritt)

Fügt man nun mehrere Schritte zusammen, so ergibt sich eine Kette von Zusicherungen. Aus jeder Zusicherung wird dabei die nachfolgende Zusicherung abgeleitet, die ihrerseits als Ausgangsbasis für die nachfolgende Zusicherung dient (Abb. 10.10). Betrachtet man ein vollständiges Software-Modul oder Programm, so gibt es in der Kette von Zusicherungen eine erste und eine letzte Zusicherung. Die erste Zusicherung bezeichnet man als Vorbedingung. Die letzte Zusicherung heißt Nachbedingung. Die Aufgabe der formalen Verifikation mit dem Floyd’schen Zusicherungsverfahren ist nun zu zeigen, dass aus der Gültigkeit der Vorbedingung gefolgert werden kann, dass die Nachbedingung nach der Ausführung ebenfalls

10.3 Formaler Korrektheitsbeweis

Aus der Gültigkeit der Vorbedingung muss die Gültigkeit der Nachbedingung folgen.

337

Abbildung 10.10 Zusicherungen (mehrere Verarbeitungsschritte)

gültig sein wird (Abb. 10.11). Vorbedingungen werden unbewiesen als wahr akzeptiert. Sie geben an, welche Einschränkungen für Eingabeparameter gefordert sind. Anders formuliert: Sie definieren eine Regel, an die sich der Dienstnutzer zu halten hat. Falls der Dienstnutzer die Vorbedingung nicht erfüllt, so bricht er seinen Teil des „Vertrags“ zwischen Dienstnutzer und Dienstanbieter. Dieser Vertrag hat den folgenden Inhalt: „Falls der Dienstnutzer die Vorbedingung des Dienstanbieters erfüllt, so garantiert der Dienstanbieter ein entsprechend seiner Nachbedingung korrektes Ergebnis“. Die Gültigkeit der Vorbedingung wird ohne Beweis akzeptiert.

Da für den Fall, dass der Dienstnutzer die Vorbedingung nicht beachtet, kein korrektes Ergebnis zugesichert wird, ist für diesen Fall kein Korrektheitsnachweis notwendig. Er ist nur unter der Prämisse sinnvoll, dass die Vorbedingung erfüllt ist. Daher wird sie unbewiesen als wahre Aussage akzeptiert. Abb. 10.11 zeigt die Vorbedingung und Nachbedingung des Software-Moduls zur ganzzahligen Division mit Rest aus Abschnitt 10.2 Die Vorbedingung fordert, dass der Dividend nicht negativ ist. Der Divisor muss positiv sein. Der Fall Divisor = 0 muss wegen der sonst stattfindenden Division durch Null ausgeschlossen werden. Die Nachbedingung spezifiziert das erwartete Ergebnis. Bei einer Division mit Rest muss „die Probe aufgehen“. Addiert man zum Rest das Produkt aus Quotient und

Abbildung 10.11 Vor- und Nachbedingung

338

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Divisor hinzu, so muss sich der Dividend ergeben. Das allein reicht aber nicht aus, wie man sich anhand eines Beispiels verdeutlichen kann.

Die folgenden Werte erfüllen alle die Gleichung Dividend = Rest + Quotient * Divisor: >

Dividend = 24, Divisor = 5, Rest = 9, Quotient = 3

>

Dividend = 24, Divisor = 5, Rest = -1, Quotient = 5

>

Dividend = 24, Divisor = 5, Rest = 4, Quotient = 4

BEISPIEL

Es muss offensichtlich zusätzlich gefordert werden, dass der Rest kleiner als der Divisor aber nicht negativ ist, also: 0 ≤ Rest < Divisor. Nur das korrekte Ergebnis (Dividend = 24, Divisor = 5, Rest = 4, Quotient = 4) erfüllt diese zusätzliche Bedingung.

Die Idee, aus einer Zusicherung vor einem Verarbeitungsschritt die Zusicherung nach dem Verarbeitungsschritt abzuleiten, funktioniert leider manchmal nicht. Zur Verdeutlichung wird der Programm-Ablauf-Plan des Software-Moduls zur ganzzahligen Division mit Rest verwendet (Abb. 10.12). Am Start des Programm-Ablauf-Plans (1. in Abb. 10.12) gilt die Vorbedingung (Dividend ≥ 0 ∧ Divisor > 0). Am Ende (8. in Abb. 10.12) muss die Nachbedingung (Dividend = Rest + Quotient * Divisor ∧ 0 ≤ Rest < Divisor) eine wahre Aussage ergeben. Im ersten Verarbeitungsschritt wird der Variable Quotient der Wert Null zugewiesen. Die Werte der anderen Variablen ändern sich nicht. Man erhält die unter 2. in Abb. 10.12 angegebene Zusicherung. Die Zuweisung des Wertes von Dividend an die Variable Rest führt zu der unter 3. in Abb. 10.12 angegebenen Zusicherung. An dieser Stelle beginnt eine Schleife. Wie man leicht erkennen kann, darf man die unter 3. angegebene Zusicherung nicht „hinter die Einmündung der Schleife“ schreiben. Im Schleifenrumpf wird z. B. der Wert von Quotient erhöht. Daher ist die in 3. enthaltene Zusicherung (Quotient = 0) nach einem Schleifendurchlauf sicherlich falsch, denn Quotient besitzt dann den Wert 1. Im Prinzip besitzt die Stelle des Programm-Ablauf-Plans unmittelbar vor der Schleifenentscheidung mehrere „Vorgänger“. Beim ersten Erreichen der Schleife ist der Vorgänger die letzte Anweisung vor der Schleife. Beim Durchlaufen der Schleife ist es die letzte Anweisung des Schleifenrumpfs. Die Situationen vor der Schleife und nach jedem Schleifendurchlauf werden unterschiedlich sein, und daher werden dort jeweils unterschiedliche Zusicherungen gültig sein. Das induktive Ableiten einer Zusicherung aus der davor gültigen Zusicherung scheitert an dieser Stelle. Man benötigt eine Zusicherung, die unabhängig von der Anzahl der Schleifendurchläufe eine wahre Aussage ergibt. Diese Zusicherung bezeichnet man als Schleifeninvarian-

10.3 Formaler Korrektheitsbeweis

Bei Schleifen scheitert der Automatismus des induktiven Zusicherungsverfahrens.

339

Abbildung 10.12 Annotierter Programm-Ablauf-Plan

te. Schleifeninvarianten müssen gefunden werden; sie können nicht aus anderen Zusicherungen induktiv abgeleitet werden. Die Suche nach einer geeigneten Schleifeninvariante kann zielgerichtet durchgeführt werden. In diesem Beispiel ist das Finden der Schleifeninvariante relativ einfach. In der Schleife wird ein Gleichgewicht zwischen der Verkleinerung des Wertes der Variable Rest und der Erhöhung von Quotient aufgebaut, wobei darauf geachtet wird, dass der Wert von Rest nicht negativ wird. Daher wird behauptet, dass der folgende Ausdruck eine Schleifeninvariante sei: Dividend = Rest + Quotient * Divisor ∧ 0 ≤ Rest Schleifeninvarianten müssen bewiesen werden.

Beweisprinzip: vollständiger Induktionsbeweis

340

Bisher ist dies eine reine Behauptung. Würde man diese Schleifeninvariante unbewiesen verwenden, so bestünde die Gefahr, dass ein fehlerhaftes Programm durch die Nutzung einer falschen Schleifeninvariante möglicherweise als korrekt bewiesen werden könnte. Daher ist zu beweisen, dass der angegebene Ausdruck eine Schleifeninvariante ist. Dieser Beweis folgt stets dem Prinzip der vollständigen Induktion. Induktionsbeweise bestehen aus zwei Teilen – der Induktionsverankerung und dem Schluss von n auf n+1. Die Induktionsverankerung zeigt, dass die zu beweisende Aussage für die Startinstanz wahr ist. Der Schluss von n auf n+1 zeigt, dass aus der Gültigkeit der Aussage für eine betrachtete In-

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

stanz die Gültigkeit für die nachfolgende Instanz gefolgert werden kann. Beide Teile des Beweises zeigen zusammengenommen, dass die Aussage für alle Instanzen wahr sein muss. Die betrachteten Instanzen sind in diesem Fall die Schleifendurchläufe. Für die Induktionsverankerung ist daher die Schleifeninvariante vor dem ersten Schleifendurchlauf zu untersuchen. Dann gilt die unter 3. in Abb. 10.12 aufgeführte Zusicherung: Dividend ≥ 0 ∧ Divisor > 0 ∧ Quotient = 0 ∧ Rest = Dividend ∧ Rest ≤ 0 Es ist zu zeigen, dass unter Nutzung dieser Zusicherung die Schleifeninvariante gilt. Es wird die folgende Induktionsverankerung durchgeführt: Dividend = Rest + Quotient * Divisor ∧ Rest ≥ 0 ist zu verankern. Der zweite Teil der Schleifeninvariante (Rest ≥ 0) ist auch Bestandteil der unter 3. in Abb. 10.12 aufgeführten Zusicherung. Daher ist er wahr. Setzt man in die rechte Seite der Gleichung die Zusicherungen (Quotient = 0) und (Rest = Dividend) aus 3. ein, so erhält man:

Induktionsverankerung

Rest + Quotient * Divisor = Dividend + 0 * Divisor = Dividend Damit ist die Induktionsverankerung erfolgt. Wenn die Schleife erstmals erreicht wird, ist die Schleifeninvariante wahr. Der unter 4. in Abb. 10.12 angegebene Ausdruck ist daher mindestens vor dem ersten Schleifendurchlauf gültig. Nun ist noch der Schluss von n auf n+1 zu leisten. Das kann unter Nutzung des bekannten induktiven Zusicherungsverfahrens durchgeführt werden. Wenn der unter 4. in Abb. 10.12 angegebene Ausdruck gilt, so gilt auch der unter 5. in Abb. 10.12 angegebene Ausdruck, da bei der Überprüfung der Schleifenentscheidung keine Variablenwerte verändert werden. Man gelangt nur dann an die Stelle 5., wenn der Rest nicht kleiner als der Divisor ist. Darum muss die Zusicherung Rest ≥ Divisor ergänzt werden. Im nächsten Schritt wird der Wert von Rest um den Wert von Divisor verringert. Dies muss in der Zusicherung berücksichtigt werden. Um sicherzustellen, dass die Zusicherung weiterhin gilt, muss Rest durch Rest + Divisor ersetzt werden. Man erhält die Zusicherung 6. in Abb. 10.12.

Schluss von n auf n+1

Anschließend wird der Wert von Quotient inkrementiert. Auch dies muss in der Zusicherung berücksichtigt werden. Der Wert der Variable Quotient ist gegen Quotient - 1 auszutauschen. Man erhält die unter 7. in Abb. 10.12 aufgeführte Zusicherung. Vergleicht man diese Zusicherung mit der Zusicherung zu Beginn der Schleife, so stellt man fest, dass sie identisch sind. Die Schleifeninvariante reproduziert sich nach einem Schleifendurchlauf wieder. Damit ist auch der Schluss von n auf n+1 gelungen. Es ist bewiesen, dass der betrachtete Ausdruck tatsächlich eine Schleifeninvariante ist. Daher darf er für die sich anschließenden Schritte verwendet werden.

10.3 Formaler Korrektheitsbeweis

341

Betrachtung des Schleifenabbruchs

Nun ist der Schleifenabbruch zu betrachten. Falls die Schleife terminiert, so gelangt die Ausführung an das Ende des Algorithmus. Da durch den keine Variablenwerte modifiziert werden, kann die unter 4. angegebene Zusicherung als 8. in Abb. 10.12 übertragen werden. Die Schleife wird nur abgebrochen, wenn der Wert von Rest kleiner als der Wert von Divisor wird. In 8. ist daher die Zusicherung Rest < Divisor zu ergänzen. Man erhält die Nachbedingung.

Partielle Korrektheit garantiert nicht, dass stets ein Ergebnis geliefert wird.

Damit ist der Nachweis der sogenannten partiellen Korrektheit erbracht. Partielle Korrektheit ist gegeben, wenn das Programm, falls es terminiert, ein korrektes Ergebnis liefert. Es ist noch nicht bewiesen, dass das Programm für alle möglichen Eingaben terminiert. Und wenn es nicht terminiert, so liefert es eben auch kein Ergebnis. Eine mögliche Ursache könnte z. B. eine Schleife sein, deren Ausführung für einige Eingabewerte nicht abbricht. Terminationsbeweise werden in einem späteren Abschnitt diskutiert.

Prädikatenlogik

Die Verwendung von Aussagenlogik reicht nicht in jedem Fall aus. Als Beispiel soll die Berechnung der Fibonacci-Zahlen verwendet werden. Mit den Startwerten a1 = 1 und a2 = 1 wird die Folge der Fibonacci-Zahlen erklärt durch an+2 = an+1 + an . Die Fibonacci-Zahlen a1 bis amax sollen mit Hilfe eines Software-Moduls bestimmt werden, dessen Nassi-Shneiderman-Diagramm in Abb. 10.13 angegeben ist. Dem Feld a mit dem Indexbereich 1 bis max, mit max ≥ 2, sollen die Fibonacci-Zahlen a1 bis amax zugewiesen werden. Um diesen Sachverhalt beschreiben zu können, ist es notwendig, Aussagen über eine Menge von Betrachtungseinheiten – hier Feldelemente – formulieren zu können. Man benötigt sogenannte Quantoren. Quantoren sind in der Aussagenlogik nicht verfügbar. Eine um Quantoren erweiterte Aussagenlogik heißt Prädikatenlogik erster Ordnung. Der sogenannte Allquantor bietet die Möglichkeit, Aussagen der Art „Für alle Elemente gilt ...“ zu formulieren. Der Existenzquantor gestattet Formulierungen der Art „Es gibt mindestens ein Element, für das gilt ...“.

Abbildung 10.13 Nassi-Shneiderman-Diagramm der Fibonacci-Berechnung

342

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Es gibt mehrere Notationen für Quantoren. Ein zwischen den Indizes 0 und n aufsteigend sortiertes Feld kann mit dem Allquantor alternativ folgendermaßen beschrieben werden: > > >

BEISPIEL

all j: 0 ≤ j < n: a[ j] ≤ a[ j + 1] ∀ j|0≤ j >

ex j: 0 ≤ j ≤ n: a[ j] > 0 ∃ j|0≤ j≤n

: a[ j] > 0

j|0≤ j≤n

: a[ j] > 0



Die Vorbedingung des Moduls zur Fibonacci-Berechnung entsprechend Abb. 10.13 ist max ≥ 2. Die Definition der Fibonacci-Zahlen führt zu der folgenden Nachbedingung: a[1] = 1 ∧ a[2] = 1 ∧

∀ j|3≤ j≤max a[ j] = a[ j − 1] + a[ j − 2]

Eine Variante des induktiven Zusicherungsverfahrens nutzt mit Annotationsfeldern erweiterte Nassi-Shneiderman-Diagramme als Darstellungsmittel. Die Zusicherungen werden hier nicht mit Pfeilen an einen Programm-Ablauf-Plan, sondern als Annotation in entsprechende Felder eines Nassi-Shneiderman-Diagramms eingetragen. Abb. 10.14 stellt das mit Zusicherungen annotierte Nassi-Shneiderman-Diagramm zur FibonacciBerechnung dar. Die Vorbedingung wird dem Diagramm vorangestellt. Die Nachbedingung wird an der Diagrammunterkante hinzugefügt. Die Schleife bestimmt bei jedem Durchlauf eine weitere Fibonacci-Zahl. Als Schleifeninvariante wird der folgende Ausdruck verwendet: a[1] = 1 ∧ a[2] = 1 ∧

Erweiterte Nassi-Shneiderman-Diagramme können als Basis für den Beweis dienen.

∀ j|3≤ j 0} Wenn nach der Ausführung der Zuweisung y > 0 gelten soll, so muss vor der Ausführung der Zuweisung x > 0 erfüllt gewesen sein. Dies ist die Vorbedingung Px y , die durch einfaches Ersetzen aller Variablen y der Nachbedingung durch Variablen x erzeugt wird. {x > 0} y=x {y > 0}

In allgemeiner Form kann die Semantik der Zuweisung als Axiom durch A0. {Px y } y=x {P} dargestellt werden. Inferenzregeln

346

Weiter gibt Hoare einige Inferenzregeln (Schlussfolgerungsregeln) an. Diese Regeln besitzen die Form „Wenn die Voraussetzungen gelten, dann gilt die Schlussfolgerung“. Hoare notiert diese Regeln in der Form „If A and B then C“. Durchaus üblich ist aber auch die folgende Schreibweise, die im Weiteren verwendet wird:

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

A, B C Die Ableitungsregel wird auch als Konsequenzregel bezeichnet. Sie ermöglicht es, Vorbedingungen zu „verschärfen“ bzw. Nachbedingungen „abzuschwächen“. Dies ist z. B. erforderlich, um aus einer bewiesenen Zusicherung die im Rahmen des Beweises gewünschte Zusicherung abzuleiten. Q ⇒ R, {P}S{Q} A1. {P}S{R}

Abschwächen von Nachbedingungen

Die Regel A1 beschreibt, dass P die Vorbedingung von S bezüglich R ist, falls P Vorbedingung von S bezüglich Q ist und Q die Zusicherung R impliziert. Jede Zusicherung R, die schwächer als eine Nachbedingung Q ist, kann als Nachbedingung verwendet werden. Nachbedingungen können abgeschwächt werden.

Falls S ein Programm ist, dessen Ausgangszusicherung R verlangt, dass der Wert der Variablen x nicht negativ ist, und bewiesen ist, dass das Programm sogar sicherstellt, dass x einen positiven Wert besitzt, so kann die Regel A1 angewendet werden.

BEISPIEL

Zu zeigen ist, dass gilt: {P} S {x ≥ 0}. Bewiesen ist: {P} S {x > 0}. Es gilt: (x > 0) ⇒ (x ≥ 0). Also kann A1 angewendet werden. Man erhält: (x > 0) ⇒ (x ≥ 0), {P}S{x > 0} {P}S{x ≥ 0} Damit ist die Ausgangszusicherung R bewiesen.

Die Regel A2 ist symmetrisch zur Regel A1: A2.

P ⇒ Q, {Q}S{R} {P}S{R}

Verschärfung von Vorbedingungen

Sie lässt jede Zusicherung P als Vorbedingung zu, die stärker ist, als die Vorbedingung Q. Vorbedingungen dürfen „verschärft“ werden.

Falls S ein Programm ist, dessen Eingangszusicherung P garantiert, dass der Wert der Variablen x positiv ist, und bewiesen ist, dass die Ausgangszusicherung R gilt, falls x zu Beginn einen nicht negativen Wert besitzt, so kann die Regel A2 angewendet werden. Zu zeigen ist, dass gilt: {x > 0} S {R}. Bewiesen ist: {x ≥ 0} S {R}. Es gilt: (x > 0) ⇒ (x ≥ 0). Also kann A2 angewendet werden. Man erhält:

BEISPIEL

(x > 0) ⇒ (x ≥ 0), {x ≥ 0}S{R} {x > 0}S{R}

10.3 Formaler Korrektheitsbeweis

347

Um über Programmteile argumentieren zu können, die sich aus mehreren Anweisungen zusammensetzen, benötigt man die Kompositionsregel: Kompositionsregel

A3.

{P}S1 {Q}, {Q}S2 {R} {P}S1 ; S2 {R}

P ist Vorbedingung der Sequenz S1 ; S2 bezüglich R, falls P Vorbedingung von S1 bezüglich Q ist und Q Vorbedingung von S2 bezüglich R ist. Die Kompositionsregel gestattet die Behandlung von Anweisungssequenzen. Falls die Nachbedingung einer Anweisung identisch mit der Vorbedingung der nachfolgenden Anweisung ist, so kann diese „entfallen“. Die Vorbedingung der ersten Anweisung und die Nachbedingung der zweiten Anweisung werden zur Vorbedingung bzw. Nachbedingung der Anweisungssequenz.

Regel für abweisende Schleifen

Schließlich definiert Hoare eine Regel für abweisende Schleifen, also Schleifen der Form „while B do S“. B ist die Schleifenbedingung, die vor Ausführung des Schleifenkörpers S und nach jeder Ausführung des Schleifenkörpers evaluiert wird. Besitzt B den Wert wahr, so wird ein Schleifendurchlauf ausgeführt. Andernfalls wird der Schleifenkörper S nicht ausgeführt und mit der auf den Schleifenkörper folgenden Anweisung fortgefahren. Eine entscheidende Bedeutung bei der Verifikation von Schleifen besitzt die sogenannte Schleifeninvariante (siehe auch 10.3.2.1). Schleifeninvarianten sind Zusicherungen, die vor der Ausführung einer Schleife und nach jedem Schleifendurchlauf gültig sind, deren Wert also invariant wahr ist. Invarianten gestatten eine geschlossene Beschreibung der Funktionalität einer Schleife und sind aus diesem Grund unverzichtbarer Bestandteil der Verifikation von Schleifen. {P ∧ B}S{P} A4. {P}while B do S{P ∧ ¬B} A4 besitzt die folgende Bedeutung: Unter der Prämisse, dass die Ausführung des Schleifenrumpfs S die Gültigkeit der Invarianten P nicht verändert, ist P sowohl Vorbedingung als auch Bestandteil der Nachbedingung der Schleife. Da die Schleifenausführung nur abgebrochen wird, wenn die Schleifenbedingung falsch wird, erhält man als vollständige Nachbedingung (P∧¬B). Außerdem kann die Vorbedingung ein wenig verschärft werden. Da der Schleifenrumpf S nur ausgeführt wird, falls B wahr ist, existiert nur dann die Möglichkeit, dass P verfälscht wird. In der Voraussetzung kann daher als Vorbedingung (P∧B) verwendet werden. Schließlich ist eine Regel für die Behandlung von Auswahlkonstrukten („if B then S1 else S2 “) notwendig.

Regel für Auswahlkonstrukte

A5.

{Q ∧ B}S1 {R}, {Q ∧ ¬B}S2 {R} {Q}i f B then S1 else S2 {R}

Ein Korrektheitsbeweis unter Verwendung des Hoare-Kalküls ist in /Hoare 71/ veröffentlicht. Die Verifikation des bereits zum Floyd’schen Verfahren vorgestellten Moduls zur ganzahligen Division mit dem Hoare-Kalkül ist in Tab. 10.1 dargestellt.

348

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Tabelle 10.1 Beweis mit dem Hoare-Kalkül

Die linke Spalte nummeriert die Beweisschritte. Die rechte Spalte enthält die verwendete Regel und ggf. die Nummern der benutzten Beweisschritte. Die Werte der Eingangsvariablen sollen keinen Einschränkungen unterliegen. Als Eingangszusicherung wird daher die boolesche Konstante true verwendet. Als Ausgangszusicherung dient der Ausdruck Dividend = Rest + Quotient * Divisor ∧ ¬(Divisor ≤ Rest). Das Ziel der Verifikation ist zu beweisen, dass die Nachbedingung, die das Programm aus der Vorbedingung erzeugt, die Ausgangszusicherung impliziert. Einerseits vermittelt der Beweisaufwand für das triviale Beispielprogramm einen ungefähren Eindruck des Aufwands, der für ein kompliziertes Programm zu erwarten ist. Andererseits besteht der Beweis im Wesentlichen aus der einfachen, geradlinigen Anwendung von Regeln auf Ausdrücke – aus simpler, aber aufwändiger Symbolmanipulation. Dies kann relativ leicht automatisiert werden.

Beweise sind in weiten Teilen automatisierbar.

Es ist bemerkenswert, dass der Beweis ohne Einschränkungen der Werte der Eingabevariablen Dividend und Divisor gelingt. Betrachtet man den Quellcode, so erkennt man, dass der Algorithmus z. B. für Divisor = 0 nicht korrekt arbeitet, weil sich eine Endlosschleife einstellt. Der Algorithmus terminiert für diesen Wert von Divisor nicht.

10.3.3

Totale Korrektheit

Die bisher dargestellten Techniken sind geeignet, die partielle Korrektheit eines Programms nachzuweisen. Dieser Beweis der Konsistenz zwischen Spezifikation und Code gilt jedoch nur unter der Voraussetzung, dass das Programm terminiert, also zu einem Ende gelangt. Der Nachweis der Termination wird weder durch das Floyd’sche Verfahren noch

10.3 Formaler Korrektheitsbeweis

349

Termination ist im Allgemeinen ein unentscheidbares Problem

Terminationsfunktion

BEISPIEL

durch den Hoare-Kalkül geleistet. Terminationsbeweise können in allgemeiner Form nicht algorithmisch durchgeführt werden. Es ist nicht möglich, einen Algorithmus anzugeben, der entscheiden kann, ob ein beliebiger anderer Algorithmus stets terminiert. Das ist ein sogenanntes unentscheidbares Problem. Trotz des Fehlens einer in jedem Fall erfolgreichen Vorgehensweise für den Nachweis der Termination kann für viele Programme die Termination gezeigt werden. Man ordnet jedem Schleifendurchlauf eine so genannte Terminationsfunktion zu, deren Wertebereich die Menge der nicht-negativen ganzen Zahlen ist. Kann gezeigt werden, dass die Terminationsfunktion nach jedem Schleifendurchlauf einen geringeren Wert liefert als vorher, so bilden die Werte der Terminationsfunktion während der Programmausführung eine streng monoton fallende Folge. Da im Wertebereich der nichtnegativen ganzen Zahlen keine streng monoton fallenden Folgen mit einer unendlichen Anzahl von Folgengliedern möglich sind, folgt gilt, dass die betrachtete Schleife terminiert.

In dem Divisionsprogramm nach Abb. 10.12 seien alle beteiligten Variablen ganzzahlig. An jeder Stelle des Programms gilt Divisor > 0, also aufgrund der Ganzzahligkeit der Variablen Divisor ≥ 1. Es gilt Dividend ≥ 0 und daher auch Rest ≥ 0. In jedem Schleifendurchlauf wird der Wert von Rest um den Wert von Divisor – also mindestens um 1 – verkleinert. Gleichzeitig gilt Rest ≥ 0. Die Werte von Rest bilden offensichtlich bezogen auf die Schleifendurchläufe eine streng monoton fallende Folge, deren Wertebereich die Menge der nicht negativen ganzen Zahlen ist. Daraus folgt, dass die Schleife stets terminiert. Die Terminationsfunktion ist t = Rest. Die Schleifenregel des Hoare-Kalküls kann entsprechend angepasst werden: A4∗ .

{P ∧ B}S{P}, {P ∧ B ∧ t = z}S{t < z}, P ⇒ t ≥ 0 {P}while B do S{P ∧ ¬B}

Der Wert z muss für den betrachteten Programmausschnitt – die Schleife – eine Konstante sein. Falls vor der Ausführung des Schleifenrumpfs t = z gilt, so muss anschließend t < z gelten, d. h. der Wert der Terminationsfunktion wird geringer. Aus der Gültigkeit der Schleifeninvariante P muss folgen, dass t ≥ 0 gilt. Außerdem muss t in die Menge der ganzen Zahlen abbilden. In dem Beispiel nach Abb. 10.12 gelingt der Beweis mit der folgenden Zuordnung: z = Dividend, t = Rest. Der Beweis mit dem Hoare-Kalkül entsprechend Tab. 10.1 scheitert, wenn das Axiom A4∗ verwendet wird. Es kann hier nicht allgemein bewiesen werden, dass die Terminationsfunktion streng monoton fallend ist. Falls Divisor den Wert Null besitzt, so liefert die Terminationsfunktion t = Rest eine Folge, deren Glieder einen konstanten Wert besitzen. Die Schleife terminiert in diesem Fall nicht. In dem Beweis entsprechend Tab. 10.1 fehlt die Vorbedingung Divisor > 0.

350

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

10.3.4

Algebraische Techniken

Die algebraische Spezifikationstechnik besitzt eine solide formale Basis. Im folgenden wird sie – etwas vereinfacht – informell beschrieben. Unter einer Algebra wird eine Menge von Elementen verstanden, zu der eine Anzahl von Operationen gehören, die auf die Elemente anwendbar sind. Die Kombination aus Mengen und Operationen bezeichnet man auch als Datentyp. Algebraische Spezifikationen sind eine insbesondere für Datenabstraktionen geeignete Spezifikationsform. Datenabstraktionen bestehen aus einem internen Gedächtnis – einer Datenstruktur – und aus Zugriffsoperationen auf dieses Gedächtnis. Die einzige Zugriffsmöglichkeit auf das interne Gedächtnis bilden die zur Datenabstraktion gehörenden Zugriffsoperationen. Ein Zugriff auf das Gedächtnis unter Umgehung der Zugriffsoperationen ist nicht möglich. Aufgrund ihrer Eigenschaften können algebraische Spezifikationen in der objektorientierten Software-Entwicklung zur Spezifikation des Verhaltens von Klassen dienen. Algebraische Spezifikationen beschreiben die Wirkung der Anwendung der Operationen auf die betrachteten Datenobjekte.

q sei eine Variable vom Typ Integer-Warteschlange. i sei eine ganze Zahl, also eine Integer-Variable. Die Operation insert (q, i) fügt i am Warteschlangenende von q an. Als Ergebnis erhält man eine geänderte Warteschlange, die um das am Warteschlangenende eingefügte Element i länger ist. Das Ergebnis der Operation ist daher vom Typ Warteschlange.

Algebraische Spezifikationen eignen sich besonders zur Spezifikation von Datenabstraktionen.

BEISPIEL

Die Operation delete (q) entfernt ein Element vom Kopf der Warteschlange und liefert als Ergebnis eine Warteschlange. Die Operation isNew (q) stellt fest, ob die Warteschlange leer ist. Das Ergebnis ist ein Boolescher Wert. Die Operation length (q) liefert die aktuelle Anzahl der Elemente in der Warteschlange q. Als Ergebnis erhält man eine nicht negative ganze Zahl. Die Beschreibung spezifiziert syntaktische Eigenschaften. Es wird festgelegt, welche Dinge betrachtet werden (Warteschlangen und Integer-Variablen). Ferner werden dafür Variablen vereinbart (q und i). Außerdem werden die „Schnittstellen“ der Operationen festgelegt, indem angegeben wird, welche „Eingaben“ und „Ausgaben“ sie verarbeiten. Dabei bezieht man sich nicht auf konkrete Variablen oder Werte, sondern auf die vereinbarten Sorten. So erwartet z. B. die Operation length als Eingabe eine Warteschlange und liefert als Ausgabe einen Integerwert. Die Semantik wird in Form von Axiomen festgelegt. Die Axiome sind der eigentliche fachliche Teil der Spezifikation. Sie legen das Verhalten fest. Ein Ausschnitt aus der Spezifikation der Warteschlange kann z. B. folgendermaßen notiert werden:

10.3 Formaler Korrektheitsbeweis

351

spec QUEUE sort Queue; ops insert: Queue × Int → Queue; delete: Queue → Queue; isNew: Queue → Bool; length: Queue → Int; vars q: Queue i: Int axioms delete (insert (q, i)) = if isNew (q) then q else insert (delete (q), i); isNew(q) = (length (q) = 0); length (insert (q, i)) = length (q) + 1; length (delete (q)) = if IsNew(q) then error else length (q) - 1; . . .end

Das erste der aufgeführten Axiome besitzt die folgende Bedeutung (Abb. 10.15):

Abbildung 10.15 Ein Axiom der Warteschlangen-Spezifikation

Wenn einer Warteschlange q ein Element i hinzugefügt wird und anschließend ein Element entfernt wird, so sind zwei Fälle zu unterscheiden. Falls die Warteschlange q zuvor leer war – d. h. isNew(q) liefert das Ergebnis wahr – so erhält man anschließend wieder die leere Warteschlange q. Das Element i ist in diesem Fall eingefügt und gleich wieder entnommen worden. Die Reihenfolge der Operationen darf nicht vertauscht werden, weil sonst die Operation delete auf eine leere Warteschlange angewendet würde. Falls die Warteschlange q vorher nicht leer war, so kann die Reihenfolge der Operationen vertauscht werden – d. h. man darf erst ein Element entnehmen und anschließend i einfügen – ohne das sich die Ergebniswarteschlange verändert. In diesem Fall wird ein anderes Element entnommen, als eingefügt wurde, und daher kann die Reihenfolge der Operationen vertauscht werden.

352

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Das zweite Axiom drückt aus, dass die Operation isNew(q) genau dann das Ergebnis wahr liefert, wenn die Warteschlange leer ist (length (q) = 0). Das dritte Axiom beschreibt, dass die Warteschlange durch Anwendung der Operation insert um ein Element länger wird. Es ist nicht ganz einfach sicherzustellen, dass die Menge der Axiome vollständig ist. Algebraische Spezifikationen können umfangreich sein. Natürlich müssen die Axiome „ineinander eingesetzt“ wahre Aussagen liefern. Dies wird im folgenden anhand eines Beispiels verdeutlicht. Die von Umformungen betroffenen Teile sind jeweils in fetter Schrift hervorgehoben: Axiom 1:delete(insert(q, i))=if isNew(q) then q else insert(delete(q),i); Axiom 2:isNew(q) = (length (q) = 0); Axiom 3:length (insert (q, i)) = length (q) + 1; Axiom 4:length (delete (q))=if IsNew(q) then error else length(q) - 1; >

Ersetzen von q durch insert (q,i) in Axiom 4: length (delete (insert (q, i))) = if isNew(insert (q, i)) then error else length (insert (q, i)) - 1

>

Anwenden von Axiom 2: length (delete (insert (q, i))) = if (length (insert (q, i)) = 0) then error else length (insert (q, i)) - 1

>

Anwenden von Axiom 3: length (delete (insert (q, i))) = if ((length (q) +1) = 0) THEN error ELSE length (insert (q, i)) - 1 = length (insert(q,i)) - 1

Die Bedingung ((length (q) + 1) = 0) ist stets falsch. Daher kann der oben angegebene Ausdruck vereinfacht werden zu: >

length (delete (insert (q, i))) = length (insert(q,i)) - 1

>

Anwenden von Axiom 3: length (delete (insert (q, i))) = length (q) + 1 - 1 = length (q)

>

Anwenden von Axiom 1: length (delete (insert (q, i))) = if isNew (q) then length (q) else length (insert (delete (q), i)) = length (q)

>

Anwenden von Axiom 3: if isNew (q) then length (q) else length (delete (q)) + 1 = length (q)

>

Anwenden von Axiom 4: if isNew (q) then length (q) else (if isNew(q) then error else (length (q) - 1) + 1 = length (q)

Die kursiv gesetzte Bedingung isNew(q) ist stets falsch. Darum kann der Ausdruck vereinfacht werden zu: >

if isNew (q) then length (q) else (length (q) - 1) + 1 = length (q) ⇒

>

if isNew (q) then length (q) else length (q) = length (q) ⇒

>

length (q) = length (q) (wahre Aussage)

10.3 Formaler Korrektheitsbeweis

353

Algebraische Spezifikationen können für den Beweis oder den Test verwendet werden.

BEISPIEL

Algebraische Spezifikationen sind formal. Sie können als Basis für formale Beweise dienen. Darüber hinaus ist es möglich, sie im Rahmen eines dynamischen Tests zu nutzen. Die linke und rechte Seite der Axiome geben jeweils bestimmte Aufruffolgen von Operationen und Regeln zur Weiterverarbeitung der Ergebnisse an. Diese können als Testtreiber dienen. Die schließlich erzielten Ergebnisse müssen identisch sein.

Das Axiom length (insert (q, i)) = length (q) + 1 führt zu dem folgenden Test: Zunächst ist die Operation insert und anschließend ist die Operation length aufzurufen. Es ist zu prüfen, ob man das gleiche Ergebnis erhält, wenn der Wert, den man als Ergebnis von length (q) erhält, um Eins erhöht wird.

Das Werkzeug DAISTS (Data-Abstraktion Implementation, Specification, and Testing System) /Gannon et al. 81/ kann die Spezifikation zu Testzwecken in die verwendete Programmiersprache transformieren. Die übersetzten Axiome können anschließend als Testtreiber verwendet werden.

10.3.5 Zustandsautomaten existieren in einer Vielzahl von Formalitätsgraden.

Symbolic Model Checking

354

Automatenbasierte Techniken

Zustandsautomaten sind ein etabliertes Darstellungsmittel für das Verhalten von Systemen. Neben den weniger formalen Zustandsautomaten – z. B. in der Unified Modeling Language – existieren streng formale Zustandsautomaten, die als Basis für formale Nachweise geeignet sind. Vielfach werden Zustandsautomaten nicht als Spezifikationsmittel, sondern als Programmiersprache genutzt. Aus dem Zustandsautomaten wird in diesem Fall der Programmcode automatisch generiert. In diesem Fall ist der Nachweis von Eigenschaften des Zustandsautomaten – wenn eine fehlerfreie Übersetzung gewährleistet ist – identisch mit dem Nachweis dieser Eigenschaften für das generierte Programm. Eine besonders interessante Technik für die formale Überprüfung definierter Eigenschaften eines Zustandsautomaten ist die symbolische Modellprüfung (Symbolic Model Checking) /Robinson-Mallett, Liggesmeyer 06/, /Robinson-Mallett et al. 06b/. Wenn Verhalten durch Zustandsautomaten dargestellt wird, ist es in der Regel erforderlich, Aussagen über die Sequenzen der Zustände – also über Reihenfolgen von Ereignissen – zu formulieren. Die Erfüllung einer Sicherheitsanforderung bedeutet bezogen auf einen Zustandsautomaten, dass keine der möglichen Zustandssequenzen einen unsicheren Zustand enthält. Eine Lebendigkeitsanforderung erfordert, dass auf allen möglichen Zustandssequenzen bestimmte Zustände immer wieder erreicht werden (z. B. der Startzustand). Die nachzuweisenden Eigenschaften werden oft als temporallogische Formeln angegeben. Das Ziel des Symbolic Model Checking ist, nachzuweisen, dass ein Zu-

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

standsautomat die gewünschte Eigenschaft besitzt oder nicht besitzt. Im letztgenannten Fall ist gegebenenfalls die Generierung eines Gegenbeispiels möglich, so dass der Fehler im Automaten leichter behoben werden kann. Die Zustände des Zustandsautomaten werden oft nicht explizit angegeben. Stattdessen werden Zustandsvariablen gemeinsam mit ihren diskreten Wertebereichen vereinbart. Der Zustandsraum ergibt sich aus den möglichen Kombinationen der Werte. Die Zustandsübergänge werden in Form von Transitionsregeln spezifiziert.

Abbildung 10.16 Die Fertigungszelle

Abb. 10.16 zeigt als Beispiel den Ausschnitt einer Fertigungszelle, das an /Lewerentz, Lindner 95/ angelehnt ist. Eine Fertigungszelle verarbeitet Metall-Rohteile, die einer Presse durch einen Roboter zugeführt werden. Der Roboter greift das Rohteil von einem Hubdrehtisch, dem es durch ein Förderband zugeführt wird. Die Aufgabe des Hubdrehtisches ist, durch eine horizontale und vertikale Positionsänderung ein Rohteil so zu platzieren, dass es vom Roboter gegriffen werden kann. Tab. 10.2 listet die Aktuatoren und Sensoren des Hubdrehtisches sowie ihre möglichen Werte auf.

Ein Beispiel aus der Automatisierungstechnik

Tabelle 10.2 Aktuatoren und Sensoren des Hubdrehtisches

10.3 Formaler Korrektheitsbeweis

355

Sicherheitsanforderung

Der Hubdrehtisch transportiert Rohteile von der Ausgangsposition zur Zielposition. Es ist eine Sicherheitsanforderung zu beachten. Der Tisch darf sich nicht in den verbotenen Bereich (Abb. 10.17) bewegen. Das ist sichergestellt, falls Zustände nicht erreichbar sind, für die [(vpos=y0 ∧ (hpos=x1 ∨ hpos=x2)] erfüllt ist.

Abbildung 10.17 Sicherheitsanforderung

Zustandsraum

Abb. 10.18 stellt den Zustandsraum des Hubdrehtisches nach Abb. 10.16 dar. Die durchgezogenen Zustandsübergänge sind Schaltvorgänge der Steuerungssoftware. Die gestrichelten Zustandsübergänge stellen Antworten des Hubdrehtisches dar.

Steuerungslogik

Die Ausgangsposition des Tisches ist hpos=x0, vpos=y0. Alle Bewegungen sind gestoppt (hmov=stop, vmov=stop). Die vertikale Bewegung wird gestartet (vmov=up) sobald sich ein Werkstück auf dem Tisch befindet (part_on_table=yes). Wenn vpos=y1 erreicht wird, so wird auch die horizontale Bewegung gestartet (hmov=plus). Wenn der Tisch die Zielposition (hpos=x2, vpos=y2) erreicht, so kann der Roboter das Werkstück greifen. Sobald das Werkstück den Tisch verlassen hat (part_on_table=no) beginnt die horizontale Bewegung (hmov=minus) bis die Position hpos=x0 erreicht ist. Die Abwärtsbewegung beginnt (vmov=down) und die horizontale Bewegung wird gestoppt (hmov=stop). Wenn der Tisch die Ausgangsposition erreicht, so wird auch die Abwärtsbewegung gestoppt (vmov=stop).

Sicherheitsnachweis

Unsichere Zustände sind in Abb. 10.18 grau dargestellt. Wie man in Abb. 10.18 erkennen kann, ist keiner dieser Zustände erreichbar. Keine der möglichen Zustandssequenzen enthält einen unsicheren Zustand. Wäre ein unsicherer Zustand erreichbar, so könnte nachvollzogen werden, welche Sequenz von Zustandsübergängen in den unsicheren Zustand führt. In diesem Fall wird die Eigenschaft nicht bewiesen und ein Gegenbeispiel erzeugt. Derartige Nachweise können durch Symbolic Model Checking erbracht werden. Für umfangreiche Zustandsautomaten erfor-

356

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

Abbildung 10.18 Zustandsautomat des Hubdrehtisches

dert das leistungsfähige Algorithmen und effiziente Darstellungen des Zustandsraums. In der Praxis hat sich die Verwendung von OBDDs (Ordered Binary Decision Diagrams) als Darstellungsmittel bewährt /Bryant 86/.

10.3.6

Bewertung des formalen Korrektheitsbeweises

Die Nutzung formaler Beweistechniken ist insbesondere in Anwendungsbereichen sinnvoll, in denen Restfehler nicht toleriert werden können. Neben sicherheitskritischen oder hochzuverlässigen Anwendun-

10.3 Formaler Korrektheitsbeweis

Formale Beweise sind leistungsfähig, aber ihre praktische Umsetzung ist häufig schwierig. 357

gen sind Produkte für den Massenmarkt betroffen. So können gravierende unerkannte Fehler in Steuerungskomponenten von Automobilen z. B. Rückrufaktionen verursachen. In der Praxis sind die für formale Beweise erforderlichen formalen Spezifikationen oft nicht verfügbar. Darüber hinaus behindern Eigenschaften moderner Programmiersprachen Korrektheitsnachweise. Daher ist ein Verzicht auf die Nutzung bestimmter Sprachelemente notwendig, um Beweise führen zu können. Programme, die in der relativ alten Programmiersprache PASCAL erstellt sind, können unproblematischer verifiziert werden, als Programme in vielen „modernen“ Programmiersprachen. Die Trends bei den Programmiersprachen begünstigen die Anwendung formaler Techniken nicht. Die Nutzung formaler Techniken muss vorbereitet werden.

Die nachträgliche Entscheidung einen formalen Korrektheitsbeweis mit dem Floyd’schen Verfahren oder dem Hoare-Kalkül zu führen, ist in der Regel nicht umsetzbar. Diese Entscheidung muss früh getroffen werden, weil spezielle Verfahren in der Entwicklung verwendet werden müssen. Um nicht für alle Module einer Software formale Techniken verwenden zu müssen, ist es oft erforderlich, kritische von unkritischen Verarbeitungen zu trennen. Man bezeichnet dies als Entwurf nach Kritikalität. Für die kritischen Module müssen formale Spezifikationen erstellt werden, und bei der Programmierung müssen bestimmte Regeln beachtet werden, um einen formal verifizierbaren Quellcode zu erhalten. Algebraische Techniken werden in der Praxis kaum verwendet. Vielleicht wird sich das im Zuge der zunehmenden Nutzung objektorientierter Techniken ändern, denn algebraische Spezifikationen passen hervorragend zur Struktur objektorientierter Software. Sie eignen sich zur Spezifikation des Verhaltens von Klassen bzw. Objekten. Automatenbasierte Techniken besitzen einen eingeschränkten Anwendungsbereich. Sie sind nur für Software geeignet, deren Verhalten durch einen Zustandsautomaten beschrieben werden kann. Für viele Anwendungen – insbesondere bei der Entwicklung von eingebetteter Software – ist dies möglich. Automatenbasierte Techniken und Symbolic Model Checking werden daher insbesondere in der Automatisierungstechnik eingesetzt, um z. B. Sicherheitseigenschaften nachzuweisen. Symbolic Model Checking ist auf sehr umfangreiche Systeme, die durch entsprechend umfangreiche Zustandsautomaten beschrieben werden, anwendbar. Darüber hinaus sind Zustandsautomaten ein in der Praxis verbreitetes Darstellungsmittel. Automatenbasierte Techniken und Symbolic Model Checking erfüllen für ihren spezifischen Anwendungsbereich weitgehend die Anforderungen der Praxis.

10.4 Pro: Vollständigkeit der Aussagen

358

Bewertung der formalen Techniken

Die formalen Techniken zielen auf die Erzeugung vollständiger Aussagen zur Korrektheit. Sie erheben den Anspruch, den Stichprobencharak-

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

ter der dynamischen Testtechniken zu beseitigen. Dies gelingt jedoch nur unter sehr idealisierten Annahmen. Einerseits kann der symbolische Test bestimmte Datentypen und Datenstrukturen nicht korrekt berücksichtigen. Ferner scheitert er, falls zu viele Pfade vorhanden sind. Andererseits liefert er für die symbolisch getestete Teilmenge der Pfade vollständige Aussagen. Die formalen Korrektheitsbeweise besitzen spezifische Anwendungsbereiche und in den Anwendungsbereichen bestimmte charakteristische Eigenschaften. Einerseits sind induktive Zusicherungsbeweise grundsätzlich in der Lage, die Korrektheit zu beweisen. Andererseits ist nicht allgemein entscheidbar, ob ein Programm für alle möglichen Eingaben überhaupt ein Ergebnis liefert. Der Korrektheitsnachweis zeigt oft nur die partielle Korrektheit. Korrektheitsbeweise können für den vollen Sprachumfang moderner Programmiersprachen nicht geführt werden. Darüber hinaus werden Fließpunktvariablen aufgrund der Rundungsproblematik nicht korrekt behandelt. Algebraische Techniken werden in der Praxis kaum akzeptiert. Automatenbasierte Techniken können auf große Systeme angewendet werden, falls diese Systeme durch Zustandsautomaten geeignet beschrieben werden können. Dies gelingt nicht bei jedem System. Daher besitzen automatenbasierte Techniken einen eingeschränkten Anwendungsbereich.

Contra: praktische Umsetzbarkeit

Für die korrekte Funktion ist insbesondere bei eingebetteter Software neben der Erzeugung des gewünschten Ein-/Ausgabe-Verhaltens die Einhaltung von Zeitbedingungen erforderlich. Wird eine korrekte Ausgabe zu spät erzeugt, so können die Auswirkungen ähnlich gravierend sein, wie die einer rechtzeitigen, aber falschen Ausgabe. Die Einhaltung von Zeitbedingungen kann weder durch einen symbolischen Test noch durch formale Verifikation gezeigt werden.

Formale Techniken liefern keine Aussagen zum Laufzeitverhalten.

Es existiert keine einzelne Technik, die in der Lage ist, die Korrektheit – bei der Zugrundelegung eines umfassenden Korrektheitsbegriffs – vollständig zu zeigen. Selbst ein formaler Korrektheitsbeweis auf Basis einer formalen Spezifikation leistet dies nicht. Kennzeichnend für die heute verfügbaren Techniken ist, dass sie Aussagen für einen bestimmten, betrachteten Ausschnitt der Eigenschaft Korrektheit erzeugen. Gelingt z. B. der Nachweis der partiellen Korrektheit eines Programms durch einen formalen Beweis, so hat man die folgende Aussage zur Korrektheit erzeugt: Für alle Daten, für die das Programm ein Ergebnis erzeugt, entspricht dieses Ergebnis der Forderung der Spezifikation. Es ist weder nachgewiesen, dass das Programm für alle Eingaben ein Ergebnis liefert, noch ist eine Information dazu erzeugt worden, in welcher Zeitspanne Ergebnisse erzeugt werden. Für die praktische Anwendung einer Software ist das Zeitverhalten aber oft von Bedeutung. Die Qualität der durch den Einsatz formaler Techniken erzeugbaren Aussagen über die Eigenschaft Korrektheit eines Programms ist unterschied-

10.4 Bewertung der formalen Techniken

359

lich. In allen praktischen Fällen ist sie bei Zugrundelegung eines umfassenden Korrektheitsbegriffs niemals vollständig. Formale Techniken können insbesondere in sicherheitskritischen Anwendungsbereichen den dynamischen Test ergänzen. Ersetzen können sie ihn nicht.

CHECKLISTE

360

>

Symbolischer Test kann ein geeignetes Mittel sein, um in schlecht strukturierter Alt-Software Code aufzuspüren, der nicht ausführbar ist. Durch Entfernen derartigen Codes wird solche Software kürzer, schneller und übersichtlicher.

>

Symbolischer Test kann zur Unterstützung dynamischer, strukturorientierter Testtechniken dienen. Er kann z. B. bei einem Zweigüberdeckungstest für einen bislang ungetesteten Zweig Testdaten generieren oder nachweisen, dass keine Testdaten existieren.

>

Wenn Sie sicherheitskritische Software entwickeln, so sollten Sie über die Nutzung formaler Techniken für die besonders kritischen Bestandteile Ihrer Software nachdenken.

>

Falls Sie bereits automatenbasierte Techniken verwenden, so können Sie gegebenenfalls Symbolic Model Checking leicht einführen.

>

Versuchen Sie nicht, dynamisches Testen durch formale Techniken zu ersetzen. Wenn Sie formale Techniken nutzen, so können Sie sicherlich die Anzahl der dynamischen Testfälle deutlich reduzieren. Sie werden aber auf den dynamischen Test nicht verzichten können.

10 Formale Techniken: Symbolischer Test und formaler Korrektheitsbeweis

11 Prozesse und Prüfstrategien In diesem Buch werden in erster Linie Methoden, Techniken und Werkzeuge beschrieben. Diese technischen Lösungen erfordern zu ihrer sinnvollen Nutzung einen Rahmen, in den sie eingebettet sind. In diesem Kapitel werden wichtige Aspekte dieser „Infrastruktur“ für die Erzeugung qualitätsgerechter Software diskutiert. Neben dem Prozessmodell, das den Ablauf der Entwicklung regelt, sind Verantwortlichkeiten und Ressourcenzuordnungen festzulegen. Darüber hinaus ist die Definition der zu erstellenden Dokumente erforderlich. Für diese Aspekte und für die technischen Inhalte können einschlägige Normen und Standards Vorgaben enthalten.

Übersicht 11.1

Eigenschaften und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

11.2

Software-Entwicklungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

11.3

Die Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

11.4

Die Prüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

11.5

Organisatorische Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

11.6

Dokumentation und Auswertung der Prüfung . . . . . . . . . . . . . . 381

11.7

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

11.8

Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

361

11.1

Eigenschaften und Ziele

Die folgenden Eigenschaften charakterisieren zur Zeit viele professionelle Software-Entwicklungen:

Situation

>

Die Software-Umfänge nehmen ständig zu.

>

Die für die Entwicklung zur Verfügung stehende Zeitspanne wird nicht länger.

>

Die Software muss in Varianten (z. B. Ländervarianten) entwickelt werden.

>

Die Software-Entwicklung geht arbeitsteilig vonstatten. Oft sind mehrere hundert Entwickler beteiligt.

>

Viele Unternehmen haben Schwierigkeiten, kompetente SoftwareEntwickler auf dem Arbeitsmarkt zu akquirieren.

>

Meistens wird eine hohe Verfügbarkeit der Software gefordert, die bereits oft quantitativ vertraglich festgeschrieben ist und bei deren Nichterreichung Konventionalstrafen zu zahlen sind.

>

Bei der Entwicklung softwareintensiver technischer Systeme existieren häufig Sicherheitsanforderungen, deren Einhaltung in einigen Anwendungsbereichen gegenüber Zulassungsstellen nachgewiesen werden muss.

Zusammenfassend kann die Situation folgendermaßen beschrieben werden: Umfangreiche Software muss in nachvollziehbarer Weise eindeutig mit allen relevanten Eigenschaften dargestellt werden, die konsistent durch die Entwicklung in Programmcode umgesetzt werden müssen, um anschließend in geeigneter Form nachgewiesen zu werden. Dies erfordert entsprechende Entwicklungsprozesse als organisatorischen Rahmen für geeignete Entwicklungs- und Qualitätssicherungstechniken. Neben technischen Aspekten sind wirtschaftliche Kriterien zu beachten. Darüber hinaus ist insbesondere in kritischen Anwendungsbereichen eine geeignete Dokumentation der Prüfung erforderlich, die den Nachweis der ordnungsgemäßen Durchführung unterstützt. Oft besteht keine Wahlfreiheit, weil Standards die Nutzung bestimmter Prozesse, Tätigkeiten, Methoden oder Techniken vorschreiben.

11.2

Software-Entwicklungsprozesse

Entwicklungsprozesse regeln die gesamten Arbeitsabläufe in der Software-Entwicklung. In einigen Anwendungsgebieten ist die Einhaltung

362

11 Prozesse und Prüfstrategien

bestimmter Entwicklungsprozesse verbindlich. So ist z. B. die Entwicklung entsprechend des Vorgehensmodells der Bundesverwaltung (V-Modell XT) /Rausch, Broy 08/ außer für den Bereich der Bundesverwaltung auch für militärische Entwicklungen verbindlich. Der klassische Entwicklungsprozess folgt dem so genannten Wasserfallmodell . Dieses Modell sieht vor, dass der Entwicklungsprozess in Phasen aufgeteilt wird, und dass jede Phase abgeschlossen wird, bevor die nachfolgende Phase begonnen wird. Häufig wird es als nachteilig empfunden, dass Modifikationen an dem zu entwickelnden Software-Produkt nur schwierig möglich sind. Die Anforderungen müssen zu einem frühen Zeitpunkt erfasst werden und können, nachdem sie festgeschrieben sind, kaum an geänderte Wünsche angepasst werden. Entwicklungsprozesse, die einem Phasenmodell folgen, besitzen für die Software-Qualitätssicherung den Vorteil, dass eine feste Prüfreferenz existiert, gegen die die Prüfung stattfinden kann. Darüber hinaus entstehen zu einem frühen Zeitpunkt Anforderungsdokumente – z. B. Lastenhefte –, die als Vertragsgrundlage dienen können. Aufgrund der expliziten Phasen erhält man eine entsprechende Abgrenzung der Tätigkeiten, die sich als Basis für eine arbeitsteilige Entwicklung anbietet. Die Software-Entwicklung wird in klar abgegrenzte Phasen unterteilt, die weiter in untergeordnete Arbeitspakete aufgeteilt werden. Diese nachvollziehbare Struktur begünstigt ein geeignetes Projektmanagement. Ein Projektplan ist leicht zu erstellen. Aufgrund der deutlich unterscheidbaren Arbeitspakete und Phasen ist die Projektverfolgung unkompliziert. Viele sehr umfangreiche SoftwareProdukte werden mit Entwicklungsprozessen erzeugt, denen ein Phasenmodell zugrunde liegt.

Wasserfallmodell

In einigen Fällen ist eine abschließende Festlegung der Anforderungen in einer frühen Phase nicht zu leisten. Hier kann die Nutzung von prototyporientierten Entwicklungsprozessen ein Ausweg sein. Man unterscheidet „Wegwerfprototypen“ und „evolutionäre Prototypen“. Im Grunde dienen Prototypen der Beseitigung von Unklarheiten z. B. im Hinblick auf Anforderungen oder die technische Machbarkeit. „Wegwerfprototypen“ werden mit speziellen Entwicklungsmethoden erstellt, die eine schnelle Realisierung gewährleisten, aber sich in der Regel für die Entwicklung des realen Zielsystems nicht eignen. Nachdem das Ziel des „rapid prototypings“ erreicht ist, wird ein derartiger Prototyp „weggeworfen“ und die Entwicklung beginnt erneut. Evolutionäre Prototypen werden nicht verworfen, sondern zum vollständigen Produkt ausgebaut. In diesem Zusammenhang findet man auch den Begriff des Pilotsystems, das bereits den Kern des gewünschten Produkts bildet. Falls die Kernfunktionalität festgelegt ist, so kann diese zur Entwicklung eines Produkts dienen, das ausgeliefert wird. Die Erfahrungen aus der Nutzung dieses Kernsystems unterstützen die Definition der Anforderungen für die folgende Ausbaustufe. Man erhält einen evolutionären Entwicklungsprozess. Innerhalb jeder Versionsentwicklung kann z. B. nach einem konventionellen Phasenmodell entwickelt werden. Viele langlebige Software-Produkte ent-

Prototyporientierte Entwicklung

11.2 Software-Entwicklungsprozesse

Evolutionäre Entwicklung

363

Inkrementelle Entwicklung

Extreme Programming

Die Existenz von Phasen ist vorteilhaft für die Qualitätssicherung.

stammen einem evolutionären Entwicklungsprozess, da ausgehend von einem Kernsystem ständig weitere Funktionen ergänzt werden. Im Gegensatz zum evolutionären Modell versucht man beim inkrementellen Modell, die Anforderungen möglichst vollständig zu ermitteln. Anschließend wird aber nur ein Kernsystem entwickelt und ausgeliefert. Die fehlenden Anforderungen werden in den folgenden Versionen realisiert. Das inkrementelle Modell ist ein evolutionäres Modell, bei dem bereits zu Beginn alle Anforderungen bekannt sind. Das inkrementelle Modell besitzt insbesondere den Vorteil, dass in kurzer Zeit ein Produkt verfügbar ist, das die wichtigsten Funktionen bietet. Für kleine Projekte mit instabilen Anforderungen und starker Kundeneinbindung wird als alternatives Prozessmodell das so genannte „Extreme Programming“ diskutiert. Dieser Ansatz sieht eine Entwicklung in schnellen Iterationen vor, die den Zweck haben, durch Validierung mit dem Kunden ein erwartungskonformes Software-Produkt zu garantieren. Eine hinreichende Qualität soll durch die konsequente Durchführung von qualitätssichernden Aktivitäten gewährleistet werden. Ein sinnvoller Einsatz von Extreme Programming ist an die Erfüllung der Voraussetzungen gebunden. Das Projekt muss hinreichend klein sein, und der Kunde muss bereit sein, aktiv mitzuarbeiten. Aufgrund der im Wesentlichen unklaren Prüfreferenz ist zu erwarten, dass dieses Prozessmodell insbesondere für die Entwicklung kritischer Software nicht optimal geeignet ist. Eine ausführliche Darstellung von Prozessmodellen ist in /Balzert 98/ enthalten. Fast alle Prozessmodelle nutzen Entwicklungsphasen. Im Grunde handelt es sich um abgewandelte Phasenmodelle, bei denen z. B. zusätzlich Prototypen entwickelt werden, zunächst nur ein Teil der Anforderungen umgesetzt wird oder mehrere Phasenmodelle nebenläufig genutzt werden. Für die Qualitätssicherung ist die Existenz definierten Phasen vorteilhaft. Dies ermöglicht die Verzahnung von Konstruktions- und Prüfschritten und die Identifikation geeigneter Prüfreferenzen. Diese Prüfreferenzen sind die Ergebnisse der Analyse-, Entwurfs- und Implementierungsphase. Daher werden die Inhalte dieser Phasen im Folgenden kurz betrachtet. Abb. 11.1 ordnet einige der genannten Prozessmodelle nach ihrer Eignung bezüglich des Projektumfangs, der Stabilität und Bekanntheit der Anforderungen sowie der Kundeninvolvierung ein.

11.3

Informale Techniken

364

Die Entwicklung

Abb. 11.2 ordnet Software-Entwicklungsmethoden nach vier Eigenschaften ein. Drei dieser Eigenschaften – die Einfachheit, die Einsetzbarkeit und die Eindeutigkeit der Beschreibung – sind stark miteinander korreliert. Als vierte Eigenschaft wird der Umfang der Software betrachtet, auf die eine Technik sinnvoll angewendet werden kann. Informale Ansätze – z. B. umgangssprachlicher Text – sind noch sehr verbreitet. Sie sind

11 Prozesse und Prüfstrategien

umfangreich

Extreme Programming

Abbildung 11.1 Einordnung von Prozessmodellen umfangreich

automatenbasiert

prädikatenlogisch algebraisch

Abbildung 11.2 Einordnung von Konstruktionstechniken

einfach und universell einsetzbar, gestatten aber keine unmissverständliche Darstellung. Aufgrund fehlender automatischer Überprüfungsmöglichkeiten, schlechter Visualisierung der Darstellung und unzureichender Abstraktions- und Strukturierungsmechanismen, die besonders für umfangreiche Software erforderlich sind, eignen sie sich nur für unkritische Software mit kleinem Umfang. Ein ständig zunehmender Teil der industriellen Software-Produzenten interessiert sich seit Beginn der 80er-Jahre für so genannte formatierte Techniken. Kennzeichnend für formatierte Techniken ist, dass ihrer Notation eine feste Syntax zugrunde liegt, zur Interpretation der Inhalte aber Anwendungs-wissen erforderlich ist. Zu den formatierten Techniken gehören insbesondere die funktional dekomponierenden Techniken, z. B. Strukturierte Analyse (SA) und Strukturierter Entwurf (SD) sowie die objektorientierten Analyse- und Entwurfstechniken. Formatierte Techniken bestehen stets aus mehreren Basistechniken, die eine Beschreibung aus unterschiedlichen Sichten ermöglichen. Auffallend an formatierten

11.3 Die Entwicklung

Formatierte Techniken

365

Techniken ist die explizite Bereitstellung von Abstraktions-, Hierarchisierungs- und Modularisierungsmechanismen. Durch die formale Syntax der Struktur sind automatische Konsistenzprüfungen möglich. All dies sind Eigenschaften, die explizit auf die Beherrschung umfangreicher Software ausgerichtet sind. Einerseits sind diese Techniken komplizierter als die informalen Techniken, und die Anwendbarkeit ist etwas eingeschränkter. Andererseits erzielt man einen Präzisionsgewinn. Bei den formatierten Techniken werden funktional dekomponierende Techniken seit einigen Jahren durch objektorientierte Techniken ergänzt. Der Standard ist zur Zeit die so genannte Unified Modeling Language (UML) /Rumbaugh et al. 04/, /Rupp et al. 07/. Formale Techniken

Bereits seit den 60er-Jahren sind formale Techniken verfügbar. Ihre Beschreibungsmächtigkeit ist begrenzt durch die Notwendigkeit, die Sprache für die formale Semantikdefinition klein zu halten. Die erstellten Beschreibungen sind eindeutig. Aufgrund unbefriedigender Eigenschaften im Hinblick auf Abstraktion, Strukturierung und Visualisierung ist der typische Anwendungsbereich die Entwicklung kleiner, kritischer Software. Eine Ausnahme im Hinblick auf die behandelbaren Software-Umfänge bilden bei den formalen Techniken die automatenbasierten Ansätze. Sie sind aufgrund effizienter Darstellungsmöglichkeiten auf extrem große Software-Systeme anwendbar. Formale Techniken werden in der Praxis nur selten genutzt. Dagegen ist die Verwendung formatierter Techniken Stand der Praxis. Diese Techniken werden daher im Folgenden näher dargestellt. Im Bereich der Software-Entwicklung sind ausgehend von einfachen, strukturierten Methoden (z. B. SADT) zunächst systematische Techniken entstanden, die man im Allgemeinen als formatierte oder auch semiformale Techniken bezeichnet. Die erste dieser Techniken, die eine nennenswerte Verbreitung in der Praxis gefunden hat, war Ende der 70er-Jahre Structured Analysis (SA) /DeMarco 85/. Diese Technik wurde von den ersten CASE-Werkzeugen unterstützt. Strukturierte Analyse ist eine Technik zur Beschreibung der Funktionsanforderungen an Software-Systeme. Die Technik basiert auf der Methode der so genannten funktionalen Dekomposition. Man identifiziert Funktionen, die solange in Teilfunktionen zerlegt werden, bis die elementaren Funktionen einen hinreichend kleinen, geeigneten Umfang besitzen. Ein Beispiel für eine funktional dekomponierende Entwurfstechnik ist Structured Design (SD) /Yourdon, Constantine 79/. Structured Analysis setzt sich aus mehreren so genannten Basistechniken zusammen, z. B. aus Datenflussdiagrammen, Syntaxbeschreibungen in der Backus-Naur-Form und Entity-Relationship-Modellen sowie Beschreibungen in Prosa. Die Struktur von SA-Diagrammen ist klar definiert. Dies erlaubt es, syntaktische Prüfungen automatisch durchzuführen, so dass insbesondere in großen SA-Modellen Konsistenzprüfungen möglich sind. Strukturierte Analyse bietet Abstraktions-, Hierarchisierungs- und Modularisierungsprinzipien und unterstützt so die Entwicklung sehr umfangreicher Software-Systeme. Die Semantik von SA-

366

11 Prozesse und Prüfstrategien

Modellen ist nicht formal festgelegt und kann aufgrund der Einbeziehung von Prosa-Beschreibungen nicht formal festgelegt werden. Zur Interpretation der Bedeutung von SA-Modellen benötigt man Sachverstand aus dem modellierten Anwendungsbereich. Diese Kombination aus präzis definierter Syntax und informeller Semantik ist charakteristisch für formatierte Techniken. Structured Analysis wurde später für die Anwendung in technischen Bereichen erweitert. Von mehreren Autoren wurden unterschiedliche Varianten der Technik Structured Analysis/Real Time Analysis (SA/RT) vorgeschlagen (siehe z. B. /Hatley, Pirbhai 87/). Die funktional dekomponierenden Ansätze werden heute weitgehend als klassische Software-Entwicklungsmethoden bezeichnet. Dies gilt insbesondere für Strukturierte Analyse (SA) mit den entsprechenden Erweiterungen, z. B. SA/RT. Diese Techniken passen zu den prozeduralen Programmiersprachen, z. B. Pascal, ADA, C. Die Methoden und die einschlägigen Programmiersprachen besitzen insbesondere in technischen Anwendungsbereichen, in denen oft sicherheitskritische Software zu entwickeln ist, eine hohe Verbreitung. Es ist davon auszugehen, dass die Mehrzahl der heute in Betrieb befindlichen Systeme mit klassischen Methoden entwickelt wurden. Obwohl objektorientierte Programmiersprachen bereits seit langem bekannt sind, entstanden die dazu passenden objektorientierten Analyse- und Entwurfstechniken erst erheblich später. In der so genannten Software-Primärbranche verdrängen objektorientierte Entwicklungsmethoden die funktional dekomponierenden Techniken in hohem Maße. Das Gleiche gilt für objektorientierte Programmiersprachen. Es ist eine deutliche Tendenz weg von den klassischen prozeduralen Programmiersprachen hin zu objektorientierten Programmiersprachen zu beobachten. Am deutlichsten ist dies vermutlich beim Wechsel von C nach C++ und Java zu erkennen. Das zunehmende Interesse der Industrie an objektorientierten Entwicklungsmethoden existiert etwa seit Mitte der 90er-Jahre. Auch die objektorientierten Ansätze gehören zu den formatierten Techniken. Die Syntax der Strukturen ist klar definiert, während die Bedeutung der Diagramme nicht vollständig definiert ist. Auch objektorientierte Techniken bieten explizite Abstraktions-, Hierarchisierungsund Modularisierungsprinzipien. Darüber hinaus unterstützen sie in hervorragender Weise das so genannte Lokalitäts- und das Geheimnisprinzip durch die Bildung von Klassen, in denen Daten lokal gekapselt werden können. Die Einhaltung dieses Prinzips sorgt für eine hohe Portabilität von Software-Systemen und begünstigt gleichzeitig deren Änderbarkeit. Objektorientierte Techniken existieren sowohl für die Analyse- als auch für die Entwurfs- und die Implementierungsphase. Im Bereich der Analyse- und Entwurfstechniken hat sich die Unified Modeling Language (UML) als Industriestandard herausgebildet. Bei den Programmiersprachen haben in der Industrie C++ und Java eine hohe Verbreitung.

Funktionale Dekomposition vs. Objektorientierung

Die Nutzung einer klar definierten Entwicklungsmethodik ist wichtig für die Software-Prüfung. Für die Prüfaktivitäten müssen Referenzen zur Verfügung stehen. Oft ist gefordert, dass diese Prüfreferenzen bestimmte

11.3 Die Entwicklung

367

Eigenschaften besitzen. Daher ist es sinnvoll, insbesondere in die Qualitätssicherung der Entwicklungsdokumente jene Personen einzubinden, die diese Dokumente zu einem späteren Zeitpunkt als Prüfreferenzen nutzen.

11.3.1 Funktional dekomponierende Analyse

Die klassischen funktional dekomponierenden Techniken besitzen eine relativ einfache Notation zur Beschreibung der Funktionalität. Die Notation der strukturierten Analyse (SA) umfasst im Wesentlichen Datenflussdiagramme, ein so genanntes Data Dictionary in Backus-Naur-Form und Entity-Relationship-Modelle. In SA/RT treten Zustandsautomaten und Entscheidungstabellen hinzu. Diese relativ kleine und damit überschaubare Notation besitzt insbesondere den Vorteil, dass es für bestimmte zu beschreibende Eigenschaften eine eindeutige Beschreibungsmöglichkeit gibt. Nachteilig ist, dass für einige Eigenschaften keine Notationsmöglichkeit vorhanden ist. Es fehlen entsprechende Beschreibungselemente. Das gilt insbesondere für das Zeitverhalten und für Sicherheits-, Zuverlässigkeits- und Verfügbarkeitseigenschaften. Ebenfalls nachteilig ist die relativ schlechte Abgeschlossenheit der entstehenden Beschreibung aufgrund der funktional dekomponierenden Vorgehensweise. Ein echtes Geheimnisprinzip im Sinne des Verbergens der Interna eines Moduls gegenüber der Umgebung existiert nicht.

Objektorientierte Analyse

Objektorientierte Analysemethoden besitzen eine im Vergleich zu SA sehr umfangreiche Notation. Dies gilt insbesondere für die verbreitete Methode UML. Die umfangreiche Notation führt dazu, dass bestimmte Eigenschaften auf unterschiedliche Weise beschrieben werden können. Die Notation bietet Wahlmöglichkeiten. Die Art der Modellierung ist zum Teil von persönlichen Vorlieben abhängig. Dies ist im Hinblick auf eine eindeutige Systembeschreibung nachteilig. Eine positive Eigenschaft der objektorientierten Analysemethoden ist die hervorragende Unterstützung des Geheimnisprinzips. Darüber hinaus wird erwartet, dass die guten Modularisierungs- und Hierarchisierungseigenschaften objektorientierter Techniken mehrere Qualitätseigenschaften positiv beeinflussen (z. B. die Wartbarkeit). Außerdem ist es offensichtlich einfacher möglich, geeignete objektorientierte Analyseklassen zu identifizieren, als entsprechend geeignete Analysefunktionen in einer funktional dekomponierenden Methode. Bestimmte Qualitätseigenschaften – z. B. Sicherheit, Zuverlässigkeit, Verfügbarkeit – können auch mit objektorientierten Methoden nur eingeschränkt beschrieben werden. Erweiterungen – z. B. Real-Time UML – bieten hier gewisse, aber begrenzte Möglichkeiten. Objektorientierte Analysetechniken besitzen im Vergleich zu funktional dekomponierenden Analysetechniken die folgenden Vorteile: >

368

Die Analyse

Bessere Realisierung des Geheimnisprinzips

11 Prozesse und Prüfstrategien

>

Bessere Modularisierungs- und Hierarchisierungsprinzipien

>

Einfachere Partitionierung von Systemen in Klassen

Zwischen den funktional dekomponierenden und den objektorientierten Methoden existieren wenige Unterschiede im Hinblick auf die Fähigkeit zur Beschreibung nicht-funktionaler Qualitätseigenschaften wie Sicherheit, Zuverlässigkeit, Verfügbarkeit und Echtzeitfähigkeit. In diesem Bereich wird es erforderlich sein, auch in der objektorientierten Modellierung Erweiterungen vorzunehmen. Nachteilig ist die umfangreiche Notation insbesondere der objektorientierten Methode UML. Es ist zu erwarten, dass Beschränkungen der Notation im Hinblick auf die Anwendbarkeit dieser Technik in kritischen Anwendungsbereichen durchgeführt werden müssen. Die Analysedokumente bilden die Basis für die Prüfung des fertig integrierten Software-Systems. In der Praxis spricht man vom Systemtest.

11.3.2

Die Analysedokumente bilden die Basis für den Systemtest.

Der Entwurf

In der klassischen Software-Entwicklung sind zwei unterschiedliche Entwurfsprinzipien verbreitet: Der strukturierte Entwurf (Structured Design, SD) und der Entwurf nach Datenabstraktion. Der strukturierte Entwurf ist in allen gängigen klassischen Programmiersprachen einwandfrei umsetzbar. Leider unterstützen derartige Architekturen das Geheimnisprinzip nur sehr eingeschränkt. Modularisierungs- und Hierarchisierungsprinzipien werden dagegen unterstützt. Der Entwurf nach Datenabstraktion begünstigt das Geheimnisprinzip. Datenabstraktionen sind jedoch nur in einigen wenigen klassischen Programmiersprachen realisierbar. Ein Beispiel ist die Programmiersprache ADA. Ein Nachteil der funktional dekomponierenden Methoden ist der Bruch beim Übergang von der Analyse zum Entwurf. Eine für die Analyse geeignete Aufteilung der Funktionen muss nicht zwangläufig eine softwaretechnisch gute Architektur ergeben.

Funktional dekomponierender Entwurf

Objektorientierte Entwurfstechniken bieten eine hervorragende Unterstützung des Modularisierungs-, Hierarchisierungs- und Geheimnisprinzips. Alle objektorientierten Techniken enthalten jedoch Möglichkeiten, diese Prinzipien zu durchbrechen. Es ist darauf zu achten, dass dies nicht geschieht. Mit objektorientierten Techniken können leicht so genannte Entwurfsmuster realisiert werden. Diese Entwurfsmuster besitzen präzis definierte Eigenschaften. Sie können zur zielgerichteten Definition von Architekturen dienen. Diese Architekturen können so konstruiert werden, dass sie bestimmte gewünschte Eigenschaften besitzen. Objektorientierte Entwurfstechniken besitzen einige deutliche Vorteile im Vergleich zu den funktional dekomponierenden Entwurfstechniken. Darüber hinaus bleibt der methodische Bruch zwischen Analyse und Entwurf aus. Die Entwurfsdokumente bilden die Basis für die Prüfung der Interakti-

Objektorientierter Entwurf

11.3 Die Entwicklung

Entwurfsdokumente bilden die Basis für den Modultest und den Integrationstest.

369

on zwischen Modulen. Diese Prüfung wird im Integrationstest durchgeführt. Die während des Entwurfs erstellten Modulspezifikationen sind die Prüfreferenz für den Modultest.

11.3.3

Der Programmcode bildet die Basis für den strukturorientierten Test.

Zur Anwendung klassischer Programmiersprachen wie C, Pascal oder ADA existieren umfangreiche Erfahrungen. Für objektorientierte Programmiersprachen wie C++ und Java gilt dies noch nicht im gleichen Maße. Während Programmiersprachen wie Pascal und ADA softwaretechnisch als besonders gute Sprachen eingestuft werden, gilt dies für die Programmiersprache C nicht uneingeschränkt. Das hat die weite Verbreitung von C jedoch nicht deutlich behindert. C++ und Java besitzen im Vergleich zu C einige Vorteile. Dennoch sind nicht alle Probleme beseitigt. Man wird für objektorientierte Programmiersprachen, in ähnlicher Weise wie für die Sprache C, Programmierkonventionen definieren müssen. Besonders wichtig ist die Beachtung von Programmierkonventionen für die Entwicklung von sicherheitskritischer Software. Grundsätzliche Schwierigkeiten mit der objektorientierten Programmierung sind im Hinblick auf einige Qualitätseigenschaften zu erwarten. Die Garantie von Echtzeiteigenschaften wird durch das in der Objektorientierung verbreitete dynamische Binden sowie durch die dynamische Erzeugung und Zerstörung von Objekten einhergehende so genannte Garbage-Collection erschwert. Der am Ende der Implementierung existierende Programmcode bildet die Basis für den strukturorientierten Test.

11.4 Eine sinnvolle Prüfung findet in Phasen statt.

Die Implementierung

Die Prüfung

Die Prüfung von Software-Systemen findet heute allgemein akzeptiert in Phasen statt. Das Ziel des Modultests ist die Überprüfung einzelner Komponenten (Module) gegen ihre Spezifikation. Die Modulspezifikation ist typischerweise Ergebnis des Feinentwurfs. Im Modultest sind alle Feinheiten eines zu prüfenden Moduls relevant. Seine Einbettung in den Kontext des Software-Systems spielt jedoch noch keine Rolle. Das Ziel des Integrationstests ist die Überprüfung des Interagierens verschiedener Module über Schnittstellen. In dieser Phase sind der innere Aufbau von Modulen und die von der derzeit betrachteten Schnittstelle weit entfernten Schnittstellen nicht relevant. Insbesondere der Integrationstest wird in der Praxis häufig in mehrere untergeordnete Phasen aufgeteilt. Oft findet man einen Subsystemintegrationstest und einen Systemintegrationstest. Ferner findet sich oft ein so genannter HardwareSoftware-Integrationstest. Es ist allgemein akzeptiert, dass Integrationstests inkrementell schritthaltend zur Integration des Systems durchgeführt werden. Ein so genannter nicht inkrementeller Integrationstest, bei

370

11 Prozesse und Prüfstrategien

dem die Module in einem Schritt zum Gesamtsystem zusammengefügt werden, hat sich als nicht geeignet erwiesen. Die Ziele des Systemtests sind die Prüfung der Funktion, Leistung und Qualität des fertig integrierten Systems gegen die Anforderungsdokumente. Im Systemtest werden die inneren Strukturen von Systemen nicht betrachtet. Die Vorgehensweise in Phasen gestattet eine sinnvolle Prüfung auch großer Systeme, da die Komplexität aufgrund der verwendeten Abstraktionsniveaus jeweils beherrschbar bleibt. Entscheidend ist, dass für die jeweilige Prüfphase die erforderlichen Spezifikationen identifiziert werden können. Diese sind Ergebnisse der frühen Entwicklungsphasen. Daher ist es erforderlich, bei einer Optimierung der Prüfung die frühen Phasen der Entwicklung mitzubetrachten.

11.4.1

Die Modulprüfung

In der Praxis wird für die Modulprüfung oft der Begriff Modultest verwendet. Natürlich kann die Modulprüfung auch mit statischen Analysetechniken oder formalen Beweisverfahren durchgeführt werden. Die Bezeichnung Modultest ist aus diesem Grund irreführend. Das Ziel des Modultests ist die Überprüfung eines einzelnen Moduls. Unter einem Modul versteht man im Allgemeinen die kleinste sinnvoll unabhängig testbare Einheit eines Programms. In der funktional dekomponierenden Software-Entwicklung werden die Funktionen bzw. Prozeduren typischerweise als Module verstanden. In der objektorientierten Software-Entwicklung bilden in der Regel die Objekte bzw. Klassen die Module. Ein zu prüfendes Modul wird für die Modulprüfung aus seinem Kontext herausgelöst. Da im Allgemeinen aufrufende Module und aufgerufene Module fehlen, ist ein einzelnes Modul nicht ablauffähig. Die fehlenden überlagerten und unterlagerten Module müssen durch künstliche Module für den Test ersetzt werden. Ersetzende aufrufende Module heißen Treiber (Driver). Stellvertreter für fehlende unterlagerte Dienste bezeichnet man als Dummies. Weil das zu testende Modul an seinen Schnittstellen in die künstliche Testumgebung eingebettet wird, bezeichnet man Treiber und Dummies zusammen auch als Testbett oder Testrahmen. Die Erstellung dieses Testrahmens kann aufwendig sein. Man sollte daher versuchen, Testrahmen, soweit möglich, automatisch zu erzeugen. Die einschlägigen Werkzeuge bezeichnet man als Testrahmen-Generatoren. Eine automatische Testrahmen-Generierung ist oft nicht vollständig möglich. Verantwortlich sind die Eigenschaften vieler Programmiersprachen, die keine vollständige Schnittstellenspezifikation vorsehen. So gestatten viele Programmiersprachen z. B. keine saubere Unterscheidung zwischen Ausgabeparametern und transienten Parametern anhand der Schnittstellensyntax. In einigen Fällen kann der Aufwand für die Erzeugung des Testrahmens durch gemeinsamen Modultest mehrerer Funktionen bzw. Objek-

11.4 Die Prüfung

Die Modulprüfung wird oft als Modultest bezeichnet.

Testbett = Testrahmen = Dummies + Treiber

371

te reduziert werden. Das Modul besteht dann aus einer kleineren Menge von Funktionen bzw. Objekten. Es ist wichtig, beim Modultest nicht zu viele Funktionen bzw. Objekte zusammenzufassen. Dies würde die Testdurchführung erschweren. Im Modultest können nur Fehler gefunden werden, die sich auf das einzelne, betrachtete Modul beziehen. Fehler, die durch die Interaktion mehrerer Module zustande kommen, werden im Modultest nicht erkannt. Im Modultest betrachtet man Realisierungsdetails. Bei einer geeigneten Modularisierung ist die Komplexität beherrschbar, da jedes Modul für sich betrachtet wird, und Schnittstellen zu anderen Modulen zunächst unberücksichtigt bleiben.

11.4.2

Die Integrationsprüfung wird oft als Integrationstest bezeichnet.

Vorteile des Bottomup-Integrationstests

372

Die Integration und die Integrationsprüfung

Nachdem die Module getrennt geprüft sind, müssen sie integriert werden, um das Software-System aufzubauen. Diese Integration erfolgt schrittweise und wird von prüfenden Aktivitäten begleitet. Für die Integrationsprüfung ist in der Praxis der Begriff Integrationstest üblich. Integrieren und Integrationstest sind parallele Vorgänge. Das Ziel des Integrationstests ist die Prüfung der Interaktion zwischen Modulen über Schnittstellen. Der Integrationstest besitzt oft eine Feinstruktur. Er ist häufig in mehrere Software-Integrationsphasen und bei der Entwicklung eingebetteter Software in eine zusätzliche Hardware-Software-Integrationsphase unterteilt. Für den Integrationstest ist eine Integrationsstrategie festzulegen. Darüber hinaus ist zu entscheiden, welche Techniken bei der Überprüfung angewendet werden. Als Integrationsstrategien können die Bottom-up-, die Top-down-Integration und Mischformen daraus verwendet werden. Beim Integrationstest müssen wie beim Modultest fehlende unterlagerte Module durch Dummies und fehlende aufrufende Module durch Treiber ersetzt werden. Im Allgemeinen können die Dummies bzw. Treiber des Modultests wiederverwendet werden. Abb. 11.3 zeigt das Prinzip des Bottom-up-Integrationstests. Die folgenden Vorteile charakterisieren ihn: >

Das Zusammenwirken zwischen der zu prüfenden Software, der Systemsoftware und der Hardware wird früh geprüft. Da es sich hier um Schnittstellen zu Komponenten handelt, die außerhalb der eigenen Anwendung liegen, muss mit Schnittstellenproblemen gerechnet werden. Durch die frühe Prüfung ist noch hinreichend Zeit vorhanden, um Probleme zu beseitigen.

>

Da Testdateneingaben über Treiber erfolgen, ist keine Zurückrechnung der Testdaten erforderlich. Testdaten werden stets in unmittelbarer Nähe der zu testenden Schnittstellen eingegeben. Transformationen der Daten über Aufrufhierarchien hinweg finden nicht statt und müssen daher auch nicht berücksichtigt werden.

11 Prozesse und Prüfstrategien

Abbildung 11.3 Bottom-up-Integrationstest

>

Die Eingabe fehlerhafter Testdaten zur Prüfung von Fehlerbehandlungen ist ebenfalls leicht möglich, da die Eingabe über Treiber erfolgt.

Den Vorteilen des Bottom-up-Integrationstests stehen einige Nachteile gegenüber: >

Es sind Treiber erforderlich. Diese Treiber müssen, falls sie nicht aus dem Modultest verfügbar sind, erzeugt werden.

>

Eine gezielte Prüfung der Fehlerbehandlung bei fehlerhaften Rückgabewerten unterlagerter Routinen ist kaum möglich, da die realen Routinen benutzt werden.

>

Ein vorzeigbares Produkt entsteht erst am Ende der Integration, da die koordinierenden Module der obersten Hierarchieebene erst dann hinzugefügt werden.

11.4 Die Prüfung

Nachteile des Bottomup-Integrationstests

373

Abbildung 11.4 Top-down-Integrationstest

Während der Bottom-up-Integrationstest die Integration bei elementaren dienstanbietenden Modulen beginnt und in Richtung dienstnutzender Module fortführt, geht der Top-down-Integrationstest in umgekehrter Richtung vonstatten. Beim Top-down-Integrationstest beginnt man mit dem ranghöchsten Modul, das ausschließlich Dienste nutzt und selbst keine weiteren Dienste anbietet. Die Integration schreitet in Richtung der Dienstanbieter voran (Abb. 11.4). Vorteile des Top-downIntegrationstests

374

Die folgenden Vorteile charakterisieren den Top-down-Integrationstest: >

Durch den Beginn der Integration bei den ranghohen Diensten wird wichtige Steuerungsfunktionalität zu Beginn geprüft. Dabei entsteht bereits zu Beginn ein Produkt, das die groben Abläufe erkennen lässt.

>

Da unterlagerte Routinen durch Dummies ersetzt werden, ist die gezielte Prüfung der Fehlerbehandlung bei fehlerhaften Rückgabewerten unterlagerter Routinen möglich.

11 Prozesse und Prüfstrategien

Abbildung 11.5 Outside-In-Integrationstest

Die folgenden Nachteile charakterisieren den Top-down-Integrationstest: >

Es sind Dummies erforderlich.

>

Mit zunehmender Integrationstiefe wird die Erzeugung der gewünschten Testsituationen an tiefer angeordneten Schnittstellen schwieriger.

>

Das Zusammenwirkenden zwischen der zu prüfenden Software, der Systemsoftware und der Hardware wird am Ende des Integrationstests geprüft. Da hier erfahrungsgemäß Schnittstellenprobleme existieren, ist die Zeit zur Korrektur dieser Probleme am Ende des Integrationstests oft zu knapp bemessen.

Nachteile des Top-downIntegrationstests

Der Outside-In-Integrationstest ist eine Kombination aus Bottom-up- und Top-down-Integrationstest (Abb. 11.5). Der Outside-In-Integrationstest kombiniert wichtige Vorteile des Bottom-up- und des Top-down-Integrationstests und vermeidet einige ihrer Nachteile. Die folgenden Vorteile charakteriVorteile des OutsideIn-Integrationstests sieren den Outside-In-Integrationstest: >

Wichtige Steuerungsfunktionalität wird bereits zu Beginn geprüft.

11.4 Die Prüfung

375

Nachteil des OutsideIn-Integrationstests

>

Bereits zu Beginn entsteht ein Produkt, das die groben Abläufe erkennen lässt.

>

Eine gezielte Prüfung der Fehlerbehandlung von fehlerhaften Rückgabewerten unterlagerter Module ist bei Schichten, die von oben nach unten integriert werden, möglich. Rückgabewerte werden hier durch Dummies eingegeben. Diese Tests sind bei steuernden Modulen besonders wichtig, da diese oft umfangreiche Fehlerbehandlungen durchführen.

>

Das Zusammenwirken zwischen der zu prüfenden Software, der Systemsoftware und Hardware wird früh geprüft, so dass im Falle von Schnittstellenproblemen hinreichend viel Zeit für Korrekturen zur Verfügung steht.

>

Da Testdaten bei den Modulen, die von unten nach oben integriert werden, über Treiber erfolgen, ist dort keine Zurückrechnung der Testdaten erforderlich.

>

Bewusste Fehleingaben zur Prüfung von Fehlerbehandlungen sind in den Schichten, die Bottom-up integriert werden, leicht möglich.

>

Der Personalbedarf ist während des Integrationstests konstanter.

>

Falls hinreichend viel Integrationstest-Personal zur Verfügung steht, so kann ein Outside-In-Integrationstest durch das parallele Stattfinden von Bottom-up- und Top-down-Integration in kürzerer Zeit durchgeführt werden als ein reiner Bottom-up- bzw. Top-down-Integrationstest.

Diesen Vorteilen steht im Wesentlichen der einzige Nachteil gegenüber, dass beim Outside-In Test sowohl Dummies als auch Treiber erforderlich sind. Als Prüftechniken kommen für den Integrationstest sowohl funktionsorientierte wie auch strukturorientierte Ansätze in Frage. Viele Testwerkzeuge für strukturorientiertes Testen unterstützen den Modul- und den Integrationstest. Als funktionsorientierte Testtechnik bietet sich insbesondere die funktionale Äquivalenzklassenbildung an. Sie ist für die Schnittstellen durchzuführen und besteht im Wesentlichen in der Durchführung einer Fallunterscheidung für die möglichen Aufruf- und Rückgabeparameter (vergleiche hierzu auch Abschnitt 13.4).

11.4.3 Die Systemprüfung wird oft als Systemtest bezeichnet.

376

Die Systemprüfung

Die Systemprüfung wird in der Praxis auch als Systemtest bezeichnet. Man versteht darunter den Test des fertigen Systems gegen die in den Anforderungsdokumenten festgelegten Funktions-, Leistungs- und Qualitätsanforderungen.

11 Prozesse und Prüfstrategien

In der Regel werden die folgenden Tätigkeiten des Systemtests unterschieden: >

Funktionstest

>

Leistungstest

>

Stresstest

>

gegebenenfalls Beta-Test

>

Regressionstest (insbesondere bei Versionsentwicklungen)

Für den Funktionstest ist eine funktionsorientierte Testplanung durchzuführen. Die Basis für diese Testplanung bilden die Anforderungsdokumente, die systematisch in Testfälle umzusetzen sind.

Funktionstest

Der Leistungstest bringt das Software-System an Grenzbereiche heran, jedoch nicht darüber hinaus. Zu diesem Zweck müssen Lasten erzeugt werden können, und gleichzeitig z. B. Zeiten und Auslastungen gemessen werden können. Dies ist manuell in der Regel nicht möglich. Die Durchführung von Leistungstests ist daher auf eine geeignete Werkzeugunterstützung angewiesen (siehe Kapitel 12).

Leistungstest

Beim Stresstest wird das Software-System unter Wegnahme von Ressourcen überlastet. Stresstests können oft mit den selben Werkzeugen durchgeführt werden, die auch zur Unterstützung von Leistungstests dienen. Der Unterschied ist unter anderem durch die erzeugte Last gegeben. Beim Stresstest sollen z. B. die folgenden Fragen beantwortet werden:

Stresstest

>

Wie ist das Leistungsverhalten bei Überlast?

>

Geht das System nach Rückgang der Überlast wieder in den Normalbereich zurück?

>

Werden die Ressourcen wieder freigegeben?

Bei einigen Software-Systemen können Überlasten aus prinzipiellen Gründen nicht ausgeschlossen werden. Daher ist es z. B. besonders wichtig sicherzustellen, dass nach Überlastungen Software-Systeme nach Rückgang der Last in ein normales Verhalten zurückkehren. Ein Ziel des Stresstests ist z. B. die Erkennung von Verklemmungen (Deadlocks). Unter einem Beta-Test versteht man die Installation des Software-Systems bei einigen speziell ausgewählten Pilotkunden mit dem Ziel, noch vorhandene Fehler zu erkennen und abzustellen bevor das System für den Markt freigegeben wird. Bei einigen Software-Systemen kann zuvor ein Test unter Kundenbeteiligung beim Hersteller des Software-Systems durchgeführt werden. Man bezeichnet dies auch als Alpha-Test. Während es bei Problemen, die während des Beta-Tests auftreten, oft schwierig ist,

11.4 Die Prüfung

Beta-Test

Alpha-Test

377

das Fehlverhalten zu reproduzieren, besteht beim Alpha-Test die Möglichkeit, die Testaktivitäten aufzuzeichnen, so dass im Falle eines Fehlverhaltens ein Mitschnitt zur Verfügung steht. Alpha-Tests sind daher aus organisatorischen und technischen Gründen den Beta-Tests vorzuziehen. Regressionstest

Besonders wichtig ist die Durchführung von Regressionstests. Alle relevanten Standards für Software-Qualitätssicherung und Software-Qualitätsmanagement betonen die Notwendigkeit wiederholbarer Testfälle. Durch die erforderlichen Fehlerkorrekturen ist jede größere Software-Entwicklung im Prinzip eine Versionsentwicklung, in der Regressionstests unverzichtbar sind. Besonders wichtig sind sie in geplanten Versionsentwicklungen. Dies sind insbesondere Entwicklungen, in denen nach einem inkrementellen oder evolutionären Prozessmodell gearbeitet wird. Eine sinnvolle Regressionstest-Durchführung ist auf eine leistungsfähige Werkzeugunterstützung angewiesen.

11.5 Klassische Qualitätssicherung im Vergleich zum Total Quality Management (TQM)

Bei sicherheitskritischer Software fordern einschlägige Standards abgestufte Vorgehensweisen.

378

Organisatorische Aspekte

Für das Qualitätsmanagement existieren alternative Organisationsformen, die entsprechend ihrer Eigenschaften auf einer Skala angeordnet werden können. Die beiden Endpunkte der Skala bilden TQM auf der einen und die klassische Qualitätssicherung auf der anderen Seite. Totales Qualitätsmanagement (TQM) ist in der zurückgezogenen Norm DIN EN ISO 8402 /DIN EN ISO 8402 95/ definiert als auf der Mitwirkung aller ihrer Mitglieder basierende Führungsmethode einer Organisation, die Qualität in den Mittelpunkt stellt und durch Zufriedenheit der Kunden auf langfristigen Geschäftserfolg sowie auf Nutzen für die Mitglieder der Organisation und für die Gesellschaft zielt. Ein wichtiges Merkmal von TQM ist die verteilte Qualitätsverantwortung, die eine unabhängige Qualitätssicherung überflüssig erscheinen lässt. Die klassische Qualitätssicherung unterscheidet im Gegensatz zu TQM deutlich zwischen der Rolle des Entwicklers und der Rolle Qualitätssicherers. Die Qualitätsverantwortung nimmt der Qualitätssicherer wahr, der aus diesem Grund eine starke unabhängige Position benötigt. In der Regel ist die Qualitätssicherung in dieser Organisation nicht der Projektleitung unterstellt. Die Mehrzahl der Software-Unternehmen verwendet Organisationsformen, die einen Kompromiss aus beiden Ansätzen darstellen. Oft wird – insbesondere in sicherheitskritischen Anwendungen – eine unabhängige Qualitätssicherung zusätzlich zu den qualitätssichernden Maßnahmen durchgeführt, die die Entwickler verantworten. Dies ist in einigen Fällen aufgrund von Forderungen einschlägiger Standards zwingend erforderlich. Für sicherheitskritische Software sehen einige Standards abgestufte Regelungen in Abhängigkeit der Kritikalitätsstufe vor. Die Norm DIN EN 50128 „Bahnanwendungen – Software für Eisenbahnsteuerungs- und Überwachungssysteme“ /DIN EN 50128 01/ unterscheidet in der Qua-

11 Prozesse und Prüfstrategien

litätssicherung die Rollen des Verifizierers und des Validierers. Unter Verifikation wird die Überprüfung der fehlerfreien Umsetzung der Anforderungen einer Phase in das Ergebnis der Phase verstanden. Unter Validation versteht die Norm die Demonstration, dass das Produkt seine Anforderungen erfüllt. Die Norm enthält die folgenden Forderungen: >

Für Software, die nicht sicherheitsrelevant ist (Software-Sicherheitsanforderungsstufe 0) dürfen Entwerfer, Implementierer, Verifizierer und Validierer dieselbe Person sein.

>

Für Software der mittleren Sicherheitsanforderungsstufen 1 und 2 dürfen Verifizierer und Validierer dieselbe Person, aber nicht identisch mit dem Entwerfer/Implementierer sein. Diese Regelung stellt das „Vieraugenprinzip“ sicher. Die Entwicklung und die Qualitätssicherung werden von unterschiedlichen Personen durchgeführt. Beide Personengruppen dürfen jedoch an den gleichen Projektleiter berichten. Daher hat der Projektleiter die Möglichkeit, Warnungen der Qualitätssicherung zu ignorieren.

>

Für Software der hohen Sicherheitsanforderungsstufen 3 und 4 existieren zwei alternative Organisationsformen der Qualitätssicherung: –

Verifizierer und Validierer können identisch sein. Sie dürfen aber nicht gleichzeitig Entwerfer/Implementierer sein. Verifizierer und Validierer berichten nicht der Projektleitung und müssen die Möglichkeit haben, die Freigabe zu verhindern.

–

Entwerfer/Implementierer, Verifizierer und Validierer sind unterschiedliche Personen. Der Entwerfer/Implementierer und Verifizierer berichten an die Projektleitung. Der Validierer muss einen unabhängigen Berichtsweg haben. Es muss ihm möglich sein, die Freigabe zu verhindern.

Diesen Regeln liegt das folgende Prinzip zugrunde: Mit ansteigender Sicherheitskritikalität einer Software muss die personelle und organisatorische Unabhängigkeit der Qualitätssicherung zunehmen. Man kann – etwas vereinfacht – formulieren: Bei sicherheitskritischer Software wird die klassische Organisation der Qualitätssicherung den Prinzipien des Total Quality Managements vorgezogen. Diese Regel ist vereinfacht, weil die Existenz einer unabhängigen Qualitätssicherung eine in die Entwicklung integrierte Qualitätssicherung nicht ausschließt. Im Gegenteil: Insbesondere in einer sicherheitskritischen Entwicklung ist dafür zu sorgen, dass der Entwicklung die Qualitätsziele bekannt sind und Verfahren genutzt werden, um sie zu erreichen und die Erreichung zu prüfen. Die Qualität muss in die Software hineinentwickelt werden. Sie kann nicht hineingeprüft werden.

11.5 Organisatorische Aspekte

Prinzip: Je sicherheitskritischer die Software ist, um so unabhängiger muss die Qualitätssicherung sein.

379

Entwickler = Prüfer vs. Entwickler = Prüfer

Eine personelle Trennung zwischen der Tätigkeit des Entwickelns und des Prüfens scheint auf den ersten Blick stets sinnvoll zu sein. Bei näherer Betrachtung erweist sich dies als nicht korrekt. Falls z. B. der Modultest durch eine unabhängige Person durchführt wird, so ist die Aufgabe des Programmierers lediglich, sein Modul fehlerfrei zu compilieren. Wenn alle Syntaxfehler beseitigt sind, so wechselt die Verantwortung zum unabhängigen Modultester. Dieser kann bestimmte Fehler erkennen, die der Programmierer nicht bemerken kann, weil ihre Ursache z. B. Missverständnisse der Modulspezifikation sind, die einem unabhängigen Tester nicht in gleicher Weise unterlaufen. Nachteilig ist, dass der unabhängige Tester nicht über die präzise Kenntnis des Programmierers bezüglich der Struktur des Moduls verfolgt. Der Programmierer weiß, warum er bestimmte Kontrollstruktur verwendet, welche Funktionen die Variablen besitzen, und wie bestimmte Testfälle verarbeitet werden müssen. Diese Kenntnisse des Programmierers werden nicht genutzt, während der unabhängige Tester sie nicht besitzt. Das Beispiel zeigt, dass es Argumente für die Durchführung der Prüfung durch den Entwickler und andere Argumente für die Prüfung durch eine andere Person geben kann. Systematische Testtechniken bieten eine Lösung für das skizzierte Problem. Man kann beispielsweise folgendermaßen vorgehen:

Mögliche Regelung der Zuständigkeiten für die Prüfung

Falls im Modultest ein Zweigüberdeckungstest durchgeführt wird, so hat der Programmierer eine bestimmte Zweigüberdeckungsrate zu erreichen (z. B. 80 %). Dies nutzt die Sachkenntnis des Programmierers zu Beginn des Tests und gewährleistet, dass ein Modul an den unabhängigen Tester weitergegeben wird, das bereits im Wesentlichen funktioniert. Anschließend wird ein unabhängiger Tester zuständig. Das kann z. B. die gleiche Person sein, die den Integrationstest für das Modul durchführt. Die Verantwortung wechselt in diesem Fall bereits vor dem Abschluss der Phase. Der unabhängige Tester führt den Test zu Ende und gewährleistet dabei die Einhaltung des „Vieraugenprinzips“. Der Integrationstest und Systemtest wird in der Regel von unabhängigen Personen durchgeführt. In großen Software-Entwicklungen ist der Systemtest darüber hinaus oft nicht der Projektleitung unterstellt.

Hinweis: Entwickler in die Prüfung und Prüfer in die Entwicklung einbinden

Es ist sinnvoll, jene Personen, die die Prüfung durchführen, in die zugeordneten Entwicklungsphasen einzubinden. Der Systemtester sollte in die Analyse, der Integrationstester in den Entwurf und der Modultester in die Implementierung eingebunden sein. Die gleiche Regel gilt auch invers. In die Planung der Systemtestfälle sollte jemand eingebunden sein, der in die Analyse involviert war. Ebenso sollte ein Entwerfer in die Planung des Integrationstests und der Programmierer in den Modultest eingebunden sein. In einer reifen Organisation existieren systematische Arbeitsweisen, definierte Ziele und Möglichkeit zur Überprüfung ihrer Erreichung. Die Zielerreichung ist in der Vorantwortung der Entwickler. Die Aufgabe einer starken organisatorisch unabhängigen Qualitätssicherung ist lediglich,

380

11 Prozesse und Prüfstrategien

unabhängig vom Projektleiter zu prüfen, ob die definierten Ziele erreicht sind. Eine derartige Organisation der Qualitätssicherung kombiniert die Vorteile der klassischen Qualitätssicherung und des Total Quality Managements.

11.6

Dokumentation und Auswertung der Prüfung

Alle Standards zum Qualitätsmanagement und zur Qualitätssicherung betonen die Bedeutung einer systematischen Vorgehensweise bei der Prüfung. Prüfungen müssen systematisch geplant, durchgeführt, kontrolliert, ausgewertet und dokumentiert werden. Bei dynamischen Tests umfasst die Dokumentation in der Regel die Testplanung, den Nachweis der Durchführung der Testfälle und die Dokumentation der Testergebnisse. Diese Dokumente können in Abhängigkeit der verwendeten Testtechnik unterschiedlich beschaffen sein. Bei einem funktionsorientierten Test kann die Testplanungsunterlage eine Äquivalenzklassenaufstellung mit zugeordneten Testfällen sein. Die Durchführung und die Testergebnisse können durch ein Protokoll nachgewiesen werden. Strukturorientierte Tests können nur durch das Protokoll eines Testwerkzeugs nachgewiesen werden. Ein Zweigüberdeckungswerkzeug registriert die bereits getesteten Zweige und liefert ein entsprechendes Abdeckungsprotokoll. Zu der Testauswertung gehört zwingend eine sinnvolle Erfassung der Fehlverhalten. Neben dem Zeitpunkt und dem Testfall sind eine Einschätzung der Schwere des Fehlerverhaltens und eine Klassifikation des Fehlverhaltens erforderlich. Diese Daten sollten nach der Identifikation des Fehlers um das Korrekturdatum, eine Fehlerklassifikation und den Korrekturaufwand ergänzt werden. Die Informationen zu einem Fehlverhalten können z. B. wie in Tab. 11.1 dargestellt strukturiert sein.

Systematische Prüfungen sind wichtig.

Derartige Daten sind unverzichtbar für die Optimierung der Entwicklung und der Prüfung, da häufig auftretende Fehlerursachen mit Korrekturaufwänden und der Schwere des Fehlverhaltens in Beziehung gesetzt werden können. Darüber hinaus ermöglichen sie eine Kosten-Nutzen-Analyse der Prüfung. Die Einführung neuer Techniken und Werkzeuge erfor-

Eine sinnvolle Aufzeichnung von Fehlverhalten ist unverzichtbar.

Klassifikation

Klassifikation

Tabelle 11.1 Testauswertung

11.6 Dokumentation und Auswertung der Prüfung

381

dert eine finanzielle Investition, der durch Einsparungen bei der Fehlerkorrektur und reduzierten Auswirkungen von Fehlverhalten ein Nutzen gegengerechnet werden kann.

11.7

Standards

11.7.1

Bedeutung von Standards

Normen, Gesetze und Verordnungen

Standards entscheiden im Zweifelsfall, welche Verfahrensweisen, Methoden und Techniken als Stand der Technik bzw. als Stand von Wissenschaft und Technik zu betrachten sind. Neben den im Folgenden detailliert vorgestellten ausgewählten Standards und Normen, sind gesetzliche Regelungen, europäische Richtlinien und Verordnungen relevant /Rothfelder 02/. Gesetze werden vom Gesetzgeber – der Legislative – erlassen und sind verbindlich. Besonders Firmen, die sicherheitskritische Systeme entwickeln, müssen im Schadensfall erhebliche juristische Konsequenzen fürchten. Ursache sind z. B. die mit derartigen Systemen einhergehenden Risiken für die Nutzer oder auch für unbeteiligte Dritte. Im Schadensfall ergibt sich z. B. aus dem Produkthaftungsgesetz die Verpflichtung zum Ersatz eines Schadens, der durch ein fehlerhaftes Produkt entstanden ist. Ein wirksamer Haftungsausschluss ist nicht möglich. Ein Haftungsausschluss setzt voraus, dass der Fehler zum Zeitpunkt des in Verkehrbringens noch nicht vorlag, oder dass er nach dem Stand von Wissenschaft und Technik nicht erkennbar war. Die Beweislast für diesen Sachverhalt liegt im Wesentlichen beim Hersteller. Darüber hinaus können Schadensersatzansprüche nach BGB gestellt werden. Auch EU-Richtlinien haben den Charakter eines Gesetzes, weil sie von den Mitgliedsstaaten zwingend in nationales Recht umzusetzen sind. Hinzu kommen Verordnungen, die unter anderem Details zur Ausführungen von Gesetzen regeln. Verordnungen werden meistens von Behörden – der Exekutive – erlassen und sind in der Regel verbindlich.

Normen werden durch „interessierte Kreise“ erstellt.

Normung ist in Deutschland die planmäßige, durch die interessierten Kreise gemeinschaftlich durchgeführte Vereinheitlichung von materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit. Deutsche Normen werden in einem privatrechtlichen Verein durch interessierte Kreise erstellt (z. B. DIN Deutsches Institut für Normung e.V., Verband Deutscher Elektrotechniker (VDE) e.V.). Standards und Normen sind keine Rechtsnormen. Sie sind – im Unterschied zu Gesetzen – nicht rechtsverbindlich, aber sie können als antizipierte Sachverständigengutachten verstanden werden. Durch Einhaltung der jeweils relevanten Normen kann ein Hersteller sicherstellen, dass der Stand der Technik erreicht ist, und er damit seine Sorgfaltspflicht erfüllt hat.

Normen können als antizipierte Sachverständigen-Gutachten verstanden werden.

Im Folgenden werden ausgewählte Stellvertreter der folgenden drei unterschiedliche Arten von Standards betrachtet:

382

11 Prozesse und Prüfstrategien

>

Prozessorientierte Standards

>

Anwendungsbereichsunabhängige technische Standards

>

Anwendungsbereichsspezifische technische Standards

Prozessorientierte Standards regeln z. B. die Verfahrensweisen, Abläufe, Aufgaben und Verantwortlichkeiten in der Software-Entwicklung und Software-Qualitätssicherung. Im Wesentlichen enthalten sie organisatorische Forderungen. Sie schließen kaum genaue technische Forderungen ein. Prozessorientierte Standards fordern typischerweise die Durchführung einer bestimmten Tätigkeit, aber sie beschreiben in der Regel nicht, wie das zu geschehen hat. Besonders auffällig ist dies in den Normen der DIN ISO 9000-Reihe. Diese Normen sind auf eine Fülle von stark unterschiedlichen Unternehmen anwendbar, und können daher keine spezifischen Techniken fordern. Prozessorientierte Standards definieren ein organisatorisches Gerüst, in das geeignete Methoden, Techniken und Werkzeuge eingefügt werden müssen. Geschieht das nicht, so ist auch das Gerüst nutzlos. Einerseits können prozessorientierte Standards als Basis zur Zertifizierung dienen. Eine unabhängige Zertifizierungsstelle bescheinigt, dass ein Prozess konform zu dem der Zertifizierung zugrundeliegenden Standard ist. Ein typisches Beispiel ist die Zertifizierung eines Unternehmens, das Software entwickelt, gegen den Standard DIN EN ISO 9001. Die Beachtung derartiger Standards ist insbesondere für Unternehmen wichtig, die entsprechend eines solchen Standards zertifiziert werden möchten oder bereits zertifiziert sind, und das Zertifikat pflegen wollen. Darüber hinaus existieren prozessorientierte Standards, die nicht als Basis zur Zertifizierung dienen, sondern eine Basis zur Bewertung und Verbesserung von Prozessen bilden. Ein Beispiel ist der Standard ISO/IEC 15504 zum Assessment-Verfahren SPICE. Die Ergebnisse zweier SPICE-Assessments sind miteinander vergleichbar. Darüber hinaus zeigen die Assessment-Ergebnisse die spezifischen Stärken und Schwächen der bewerteten Unternehmen. Dies kann als geeignete Basis für Verbesserungsaktivitäten dienen. Prinzipiell gibt es einen weiteren Typus der prozessorientierten Standards: Die anwendungsbereichsspezifischen prozessorientierten Standards – z. B. die so genannten AQAPCentury-Standards für den militärischen Anwendungsbereich. Sehr oft sind diese Standards dicht an allgemeine prozessorientierte Standards angelehnt. So existiert z. B. eine deutliche Verwandtschaft zwischen den AQAP-Century-Standards und der DIN EN ISO 9001. In der Regel legen anwendungsbereichsspezifische prozessorientierte Standards Modifikationen allgemeinerer Standards im Hinblick auf die besonderen Anforderungen eines bestimmten Anwendungsbereichs fest. Im Folgenden werden stellvertretend für die drei genannten Arten der prozessorientierten Standards die DIN EN ISO 9001, der Standard zu SPICE und die AQAPCentury-Standards vorgestellt. Als prozessorientierte Standards erfordern sie die ergänzende Berücksichtigung technischer Standards.

11.7 Standards

Prozessorientierte Standards

383

Technische Standards

Technische Standards können ebenfalls entweder einen bestimmten Anwendungsbereich betreffen – z. B. Luftfahrt oder Schienenverkehr – oder auf bestimmte Arten von Systemen anwendbar sein, die in einer Vielzahl von Anwendungsbereichen auftreten können. Die anwendungsbereichsunabhängigen Standards können insbesondere zur Identifikation allgemein akzeptierter Praktiken dienen. Als Beispiel wird im Folgenden der Standard IEC 61508 aufgeführt. Dies ist ein sehr umfassender Standard zum Thema Sicherheit elektrisch bzw. elektronisch programmierbarer, sicherheitskritischer Systeme, der neben technischen Inhalten auch organisatorische Hinweise enthält.

Anwendungsbereichsspezifische Standards

Darüber hinaus ist es insbesondere bei der Entwicklung von softwareintensiven Systemen, die Zulassungen benötigen, unbedingt erforderlich, die direkt anwendbaren Standards zu beachten. Schienenverkehrssysteme und Flugzeuge für den zivilen Luftverkehr sind Beispiele für sicherheitskritische Systeme aus Anwendungsbereichen, zu denen Standards existieren. Diese anwendungsbereichsspezifischen Standards ergänzen die von der konkreten Anwendung unabhängigen Standards, um jene Forderungen, die aufgrund der spezifischen Anforderungen und Rahmenbedingungen eines bestimmten Anwendungsbereichs existieren. Als Beispiele werden im Folgenden einige Standards für Schienenverkehrssysteme und den Bereich der Luftfahrt diskutiert. Welche Vorgehensweisen insgesamt als notwendig bzw. hinreichend gelten müssen, entscheiden neben den Standards eines Anwendungsbereichs auch die Standards vergleichbarer Anwendungsbereiche. Die Bereiche Schienenverkehr und zivile Luftfahrt sind mit Einschränkungen vergleichbar, z. B. weil es sich in beiden Fällen um Anwendungen im Bereich des öffentlichen Personentransports handelt. Darüber hinaus sind für die Beurteilung der Eignung von Prozessen, Methoden und Techniken für zivile softwareintensive Systeme die Standards aus dem militärischen Bereich aufschlussreich.

Zusätzlich zu Standards muss der „common sense“ einer Disziplin beachtet werden.

Außerdem muss ergänzend zu den „offiziellen“ Standards unbedingt beachtet werden, welche Arbeitsweise innerhalb einer Fachgemeinschaft als kompetent – dem Stand der Technik entsprechend – betrachtet wird. Dieser „common sense“ innerhalb einer Disziplin schlägt sich nur indirekt in Standards nieder. Seine Beachtung erfordert daher eine gewisse Übersicht über ein Themengebiet. Zum Teil existieren Veröffentlichungen, die bei der Ermittlung derartiger Inhalte hilfreich sein können. Diese Veröffentlichungen haben in der Regel nicht den Status eines offiziellen Standards. Zum Stand des Tests sind z. B. einige Veröffentlichungen der Special Interest Group in Software Testing der British Computer Society erschienen.

384

11 Prozesse und Prüfstrategien

11.7.2

Prozessorientierte Standards

11.7.2.1

DIN EN ISO 9001 und V-Modell

Die DIN EN ISO 9001 /DIN EN ISO 9001 08/ ist mindestens in Europa eine verbreitet genutzte Norm zum Thema Qualitätsmanagement von Software. Einerseits wird eine Zertifizierung entsprechend der DIN EN ISO 9001 für Unternehmen, die Software entwickeln, oft als notwendig angesehen. Andererseits wird sie insbesondere in kritischen Anwendungsbereichen von Software häufig nicht als hinreichender Nachweis der Existenz eines geeigneten Qualitätsmanagementsystems gesehen. Die DIN EN ISO 9001 ist im Wesentlichen frei von konkreten technischen Inhalten. Sie fordert die Durchführung bestimmter Tätigkeiten, z. B. die Beurteilung von Unterlieferanten oder die Existenz von Eingangsprüfungen. Sie legt nicht fest, wie diese Tätigkeiten zu realisieren sind. Im Wesentlichen definiert die DIN EN ISO 9001 einen organisatorischen Rahmen für das Qualitätsmanagement. Daher ist auf dem technischen Niveau eine Ergänzung des durch die Norm definierten Rahmens erforderlich. Da die DIN EN ISO 9001-Norm in einer Vielzahl unterschiedlicher Branchen verwendbar ist, existiert der Leitfaden ISO/IEC 90003 /ISO/IEC 90003 04/ zur Anwendung der Norm auf Software. Dieser Leitfaden ist eine Lesehilfe. Zertifiziert wird nach der Norm DIN EN ISO 9001. Die Prüfung von Software wird in der ISO/IEC 90003 unter den Oberbegriffen „Testen“ und „Validierung“ behandelt. Wie in anderen prozessorientierten Normen wird auch hier der Schwerpunkt in den Bereich der gründlichen Planung von Tests, der Festlegung von Zielen und der Reproduzierbarkeit von Tests gelegt. Die Norm fordert keine bestimmten Testtechniken.

DIN EN ISO 9001 und ISO/IEC 90003

Das Vorgehensmodell (V-Modell XT) /Rausch, Broy 08/ ist als Entwicklungsstandard für IT-Systeme des Bundes für die Planung und Durchführung von IT-Projekten verbindlich. Das Vorgehensmodell ist konsistent zur DIN EN ISO 9001. Organisatorische Maßnahmen bilden den Schwerpunkt.

V-Modell XT

11.7.2.2 ISO/IEC 15504: SPICE Der Standard ISO/IEC 15504 /ISO/IEC 15504 08/ ist eine internationale Übereinkunft zum Thema Software Process Assessment. Das Verfahren ist allgemein unter dem Namen SPICE (Software Process Improvement and Capability Determination) bekannt. SPICE bildet als Vereinheitlichung diverser, akzeptierter Verfahren eine wichtige Entscheidungsgrundlage für die Bewertung, ob eine Vorgehensweise dem derzeitigen Stand der Technik entspricht. Für die Software-Prüfung sind insbesondere die Teile 2 und 5 des Standards bedeutend. Der Teil 2 beschreibt ein Referenzmodell für Prozesse und Prozessreife. Teil 5 beschreibt im Wesentlichen das dem SPICE-Verfahren zugrundliegende Assessment-Modell. Der Software-Test wird in den so genannten Engineering Process Categories 1.4 bis 1.7 be-

11.7 Standards

Das vereinheitlichte Assessment-Verfahren SPICE (ISO/IEC 15504)

385

handelt. Die geforderten Verfahrensweisen und Techniken sind konsistent zu Forderungen anderer Standards. Insbesondere sind die Abläufe konsistent zu der DIN EN ISO 9001 und zur IEC 61508. Der Schwerpunkt der Forderungen liegt im Bereich der Dokumentation von Verfahrensweisen, der systematischen Erzeugung von Prüffällen und der systematischen Durchführung von Abläufen (z. B. Integration von Software-Komponenten). Auffällig ist, dass Regressionstests explizit gefordert werden. 11.7.2.3 Die AQAP-CenturyStandards besitzen deutliche Ähnlichkeiten zur DIN ISO 9000-Normenreihe.

Die so genannten AQAP-Century-Standards (AQAP-1xx) sind prozessorientierte Standards, die eine deutliche Verwandtschaft zur DIN ISO 9000-Normenreihe aufweisen. Die Inhalte sind sehr ähnlich. Zum Teil wird auch direkt auf DIN ISO 9000-Normen verwiesen. Der Standard AQAP-150 /AQAP-150 97/ fordert explizit die Wiederholbarkeit von Tests. Dies bezieht sich sowohl auf die erforderlichen Dokumente zur Testwiederholung als auch auf die Testwiederholung nach Modifikationen (Regressionstest).

11.7.3

386

AQAP-Century-Standards

Anwendungsbereichsunabhängige technische Standards: Der Standard IEC 61508

Der Standard IEC 61508 deckt organisatorische und technische Aspekte ab.

Der Standard IEC 61508 /IEC 61508 98/ ist ein sehr umfassender Standard zum Thema Sicherheit elektrisch bzw. elektronisch programmierbarer, sicherheitskritischer Systeme. Software wird insbesondere in der IEC 61508-3 behandelt. Die generellen Anforderungen betreffen insbesondere organisatorische Aspekte. Dazu zählt z. B. die geforderte Unabhängigkeit der prüfenden Person bzw. Instanz im Rahmen von Sicherheitsnachweisen. Im Hinblick auf die Prüfung von Software liefern die Teile 3 und 7 des Standards eindeutige Hinweise. Teil 3 beschreibt im Wesentlichen die für die Abläufe erforderlichen Daten und Ergebnisse. Teil 7 ist eine Technikbeschreibung, auf die häufig in Teil 3 verwiesen wird.

Forderungen für den Modultest

Der Unterabschnitt „Requirements for software module testing“ der IEC 61508-3 beschreibt ausgesprochen klar, welche Vorgehensweisen und welche Techniken im Bereich des Modultests zu wählen sind. Ziel ist die Demonstration, dass Software-Module die gewünschten Funktionen erbringen und unerwünschte Funktionen nicht eintreten können. Der Standard wählt die Formulierung „shall show“. Es ist also explizit kein Beweis, sondern lediglich eine Demonstration gefordert. Darüber hinaus wird explizit darauf hingewiesen, dass es nicht erforderlich ist, alle Eingabe- oder Ausgabekombinationen abzudecken. Vielmehr wird der Test aller Äquivalenzklassen oder strukturorientiertes Testen als ausreichend definiert. Formale Methoden und die Verwendung von Zusicherungen (assertions) werden explizit erwähnt.

11 Prozesse und Prüfstrategien

In Unterabschnitt „Requirements for Software Integration Testing“ verlangt der Standard IEC 61508-3 eine dokumentierte Vorgehensweise für den Test. Die Forderungen für die einzusetzenden Techniken sind im Wesentlichen identisch mit den Forderungen für den Modultest. Darüber hinaus werden einige weitere Nachweise verlangt. Dies betrifft insbesondere die Dokumentation von Testergebnissen und die Prüfungswiederholung im Falle von durchgeführten Modifikationen. Im Grunde ist dies eine explizite Forderung nach dokumentierten Regressionstests. Besonders hilfreich für die Identifikation der einzusetzenden Techniken sind die Tabellen im Anhang des Standards IEC 61508-3. Techniken werden in Abhängigkeit des Kritikalitätsniveaus der Software empfohlen. Es werden so genannte Safety Integrity Levels (SILs) verwendet. Sicherheitskritisch sind die SILs 1 bis 4. Die Sicherheitskritikalität steigt von niedrigen zu hohen SILs an.

Forderungen für den Integrationstest

Während funktionsorientiertes Testen über alle SILs hinweg gefordert wird, treten probabilistisches Testen und Simulations- bzw. Modulierungstechniken erst in SIL 3 und 4 hinzu. Die Tabelle „Dynamic analysis and testing“ sieht die Nutzung von Äquivalenzklassen erst für SIL 4 vor. Strukturorientiertes Testen tritt bereits in SIL 3 auf. Dies steht im Widerspruch zu den Inhalten der Tabelle „Functional and black-box testing“. Hier werden Äquivalenzklassenverfahren ab SIL 2 empfohlen.

Abgestufte Forderungen in Abhängigkeit des Kritikalitätslevels

Insgesamt ist davon auszugehen, dass die Verwendung systematischer, funktionsorientierter Testtechniken auch für nicht sicherheitskritische Software Stand der Technik ist. Das gleiche gilt für einfache strukturorientierte Tests, z. B. den Zweigüberdeckungstests. Die in dem Standard IEC 61508 verwendeten Begriffe entsprechen in ihrer Definitionen nicht stets dem heute allgemein akzeptierten Stand der Praxis.

11.7.4

Anwendungsbereichsspezifische technische Standards

11.7.4.1

DIN EN 50128

Der Standard DIN EN 50128 /DIN EN 50128 01/ ist für die Anwendung auf Schienenverkehrssysteme vorgesehen. Die Norm DIN EN 50128 „Bahnanwendungen - Software für Eisenbahnsteuerungs- und Überwachungssysteme“ ist ein europäischer Standard.

Standards für Schienenverkehrssysteme

In Kapitel 11 der Norm DIN EN 50128 sind die Software-Verifikation und der Test geregelt. Kapitel 13 der DIN EN 50128 regelt die Software-Validierung. Neben technischen sind einige organisatorische Forderungen enthalten. Die organisatorischen Forderungen sind deutlich spezifischer als z. B. in der Norm DIN EN ISO 9001. Im Wesentlichen handelt es sich um Verfeinerungen und Ergänzung. Widersprüche gibt es zwischen den Normen nicht. Es herrscht Konsistenz zwischen der DIN EN ISO 9001 bzw. DIN EN ISO 90003 und der DIN EN 50128. Für die Software-Verifikation und den Test werden diverse Eingangs- und Ausgangsdokumen-

Die DIN EN 50128 ist konsistent zur DIN EN ISO 9001 bzw. ISO/IEC 90003.

11.7 Standards

387

te gefordert, die insbesondere anzuwendende Verfahren, Verantwortlichkeiten, Testeinrichtungen, Testziele und Testumgebungen definieren. Die Verifikation hat über die verschiedenen Entwicklungsphasen hinweg bis hin zur Software-Quellcodeverifikation zu erfolgen. Die anzuwendenden Techniken ergeben sich entsprechend der so genannten Software-Sicherheitsanforderungsstufe (SSAS). Charakteristisch für die Techniken-Tabellen der DIN EN 50128 ist, dass Unterschiede bezüglich der empfohlenen Techniken nur zwischen SSAS 0, SSAS 1 bis 2 und SSAS 3 bis 4 enthalten sind. Den SSAS 1 und 2 bzw. SSAS 3 und 4 sind jeweils gleiche Techniken zugeordnet. Nicht alle Techniken-Definitionen entsprechen den in der Forschung und Praxis verbreiteten Definitionen. Darüber hinaus sind zum Teil deutliche Freiheitsgrade vorhanden. Einige explizit empfohlene Techniken sind in der Praxis in vielen Fällen nicht anwendbar. Die Tabellen lassen aber geeignete Alternativen zu. Die Norm DIN EN 50128 ermöglicht ein Zuschneiden der technischen Arbeitsweise anhand der konkret gegebenen Anwendungsbedingungen. Diese Anpassung muss notwendig durchgeführt werden. In vielen Fällen wird z. B. der für die Sicherheitsanforderungsstufe 3 oder 4 anzuwendende formale Beweis aufgrund ungünstiger Rahmenbedingungen nicht durchführbar sein. Das gleiche gilt für die symbolische Ausführung. Alternativ kann z. B. die statische Analyse in Kombination zum dynamischen Test eingesetzt werden. Dies ergibt zweifellos nicht die gleiche Aussagequalität wie eine Kombination aus einem formalen Beweis und dem dynamischen Test, ist aber nach der Norm DIN EN 50128 zulässig. 11.7.4.2 Ein Standard für Avionik

Die RTCA/DO 178B enthält explizite Forderungen zum strukturorientierten Test.

388

RTCA/DO 178B

Der Standard /RTCA DO-178B 92/ betrifft Software-Anforderungen im Bereich der Avionik. Die Inhalte des Standards sind durchaus vergleichbar mit den Forderungen der DIN EN 50128. Darüber hinaus ist die RTCA/DO 178B ausgesprochen explizit im Hinblick auf Anforderungen an den strukturorientierten Test. Die Sicherheitseinstufung erfolgt über so genannte „Software-Level“. Der kritischste Software-Level trägt die Bezeichnung A. Er ist anwendbar für Software, deren Fehlfunktion eine katastrophale Ausfallwirkung für ein Luftfahrzeug herbeiführen würde. Die Software-Level B, C, D und E sind für entsprechend abgestufte, unkritischere Ausfallwirkungen anwendbar. Neben den üblichen funktionsorientierten Tests für alle Kritikalitätslevel verlangt der Standard RTCA/DO 178B die explizite Erreichung bestimmter struktureller Testabdeckungen im Code. Für Software des Levels A wird explizit die Erreichung einer vollständigen strukturorientierten Testabdeckung nach dem Verfahren Modified Condition/Decision Test gefordert (siehe Kapitel 3: Modifizierter Bedingungs-/Entscheidungsüberdeckungstest). Diese Technik ist oberhalb des Zweigüberdeckungstests angesiedelt und nimmt eine Stellung zwischen den einfachen Bedingungsüberdeckungstest und dem Mehrfachbedingungsüberdeckungstest ein. Grundsätzlich ist das Ziel dieses Verfahrens, zusammengesetzte Entscheidungen, deren Evaluierungsergeb-

11 Prozesse und Prüfstrategien

nis von mehreren Teilentscheidungen festgelegt wird, umfassend zu prüfen. Der Zweigüberdeckungstest berücksichtigt dieses nicht. Der Zweigüberdeckungstest wird von der Norm RTCA/DO 178B bereits für Software des Levels B zwingend gefordert. Für Software des Levels C wird die Erreichung eines Anweisungsüberdeckungstests empfohlen.

11.8

Bewertung

Ein definierter Software-Entwicklungsprozess ist eine notwendige Voraussetzung für eine reife, qualitätsorientierte Software-Entwicklung. In der Praxis interessiert man sich seit einigen Jahren zunehmend für Verfahren zur Optimierung von Entwicklungsprozessen. Reife Prozesse allein reichen nicht aus. Der Rahmen, der durch den Prozess vorgegeben ist, muss mit geeigneten Techniken und Werkzeugen gefüllt werden. Die Tätigkeiten Analysieren, Entwerfen, Kodieren und Prüfen sind Bestandteil aller Prozessmodelle. Entwickelnde und prüfende Tätigkeiten beeinflussen einander, da die Ergebnisse der Entwicklungsphasen als Prüfreferenzen dienen. Eine sinnvolle Prüfung ist in Phasen unterteilt. Standards schreiben zum Teil bestimmte organisatorische und technische Inhalte vor. Mit zunehmender Sicherheitskritikalität der Software wird die Existenz einer organisatorisch und personell unabhängigen Qualitätssicherung wichtiger. Auf die Durchführung qualitätssichernder Maßnahmen durch Entwickler sollte dennoch nicht verzichtet werden.

>

Überlegen Sie, ob das Prozessmodell, das Sie zur Zeit nutzen, wirklich Ihren Anforderungen entspricht.

>

Wenn Sie Ihren Software-Entwicklungsprozess optimieren wollen, so sollten Sie über die Verwendung des SPICE-Verfahrens nachdenken, da dieser Ansatz international vereinheitlicht ist.

>

Prüfen Sie, ob es für Ihren Anwendungsbereich Standards gibt.

>

Falls Sie keine direkt anwendbaren Standards identifizieren können, so sollten Sie prüfen, ab es Standards für verwandte Anwendungsbereiche gibt. Obwohl diese Standards nicht direkt anwendbar sind, kann man ihnen oft wertvolle Hinweise entnehmen.

>

Ein systematischer, definierter Entwicklungsprozess ist eine wichtige Voraussetzung für qualitätsgerechte Software.

11.8 Bewertung

Reife Prozesse sind notwendig aber nicht hinreichend.

CHECKLISTE

389

“This page left intentionally blank.”

12 Werkzeuge Werkzeuge unterstützen die Software-Prüfung. Sie können eine geeignete Methodik nicht ersetzen. Sie können sie aber unterstützen. Die Wahl geeigneter Methoden und Techniken steht an erster Stelle. Die Auswahl von Werkzeugen muss die bereits ausgewählten Methoden und Techniken beachten. Der Kauf eines Werkzeuges, ohne zuvor eine geeignete methodische und technische Vorgehensweise identifiziert zu haben, ist unsinnig. Dennoch sind Werkzeuge zur Unterstützung der Prüfung wichtig und für manche Techniken unverzichtbar. Werkzeuge dienen zur effizienten Durchführung von Prüfungen. Sie informieren über den Stand der Prüfung. Sie nehmen zeitraubende Auswertungen vor. Darüber hinaus ist die werkzeugunterstützte Protokollierung einer Prüfung unverzichtbarer Bestandteil eines Nachweises gegenüber Kunden.

Übersicht 12.1

Eigenschaften und Ziele der Nutzung von Werkzeugen . . . . . . 392

12.2

Werkzeugtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

12.3

Verfügbarkeit von Werkzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

12.4

Informationsquellen über Werkzeuge . . . . . . . . . . . . . . . . . . . . . . 403

12.5

Bewertung der Nutzung von Werkzeugen . . . . . . . . . . . . . . . . . . 403 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

391

12.1

Eigenschaften und Ziele der Nutzung von Werkzeugen

Es gibt zahlreiche unterschiedliche Gründe für die Werkzeugbenutzung. Werkzeuge dienen zur Beobachtung und Beurteilung der durchgeführten Prüfung. Dies gilt insbesondere für strukturorientierte Testwerkzeuge – z. B. ein Zweigüberdeckungstest-Werkzeug – die während der Testdurchführung die erreichten Überdeckungen registrieren und anzeigen. Die Person, die den Test durchführt, erhält so die Information, welche Teile der Software bereits getestet sind, und welche Tests noch notwendig sind. Diese Funktionalität dient gleichzeitig für den Nachweis des ordnungsgemäß durchgeführten Tests z. B. gegenüber Auftraggebern oder Prüfbehörden. Testprotokolle, die durch Werkzeuge erzeugt worden sind, haben einen quasi „unbestechlichen“ Charakter. Sie dienen als offizielles Nachweisinstrument. Des Weiteren wird die Testmessung unterstützt, die es gestattet, Ziele für Testabdeckungen zu definieren. Neben der Anfertigung des „unbestechlichen“ Protokolls, einhergehend mit der Testmessung, dienen Werkzeuge insbesondere zur effizienteren Durchführung der Prüfung. Ein Beispiel sind Fehlerbaumwerkzeuge, die die quantitative Berechnungen des Fehlerbaums automatisch durchführen und damit den Benutzer von der Berechnung befreien. Ein anderes Beispiel sind Markov-Werkzeuge, die ein Markov-Modell in ein Differenzialgleichungssystem überführen und dieses anschließend lösen, oder statistische Zuverlässigkeitsanalysewerkzeuge, die den Benutzer bezüglich der Anwendung der statistischen Verfahren entlasten. Darüber hinaus dienen Werkzeuge zur Entlastung des Prüfers bei der Durchführung sich wiederholender, umfangreicher aber einfacher Tätigkeiten. Ein Beispiel sind Regressionstestwerkzeuge. Zusammenfassend sind die folgenden Ziele für den Werkzeugeinsatz zu nennen:

392

>

Bereitstellung von Informationen über die Prüfung

>

Durchführung von Messungen

>

Effizienzerhöhung

>

Durchführung von „schwierigen“ Tätigkeiten (z. B. mathematische Verfahren)

>

Verlässliche Abwicklung von einfachen Tätigkeiten (z. B. Regressionstest)

>

Erzeugung von Prüfprotokollen als Nachweisinstrument gegenüber Dritten

12 Werkzeuge

12.2

Werkzeugtypen

Da unterstützende Werkzeuge zu den gewählten Methoden und Techniken passen müssen, findet man bei den Werkzeugen eine ähnliche Bildung von Klassen wie bei den Methoden und Techniken. Man kann grob die folgenden Werkzeugtypen unterscheiden: >

Dynamische Testwerkzeuge

>

Statische Analysewerkzeuge

>

Formale Verifikationswerkzeuge

>

Modellierende und analysierende Werkzeuge

12.2.1

Dynamische Testwerkzeuge

Die dynamischen Testwerkzeuge bilden die sicherlich zahlenmäßig stärkste Kategorie der am Markt verfügbaren Werkzeuge. Ursache ist nicht zuletzt die starke Verbreitung dieser Techniken in der Praxis. Daher existierte ein großes Interesse an entsprechenden unterstützenden Werkzeugen. In der Praxis sind insbesondere die folgenden Typen von dynamischen Testwerkzeugen anzutreffen: >

Strukturorientierte Testwerkzeuge

>

Funktionsorientierte Testwerkzeuge

>

Regressionstestwerkzeuge

>

Leistungs- und Stresstestwerkzeuge

Strukturorientierte Testwerkzeuge dienen insbesondere der Bereitstellung von Informationen über den Stand der Prüfung. Ferner bieten sie mit dem entsprechenden Testüberdeckungsprotokoll einen Nachweis für die ordnungsgemäße Durchführung der Tests. Die in der Praxis besonders verbreiteten Zweigüberdeckungstest-Werkzeuge gehören dieser Kategorie an.

Dynamische Testwerkzeuge sind zahlreich verfügbar.

Strukturorientierte Testwerkzeuge

Zweigüberdeckungstest-Werkzeuge zeigen an, welche Zweige bereits getestet sind, sowie welche Zweige ungetestet und daher noch zu prüfen sind. Dies geschieht oft unter Nutzung von Kontrollflussgraphen als Darstellungsinstrument. Diese Kontrollflussgraphen werden in der Regel von den Werkzeugen automatisch erzeugt. Die erforderliche statische Analysefunktionalität ist in die Werkzeuge integriert. Darüber hinaus berechnen die Werkzeuge ein entsprechendes Überdeckungsmaß. Bei einem Zweigüberdeckungstest-Werkzeug ist das geeignete Testüberdeckungsmaß die Zweigüberdeckungsrate. Die Zweigüberdeckungsrate wird oft sowohl absolut – d. h. als Quotient aus getesteten und vorhandenen Zweigen – als auch relativ – d. h. prozentual – angezeigt.

12.2 Werkzeugtypen

393

Auswertung und Darstellung der Testergebnisse

Das Testwerkzeug soll die Beziehung zwischen Programmtext und Quellode verwalten.

Instrumentierende Testwerkzeuge

394

Darüber hinaus gibt es zur Auswertung von Testläufen oft eine Gesamtauswertung über alle bisher durchgeführten Testfälle und eine getrennte Auswertung des zuletzt durchgeführten Testfalls. Die Gesamtauswertung dient dabei zur Identifikation insgesamt noch nicht getesteter Programmelemente. Die Auswertung des letzten Testfalls dient insbesondere zur Fehleridentifikation bei Testfällen, die Fehlverhalten zu Tage gefördert haben. Der Fehler kann nur in Programmteilen verborgen sein, die beim Testlauf ausgeführt wurden. Daher ist diese Information ein wichtiges Hilfsmittel zur Fehleridentifikation. Zur Darstellung der Testergebnisse können sowohl grafische als auch textuelle Darstellungen angeboten werden. In der Regel wird auf dem Modultest-Niveau als grafische Darstellungsform der Kontrollflussgraph gewählt. Auf dem Integrationstest-Niveau kann z. B. die Darstellung von Aufrufüberdeckungen anhand von Strukturdiagrammen (SD-Diagramme) erfolgen. Es bietet sich aber gegebenenfalls auch eine Darstellung in einer aufbereiteten Form des Quellcodes an. Grafische Darstellungen besitzen den Vorteil der besseren Übersichtlichkeit, während textuelle Darstellungen einen besseren Bezug zwischen Testfällen und getestetem Code herstellen. Nach meiner Erfahrung ist es ideal, wenn strukturorientierte Testwerkzeuge sowohl grafische als auch textuelle Darstellungen anbieten und idealerweise die Abbildung zwischen beiden Repräsentationen verwalten. Dies ermöglicht es dem Tester, je nach Fragestellung die Darstellung zu wechseln. Die Auswertung von Testfällen wird im Regelfall zunächst einmal anhand der grafischen Repräsentation vorgenommen werden. Wird ein Zweigüberdeckungstest anhand des Kontrollflussgraphen ausgewertet und dabei ein noch nicht ausgeführter Zweig erkannt, so muss zur Erstellung eines entsprechenden Testfalls eine Rückabbildung des Kontrollflussgraphen auf den Quellcode vorgenommen werden. Wenn dies von Hand erfolgt, so ist das mühsam. Darüber hinaus ist nicht einzusehen, warum diese Rücktransformation manuell zu erfolgen hat. Schließlich hat das Testwerkzeug den Kontrollflussgraphen automatisch aus dem Quellcode erzeugt und könnte sich mühelos die Abbildung zwischen Quellcode und Kontrollflussgraph „merken“. Denkbar ist, dass z. B. durch Auswahl eines Zweiges des Kontrollflussgraphen in einem zweiten Fenster der zugehörige Quellcode hervorgehoben dargestellt wird, um die Zuordnung zwischen Grafiken und Quellcode automatisch herzustellen. Eine entsprechende Abbildung sollte auch in anderer Richtung existieren. Es sollte möglich sein, durch Markieren von Code die entsprechend zugeordneten Teile von grafischen Darstellungen zu identifizieren. Eine rein grafische Darstellung für die Testfallauswertung ist ebenso wie eine rein textuelle Auswertung des Tests nach meiner Erfahrung nicht optimal. Strukturorientierte Testwerkzeuge besitzen in der Regel eine Abhängigkeit von der gewählten Programmiersprache. Der überwiegende Teil der strukturorientierten Testwerkzeuge arbeitet instrumentierend. Instrumentieren bedeutet, dass das Testwerkzeug zunächst einmal eine Syntaxanalyse des zu testenden Quellcodes durchführt und eine gering-

12 Werkzeuge

fügig modifizierte Kopie des Quellcodes erzeugt. In die Kopie sind zusätzliche Anweisungen eingefügt worden, die bei der Testdurchführung Informationen über den Testverlauf auf einen nichtflüchtigen Speicher – in der Regel das Dateisystem – aufzeichnen. Man bezeichnet den Vorgang dieses Hinzufügens zusätzlicher Anweisungen als instrumentierend. Diese Vorgehensweise gestattet es den Testwerkzeugen während der eigentlichen Testdurchführung inaktiv sein zu können. Es ist der Testling selbst, der die notwendigen Informationen über den Testverlauf ablegt. Diese Informationen können nach Ende des Testlaufs durch das Testwerkzeug ausgelesen und entsprechend aufbereitet angezeigt werden. Vorteilhaft an dieser instrumentierenden Vorgehensweise ist, dass sich die Speicherbelegung nicht durch ein zusätzlich beim Test ablaufendes Testwerkzeug ändert. Nachteilig ist, dass der instrumentierte Testling durch die Instrumentierung Abweichungen zum Original besitzt. Aufgrund der zusätzlichen Anweisungen werden Ausführungszeiten verlängert, was insbesondere für den Test von Echtzeitsoftware kritisch sein kann. Die Programmiersprachenabhängigkeit instrumentierender dynamischer Testwerkzeuge ergibt sich aus der Notwendigkeit, die Syntax des Quellcodes zu erzeugen. Diese Funktionalität unterscheidet sich nicht wesentlich von der Funktionalität, die Compiler für die Programmiersprache besitzen. Neben der großen Anzahl der instrumentierenden Testwerkzeuge gibt es einige wenige nicht-instrumentierende Testwerkzeuge. Diese Werkzeuge laufen typischerweise auf einem separaten Computer, der die auf dem Adressbus auftauchenden Adressen des in der Ausführung befindlichen Testlings über eine Hardware-Schnittstelle abgreift. Diese Strategie gestattet es, Überdeckungen auf einem tiefen Niveau zu registrieren. Nachteilig ist, dass aufgrund der Caching-Strategien moderner Prozessoren nicht alle auf dem Adressbus auftretenden Adressen zur Ausführung gelangen. Es ist daher unmöglich, auf diesem Niveau eine verlässliche Überdeckung zu registrieren. Auch ein Abschalten der Caches ist keine Lösung, da sich so das Laufzeitverhalten ändert.

Nicht-instrumentierende Testwerkzeuge

Die in der Praxis verbreitetste Variante strukturorientierter dynamischer Testwerkzeuge ist daher die instrumentierende. Strukturorientierte dynamische Testwerkzeuge enthalten aufgrund der Erzeugung grafischer Darstellungen stets statische Analysefunktionalitäten. Da für die Instrumentierung ohnehin eine Syntaxanalyse nötig ist, werden oft bei dieser Syntaxanalyse bestimmte Merkmale des Programms gezählt. Diese werden anschließend in Form von Messwerten angeboten. Ein typisches Maß, das Zweigüberdeckungstest-Werkzeuge anbieten, ist die so genannte zyklomatische Zahl. Funktionsorientierte Testwerkzeuge dienen insbesondere zur Testfallerzeugung. Sie sind oft in der Lage, Testfälle nach bestimmten funktionsorientierten Testtechniken – z. B. der funktionalen Äquivalenzklassenbildung – zu planen. Darüber hinaus können in einigen Werkzeugen kon-

12.2 Werkzeugtypen

Funktionsorientierte Testwerkzeuge

395

krete Testdaten und die erwarteten Testergebnisse festgelegt werden. Der Test kann anschließend automatisch durchgeführt werden. Eine verbreitete funktionsorientierte Testunterstützung bieten die so genannten Zusicherungswerkzeuge. Diese gestatten die Nutzung von Zusicherungen. Bei der Formulierung der Zusicherungen muss eine feste Syntax beachtet werden. Die Werkzeuge setzen die so beschriebene Zusicherung in ausführbaren Code um, der bei der Testdurchführung sicherstellt, dass Verletzungen von Zusicherungen unmittelbar gemeldet werden. Funktionsorientierte Testwerkzeuge sind in der Regel programmiersprachenunabhängig. Mit Ausnahme der Werkzeuge für die Formulierung von Zusicherungen greifen sie in der Regel nicht in den Quellcode ein. Während strukturorientierte dynamische Testwerkzeuge für die Testdurchführung unverzichtbar sind, besitzen funktionsorientierte dynamische Testwerkzeuge eher die Eigenschaft der Komforterhöhung und der systematischen Dokumentation der Testplanung. Funktionsorientierte dynamische Testwerkzeuge sind daher weniger essentiell als strukturorientierte dynamische Testwerkzeuge. Dennoch sind sie insbesondere für die dokumentierte Durchführung umfangreicher funktionsorientierter Tests wichtig. Regressionstestwerkzeuge

Während strukturorientierte dynamische Testwerkzeuge im Wesentlichen zur Beobachtung des Testlings und funktionsorientierte dynamische Testwerkzeuge zur Testplanung dienen, zielen Regressionstestwerkzeuge auf die Automatisierung der Testdurchführung. Regressionstestwerkzeuge zeichnen die Testdaten und Testergebnisse auf. Anschließend können die aufgezeichneten Testdaten wiederholt werden. Die dabei erzeugten Testergebnisse werden mit den ursprünglich aufgezeichneten Testergebnissen verglichen. Abweichungen werden gemeldet. Die Durchführung von Regressionstests ist insbesondere nach Fehlerkorrekturen und Funktionserweiterungen erforderlich, um ungewollte Seiteneffekte dieser Modifikationen weitgehend auszuschließen. Es ist bekannt, dass die manuelle Testwiederholung sowohl technisch als auch wirtschaftlich unsinnig ist. Der einzig sinnvolle Weg ist die Automatisierung dieses Vorgangs mit einem Regressionstestwerkzeug. Regressionstestwerkzeuge sind daher ein sehr wichtiger Werkzeugtyp. Da die Werkzeuge Daten an den Ein- und Ausgabekanälen aufzeichnen bzw. einspielen, müssen Regressionstestwerkzeuge in der Regel nicht in den Quellcode eingreifen. Sie sind daher im Allgemeinen von der konkret gewählten Programmiersprache unabhängig. Regressionstestwerkzeuge besitzen in der Regel auch die Möglichkeit, grafische Oberflächen zu prüfen. Die verbreiteten menügestützten, fensterbasierten Oberflächen stellen für diese Werkzeuge in der Regel kein Problem dar.

Leistungs- und Stresstestwerkzeuge

Leistungs- und Stresstestwerkzeuge dienen zur Durchführung von Leistungs- und Stresstests. Die beiden Testarten besitzen viele Gemeinsamkeiten. Der Hauptunterschied ist die Belastung des Testlings. Beim Leistungstest wird der Testling im Normalbereich an der Grenze zur Überlast betrieben, während ein Stresstest ein Betrieb bei Überlast ist. Für beide Testarten ist es erforderlich, Lasten zu erzeugen. So könnte es

396

12 Werkzeuge

z. B. erforderlich sein, Last für ein Buchungssystem zu erzeugen, das für die Bedienung von maximal 100 Terminals ausgelegt ist. Dies kann nur werkzeugunterstützt vorgenommen werden, da eine gewisse Gleichzeitigkeit bei der Belastung einzuhalten ist, und darüber hinaus mit dem Eintritt bestimmter Ereignisse Zeiten oder Auslastungen gemessen werden können. Leistungs- und Stresstestwerkzeuge sind oft in Regressionstestwerkzeuge integriert. Dies ist naheliegend, da Regressionstestwerkzeuge ohnehin die Möglichkeit des Mitschnitts von Tests bieten. Eine Lasterzeugung kann in der einfachen Vervielfältigung eines Regressionsmitschnitts bestehen. Gegebenenfalls müssen Betriebsparameter – z. B. Adressen – modifiziert werden. Leistungs- und Stresstestwerkzeuge bieten typischerweise Editierfunktionen für Regressionsmitschnitte an. Darüber hinaus besitzen Leistungs- und Stresstestwerkzeuge zahlreiche Messfunktionen für die Registrierung von Antwortzeitverhalten und Ressourcenauslastungen.

12.2.2

Statische Analysewerkzeuge

Statische Analysefunktionen sind oft in dynamische Testwerkzeuge integriert. Sie sind aber auch getrennt verfügbar. Man kann die folgenden Werkzeugkategorien unterscheiden: >

Messwerkzeuge

>

Stilanalysatoren

>

Werkzeuge zur Erzeugung von Grafiken und Tabellen

>

Slicing-Werkzeuge

>

Datenflussanomalieanalyse-Werkzeuge

Messwerkzeuge dienen zur Gewinnung und Darstellung von Informationen über ein Software-Produkt durch Mittel der statischen Analyse. Messwerkzeuge führen zu diesem Zweck eine Analyse des Quellcodes durch, bei der sie bestimmte Merkmale im Code registrieren und in aufbereiteter Form anzeigen. Sie sind daher in der Regel programmiersprachenspezifisch. Verbreitete Maße der statischen Analyse sind die zyklomatische Zahl, die Halsead-Maße, Maße zur Datenkomplexität und einfache Maße wie Lines of Code. Durch statische Analyse können nur solche Maße bestimmt werden, die präzise definiert sind. Falls ein manueller Eingriff erforderlich ist – wie z. B. bei dem Function Point-Maß die Bestimmung der Komplexitäten – so scheidet dieses Maß bei der Bestimmung durch die statische Analyse aus. Insbesondere die Ermittlung der zyklomatischen Zahl und der Halstead-Maße sind oft in dynamische Testwerkzeuge integriert.

12.2 Werkzeugtypen

Messwerkzeuge

397

Stilanalysatoren

Stilanalysatoren analysieren ähnlich wie statische Messwerkzeuge den Quellcode. Sie bestimmen jedoch keine Messwerte aus abgezählten Größen sondern suchen nach bestimmten vordefinierten oder einstellbaren Verletzungen von Programmierregeln. Diese Regeln können Einschränkungen für die zu verwendenden programmiersprachlichen Konstrukte enthalten. Sie können aber auch zusätzliche Forderungen, die bei der Programmierung zu beachten sind, definieren. Die Verwendung von Stilanalysatoren wird für bestimmte Programmiersprachen in bestimmten Anwendungsgebieten explizit gefordert. In diesem Fall besitzen Stilanalysatoren eine hohe Bedeutung.

Werkzeuge zur Erzeugung von Tabellen und Grafiken

Werkzeuge zur Erzeugung von Tabellen und Grafiken besitzen eine weite Verbreitung. Im Wesentlichen treten derartige Werkzeuge aber nicht allein sondern als Bestandteil von Werkzeugumgebungen oder integriert in dynamische Testwerkzeuge auf. Sehr verbreitet ist die Erzeugung von Kontrollfluss- und Aufrufgraphen sowie von Variablen-Cross-Reference-Tabellen als Bestandteil der Funktionalität dynamischer Testwerkzeuge.

Slicing-Werkzeuge

Slicing-Werkzeugedienen bei der Prüfung von Software im Wesentlichen zur Unterstützung der Fehlersuche nach Erkennung eines Fehlverhaltens (Debugging).

Datenflussanomalieanalysatoren

Sehr wichtige Werkzeuge der statischen Analyse sind Datenflussanomalieanalyse-Werkzeuge. Diese statische Analysefunktionalität ist oft in Compiler integriert. Darüber hinaus gibt es zahlreiche Werkzeuge, die Datenflussanomalieanalysen explizit anbieten. Die Erkennung von Datenflussanomalien auf statischem Wege ist mit sehr wenig Aufwand möglich, stets automatisierbar und bietet sichere, verlässliche Ergebnisse. Eine Menge von Prüfwerkzeugen, die keine Unterstützung von Datenflussanomalieanalysen bietet, ist aus meiner Sicht daher unvollständig. Die automatische Durchführung von Datenflussanomalieanalysen ist unverzichtbar.

12.2.3 Es gibt kaum kommerziell verfügbare formale Verifikationswerkzeuge.

398

Formale Verifikationswerkzeuge

Formale Verifikationswerkzeuge werden von professionellen Werkzeuganbietern kaum zur Verfügung gestellt. Die Mehrzahl der formalen Verifikationswerkzeuge kommt aus dem universitären Bereich. Ihre Nutzung für die praktische Software-Entwicklung ist daher einerseits eingeschränkt. Andererseits gibt es Anwendungsbereiche, in denen bestimmte Verifikationstechniken eine gewisse Bedeutung besitzen. Hier ist insbesondere die Entwicklung von eingebetteter Software im sicherheitskritischen Umfeld zu nennen. Aber auch für diesen Anwendungsbereich werden kaum Werkzeuge auf dem Markt angeboten. Vielmehr gibt es Firmen, die sich mit eigenen Werkzeugumgebungen als Beratungsunternehmen, die die Anwendung formaler Techniken anbieten, etabliert haben.

12 Werkzeuge

Darüber hinaus gibt es Anbieter eingebetteter Systeme, die mit eigenen Werkzeugumgebungen formale Techniken anwenden. Eine gewisse Verbreitung besitzen insbesondere symbolische Verfahren in militärischen Software-Entwicklungen. Auf dem Markt wird für diesen Anwendungsbereich Werkzeugunterstützung angeboten. Professionelle Werkzeugunterstützung existiert insbesondere für automatenbasierte Techniken und zum Teil auch für das symbolische Testen. Induktive Zusicherungsverfahren und algebraische Techniken werden von kommerziellen Werkzeuganbietern kaum unterstützt. Die wenigen verfügbaren Werkzeuge sind oft im Rahmen von Forschungsarbeiten realisiert worden. Die stärkste Bedeutungszunahme für die Praxis verzeichnen insbesondere in der jüngeren Vergangenheit die automatenbasierten Techniken und die darauf basierenden formalen Verifikationsverfahren. An erster Stelle ist das Symbolic Model Checking zu nennen, das dazu dient, Eigenschaften von Zustandsautomaten nachzuweisen. Derartige Verfahren besitzen vor allem dort eine hohe Bedeutung, wo Zustandsautomaten ein wichtiges Beschreibungsmittel sind. Dies gilt insbesondere in der Automatisierungsund Steuerungstechnik. In der praktischen Anwendung gestattet es Symbolic Model Checking, extrem große Zustandsräume in die Untersuchung einzubeziehen. Eine Voraussetzung für die Anwendbarkeit der Technik auf sehr große Zustandsautomaten ist eine so genannte „dünne“ Belegung des Zustandsraumes. Diese Voraussetzung scheint in der Praxis oft erfüllt zu sein. Die Zustandsautomaten werden in der Regel effizient dargestellt. Etabliert haben sich als Darstellungsmittel für Zustandsautomaten so genannte Ordered Binary Decision Diagrams (OBDDs). Die Eigenschaften, die von den Zustandsautomaten gefordert werden, werden in der Regel in temporaler Logik angegeben. Üblich ist die Formulierung von z. B. Sicherheits- und Lebendigkeitseigenschaften. Sicherheit manifestiert sich in der Nichterreichbarkeit gefährlicher (unsicherer) Zustände. Lebendigkeit bedeutet, dass ein bestimmter Zustand immer wieder erreicht wird. Der Nachweis der Eigenschaften erfordert in der Regel eine Durchsuchung des kompletten Zustandsraumes. Dies erfordert bei großen Zustandsräumen effiziente Algorithmen, die in modernen Werkzeugen realisiert sind.

12.2.4

Symbolic Model Checking kann werkzeugunterstützt auf sehr große Zustandsräume angewendet werden.

Modellierende und analysierende Werkzeuge

Modellierende und analysierende Prüfwerkzeuge gibt es insbesondere zur Anwendung im Bereich der Risikoanalyse. In der Praxis werden derartige Werkzeuge verbreitet für Sicherheits-, Zuverlässigkeits- und Verfügbarkeitsanalysen genutzt. In der Praxis findet man insbesondere FMECA (Failure Mode, Effects and Criticality Analysis)- und Fehlerbaumanalyse-Werkzeuge. Darüber hinaus werden Werkzeuge zur Markov-Modellierung genutzt. Werkzeuge zur stochastischen Analyse von Software-Zuver-

12.2 Werkzeugtypen

Modellierende Werkzeuge sind zahlreich verfübar.

399

lässigkeit besitzen noch keine nennenswerte Verbreitung in der Praxis. Es ist zu erwarten, dass ihre Bedeutung in Zukunft stark zunehmen wird.

400

FMECA-Werkzeuge

FMECA-Werkzeuge bieten in der Regel eine einfache Oberfläche zur Nutzung von FMECA-Formblättern. Es können Ursachen und Wirkungen erfasst werden. Darüber hinaus können die drei Einflussfaktoren der Risikoprioritätszahl – die Gewichte der Eintrittswahrscheinlichkeit, der Wahrscheinlichkeit des Nichterkennens und des Gewichts der Auswirkungen – erfasst werden. Die Risikoprioritätszahl wird bestimmt. Darüber hinaus können Verbesserungsvorschläge und die daraus resultierenden Auswirkungen miterfasst werden. Vielfach bieten FMECA-Werkzeuge die Möglichkeit, die Wirkungen einer FMECA ein Abstraktionsniveau höher als Ursachen zu übernehmen. Dies ermöglicht es, die Analysen von Komponenten bei der Durchführung der FMECA für das System zu nutzen.

Fehlerbaumanalyse-Werkzeuge

Fehlerbaumanalyse-Werkzeuge werden verbreitet in sicherheitskritischen Systementwicklungen eingesetzt. Für sicherheitskritische Systeme sind oft die besonders kritischen Ausfälle bekannt. Diese werden mit einer Fehlerbaumanalyse detailliert qualitativ und quantitativ untersucht. Fehlerbaumanalyse-Werkzeuge bieten sowohl die Möglichkeit, Fehlerbäume zeichnerisch zu erfassen, als auch Hilfestellung bei der quantitativen Auswertung der Fehlerbäume. Ich halte die zeichnerische Erfassung von Fehlerbäumen mit einem Zeichenwerkzeug und die Auswertung des Fehlerbaums mit dem Taschenrechner für anachronistisch. Für diesen Zweck sollte ein professionelles Werkzeug genutzt werden.

Markov-Werkzeuge

Die quantitative Auswertung von Markov-Modellen ist ohne geeignete Werkzeugunterstützung kaum möglich. Der wesentliche Vorteil bei der Benutzung von Markov-Modellierungswerkzeugen ist die leistungsfähige Unterstützung der quantitativen Auswertung der Modelle. Dies beinhaltet die Umsetzung des Markov-Modells in ein Differenzialgleichungssystem und dessen Lösung. In der Regel sind Markov-Modellierungswerkzeuge in der Lage, sowohl die Aufenthaltswahrscheinlichkeiten in den Zuständen nach dem Abklingen von Einschwingvorgängen aufzuzeigen als auch den transienten Übergang von der Anfangssituation in die Situation nach dem Abklingen von Einschwingvorgängen darzustellen.

Weitere Werkzeuge

Bei den genannten drei Werkzeugkategorien handelt es sich nicht um eine vollständige Liste. Es existieren noch weitere Werkzeuge – z. B. zur Durchführung so genannter HAZOPs (Hazard and Operability Analysis) oder zur Durchführung von Ereignisbaumanalysen. FMECA-, Fehlerbaumanalyse- und Markov-Modellierungswerkzeuge sind unter den modellierenden Werkzeugen die zur Zeit in der Praxis wichtigsten.

Stochastische Software-Zuverlässigkeitsanalysen

Eine zur Zeit offensichtlich geringere Verbreitung in der Praxis besitzen Werkzeuge zur Durchführung stochastischer Software-Zuverlässigkeitsanalysen. Aufgrund des zunehmenden Eindringens von Software in sicherheitskritische, hoch zuverlässige Anwendungsbereiche ist damit zu

12 Werkzeuge

rechnen, dass die Bedeutung von Werkzeugen zur Durchführung entsprechend statistisch abgesicherter Analysen zunehmen wird. Stochastische Software-Zuverlässigkeitsanalyse-Werkzeuge nutzen Ausfallbeobachtungen, um mit Mitteln der Statistik Informationen zur aktuellen Software-Zuverlässigkeit zu erzeugen. Darüber hinaus ist es möglich, Prognosen für die zukünftige Entwicklung der Software-Zuverlässigkeit zu erhalten. Dies schließt insbesondere so genannte „Restfehlerprognosen“ ein. Die Werkzeuge unterstützen oft neben der Kalibrierung eines entsprechenden Zuverlässigkeitsmodells auch die Auswahl des Modells. Sowohl Kalibrierung als auch Auswahl erfordern einen nennenswerten Rechenaufwand, der von Hand kaum zu leisten ist. Von der manuellen Anwendung der stochastischen Software-Zuverlässigkeitsanalyse (siehe Abschnitt 14.6) wird nachdrücklich abgeraten. Eine sinnvolle stochastische Software-Zuverlässigkeitsanalyse erfolgt stets werkzeugunterstützt.

12.3

Verfügbarkeit von Werkzeugen

Die Test-, Analyse-, Verifikations- und Modellierungstechniken, die in diesem Buch dargestellt werden, werden nicht gleichmäßig von Werkzeugherstellern mit Werkzeugen abgedeckt. Die Abdeckung ist stark ungleich verteilt. Darüber hinaus ist auch die Verfügbarkeit von Werkzeugen für unterschiedliche Programmiersprachen und Entwicklungsbzw. Zielplattformen nicht gleichmäßig. Bestimmte Programmiersprachen und Entwicklungsumgebungen werden bevorzugt.

12.3.1

Die Werkzeugabdeckung ist nicht gleichmäßig.

Abdeckung von Techniken durch Werkzeuge

Der Großteil der auf dem Markt verfügbaren Werkzeuge unterstützt dynamische Testtechniken. Den Schwerpunkt bilden Werkzeuge für kontrollflussorientierte, strukturorientierte Techniken einerseits und für Regressionstest- Unterstützung und die Durchführung von Leistungs- und Stresstests andererseits. Bei den kontrollflussorientierten, strukturorientierten Testtechniken sind ohne Zweifel Werkzeuge zur Unterstützung des Zweigüberdeckungstests am häufigsten vertreten. Datenflussorientierte, strukturorientierte Testwerkzeuge werden von professionellen Werkzeuganbietern nur in geringer Zahl zur Verfügung gestellt. Werkzeuge für funktionsorientiertes Testen sind verfügbar. Sie bilden im Vergleich zu den kontrollflussorientierten Testwerkzeugen aber eine deutlich kleinere Gruppe. Werkzeuge zur Durchführung von statischen Analysen sind zahlreich verfügbar. Besonders verbreitet ist die Nutzung statischer Analysefunktionalitäten als Bestandteil dynamischer Testwerkzeuge. Symbolische Testwerkzeuge und formale Verifikationswerkzeuge werden von professionellen Werkzeuganbietern wenig zur Verfügung gestellt. Universitäten und Forschungseinrichtungen bieten zahlreiche

12.3 Verfügbarkeit von Werkzeugen

401

Werkzeuge an. In diesem Zusammenhang ist das Fehlen eines professionellen Supports als kritisch zu bewerten. Modellierungswerkzeuge für Sicherheit und Zuverlässigkeit finden sich zahlreich. Insbesondere Fehlerbaumwerkzeuge existieren in großer Zahl. Werkzeuge zur Durchführung stochastischer Zuverlässigkeitsanalysen sind nicht weit verbreitet. Die entsprechenden Werkzeuge kommen oft aus dem universitären Umfeld und besitzen experimentellen Charakter.

12.3.2

Abdeckung von Programmiersprachen durch Werkzeuge

Viele Werkzeuge sind programmiersprachenunabhängig. Dies gilt in der Regel z. B. für Regressionstestwerkzeuge, Leistungs- und Stresstestwerkzeuge, funktionsorientierte Testwerkzeuge, FMECA-, Fehlerbaumund Markov-Werkzeuge sowie für stochastische Zuverlässigkeitsanalyse-Werkzeuge. Im Gegensatz dazu sind insbesondere strukturorientierte dynamische Testwerkzeuge in der Regel programmiersprachenabhängig. Da diese Werkzeuge bei der Durchführung eines strukturorientierten dynamischen Tests unverzichtbar sind, ist es wichtig, ein Werkzeug zu finden, das zur verwendeten Programmiersprache passt. Die umfassende Unterstützung in diesem Bereich existiert zur Zeit für die Sprachen C, C++ und Java. Darüber hinaus werden Sprachen wie Ada und zum Teil auch Pascal unterstützt. Des Weiteren findet man Werkzeuge für die im naturwissenschaftlichen Bereich nach wie vor verbreitete Sprache Fortran und die im kaufmännischen Bereich verbreiteten Cobol-Programme. Darüber hinaus werden viele „exotische“ Programmiersprachen unterstützt. Da es sich bei diesen Werkzeugen oft um Produkte handelt, die von kleinen Firmen in geringeren Stückzahlen vertrieben werden, ist es schwierig, diese Werkzeuge zu finden. Weitere Informationsquellen zu Werkzeugen enthält Abschnitt 12.4.

12.3.3

Abdeckung von Entwicklungs- und Zielplattformen durch Werkzeuge

Viele Werkzeughersteller, die früher zahlreiche Plattformen unterstützt haben, haben sich entschlossen, die Zahl der Plattformen zu verringern. Die meisten Werkzeughersteller unterstützen PC-Plattformen mit unterschiedlichen Betriebssystemen. Darüber hinaus werden Werkzeuge für verschiedene Unix-Varianten angeboten. Es gibt einige Lösungen für VMS und, insbesondere bei Werkzeugen für die Programmiersprache Cobol, die Unterstützung von Großrechnerplattformen. Einzelne Hersteller bieten als Nischenlösungen Werkzeuge für sehr „exotische“ Plattformen an. Die Identifikation dieser Werkzeuge ist aufgrund ihrer geringen Marktdurchdringung jedoch schwierig. Weitere Informationen dazu enthält der folgende Abschnitt.

402

12 Werkzeuge

12.4

Informationsquellen über Werkzeuge

Es gibt sehr viele Werkzeuge für den Test, die Analyse, das Verifizieren, die Modellierung und die stochastische Untersuchung von Software. Da es sich vielfach um spezielle Lösungen handelt, ist es schwierig, das in einem konkreten Fall optimal geeignete Werkzeug zu finden. Daher werden an dieser Stelle einige Informationsquellen aufgeführt. Ich halte insbesondere das Internet und einschlägige Kongresse mit Ausstellungen von Werkzeuganbietern für geeignete Informationsquellen. Beide Empfehlungen helfen allein nicht weiter, denn im Internet findet man Informationen nicht ohne weiteres, und Kongresse existieren in großer Zahl. Im Internet existieren einige Seiten, die Informationen über Werkzeuge in konzentrierter Form anbieten und Links auf die Seiten der Werkzeuganbieter enthalten. Ich halte diese zusammenfassenden Darstellungen für einen guten Einstieg in die Werkzeugsuche, weil sie einen Überblick in kompakter Form ermöglichen. Sie gestatten es, zunächst einmal herauszufinden, welche Werkzeuge überhaupt existieren, und für welche Programmiersprachen und Plattformen sie welche Funktionalität bieten.

Werkzeuge im Internet

Ich empfehle eher nicht den Besuch der großen – recht unspezifischen – Computermessen. Viele kleinere Werkzeuganbieter besuchen diese Messen nicht, da der Prozentsatz der Besucher, der sich für Prüfwerkzeuge interessiert eher gering sein dürfte. Anbieter von Software-Prüfwerkzeugen nutzen seit mehreren Jahren verstärkt Kongresse, die sich den Themen Software-Test, -Analyse und -Verifikation widmen und parallel zum Kongressprogramm eine Werkzeugmesse veranstalten. Oft nehmen an derartigen Messen zahlreiche Werkzeuganbieter teil. Die Messen dauern in der Regel ein bis zwei Tage und gestatten es, viele unterschiedliche Werkzeuge in kurzer Zeit kennen zu lernen.

Werkzeuge auf Fachmessen

Da sowohl Informationen über Internetseiten wie auch Informationen zu veranstalteten Kongressen sehr schnell veralten, habe ich mich entschlossen, diese Informationen nicht in dieses Buch aufzunehmen, sondern ebenfalls über das Internet verfügbar zu machen. Sie erhalten Informationen über Internetseiten zu den Themen Software-Prüfwerkzeuge und Kongresse mit Werkzeuganbietern unter www.liggesmeyer.de.

12.5

Infos unter www.liggesmeyer.de

Bewertung der Nutzung von Werkzeugen

Die Nutzung von Werkzeugen zur Durchführung von Prüfungen ist essentiell. Dennoch sei an dieser Stelle daran erinnert, dass die Auswahl einer geeigneten methodischen und technischen Vorgehensweise vorrangig ist. Im Bereich des strukturorientierten dynamischen Tests gilt der Zweigüberdeckungstest als Minimalkriterium. Die Durchführung eines Zweigüberdeckungstests ohne Werkzeugunterstützung ist in der Praxis unmöglich. Daher besitzen strukturorientierte Testwerkzeuge – minimal

12.5 Bewertung der Nutzung von Werkzeugen

Methodiken und Techniken besitzen Vorrang vor Werkzeugen, aber bestimmte Werkzeuge sind unverzichtbar.

403

ein Zweigüberdeckungstest-Werkzeug – einen unverzichtbaren Charakter. Aufgrund der Verfügbarkeit von Testwerkzeugen wird man in der Praxis oft den Zweigüberdeckungstest anwenden müssen. Dies gilt auch dann, wenn man technisch einen datenflussorientierten Test vorziehen würde, weil die Werkzeugunterstützung für datenflussorientiertes Testen oft fehlt. Ein weiterer Typus von Werkzeugen, die als unverzichtbar gelten müssen, sind Regressionstestwerkzeuge. Jede größere praktische Software-Entwicklung erfordert Fehlerkorrekturen und oft auch Funktionserweiterungen, die die Gefahr von Folgefehlern bergen. Die Durchführung von Regressionstests ist in solchen Entwicklungen unverzichtbar. Technisch und wirtschaftlich sinnvoll sind Regressionstests nur automatisiert. Daher ist auf die einschlägigen Werkzeuge nicht zu verzichten. Modellierende und stochastische Sicherheits- und Zuverlässigkeitsanalyse-Werkzeuge sind zur Zeit im Wesentlichen nur bei Entwicklung sicherheitskritischer eingebetteter Software zu finden. Dies könnte sich insbesondere im Hinblick auf das wachsende Qualitätsbewusstsein von Betreibern besonders für die stochastische Zuverlässigkeitsanalyse in Zukunft ändern. Es ist zu erwarten, dass die Verbreitung dieser Werkzeuge zunehmen wird. Formale Verifikationswerkzeuge und symbolische Testwerkzeuge sind ebenfalls im Bereich sicherheitskritischer eingebetteter Software zu finden. Eine Ausweitung des Anwendungsbereichs auf konventionelle Software-Entwicklungen ist zur Zeit nicht zu erkennen. Statische Analysewerkzeuge besitzen insbesondere als Bestandteil dynamischer Testwerkzeuge – z. B. Erzeugung von Kontrollflussgraphen, Berechnung von Messwerten – eine hohe Bedeutung. Besonders wichtig ist die werkzeugunterstützte Ermittlung von Datenflussanomalien. Ich halte eine derartige Unterstützung für unverzichtbar. Darüber hinaus besitzt die werkzeugunterstützte Überprüfung von Programmierkonventionen in bestimmten Anwendungsbereichen einen zwingenden Charakter.

CHECKLISTE

404

>

Konzipieren Sie zuerst eine methodische und technische Vorgehensweise. Suchen Sie dazu passende Werkzeuge anschließend aus.

>

Ihre Methodik wird stets einen dynamischen Test enthalten. Da es sich minimal um einen Zweigüberdeckungstest handeln wird, sollten Sie mindestens ein Zweigüberdeckungstest-Werkzeug nutzen.

>

Wenn Sie absehen können, dass sich in Ihrer Software Änderungen durch Fehlerkorrekturen oder Funktionserweiterungen einstellen werden, so sollten Sie ein Regressionstestwerkzeug nutzen.

>

Prüfen Sie, ob Ihr Compiler die Datenflussanomalieanalyse unterstützt. Falls das nicht der Fall ist, so nutzen Sie unbedingt ein Datenflussanomalieanalyse-Werkzeug.

>

Falls in Ihrer Programmierumgebung Zusicherungen unterstützt werden, sollten Sie das nutzen. Falls das nicht der Fall ist,

12 Werkzeuge

so verwenden Sie ein Werkzeug, das Ihnen Zusicherungen bietet. >

Wenn Sie Sicherheits- und Zuverlässigkeitsanalysen mit der FMECA, Fehlerbäumen oder Markov-Modellen durchführen, so sollten Sie das werkzeugunterstützt realisieren.

>

Falls Sie als Programmiersprache C verwenden, so können Sie die schwache Syntax dieser Sprache durch Verwendung von Stilanalysatoren verschärfen. Dies wirkt in der Regel qualitätserhöhend. Diese Erkenntnis hat sich bereits in Standards niedergeschlagen, die die Nutzung von Stilanalysatoren insbesondere in Kombination mit der Programmiersprache C für kritische Software-Entwicklungen zwingend vorsehen. Dieser Sicht der Dinge sollten Sie sich gegebenenfalls anschließen.

12.5 Bewertung der Nutzung von Werkzeugen

405

“This page left intentionally blank.”

13 Prüfen von objektorientierter Software Eine wachsende Anzahl von Firmen verwendet objektorientierte Analyse- und Entwurfstechniken und objektorientierte Programmiersprachen für die Software-Entwicklung. Anfangs hoffte man, dass objektorientierte Software nur eine erheblich reduzierte Prüfung erfordern würde und dass die gewohnten Vorgehensweisen unmodifiziert verwendet werden könnten. Dieser Wunsch hat sich nicht erfüllt. Die kleinste unabhängig testbare Einheit in der Objektorientierung ist in der Regel ein Objekt. Objekte sind Instanzen von Klassen. Sie besitzen eine kompliziertere Struktur als die Module der funktional dekomponierenden Software-Entwicklung – die Funktionen. Daher ist zu erwarten, dass der objektorientierte Modultest eher schwieriger sein wird als gewohnt. Zusätzlich sind die Aspekte Vererbung und Polymorphie, sowie die Existenz parametrisierter Klassen zu beachten. Das softwaretechnisch gewünschte starke Kapselungsprinzip der objektorientierten Software-Entwicklung behindert den Test ebenfalls. Objektorientierte Konzepte können – geeignet eingesetzt – die Prüfung auch unterstützen. Falls die Kapselung von Klassen streng durchgehalten wird, so können Klassen unabhängig geprüft werden. Der durch die Vererbung explizite Zusammenhang zwischen Oberund Unterklassen kann im Integrationstest zu einer Wiederverwendung von Testfällen führen, so dass der Testplanungsaufwand deutlich reduziert werden kann.

Übersicht 13.1

Eigenschaften und Ziele des Prüfens von objektorientierter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

13.2

Hinweise für die objektorientierte Entwicklung . . . . . . . . . . . . . 410

13.3

Objektorientierter Modultest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

13.4

Objektorientierter Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . 428

13.5

Objektorientierter Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

13.6

Bewertung des Prüfens von objektorientierter Software . . . . 437 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

407

13.1

Gleiche Prüfphasen; andere Regeln innerhalb der Phasen

Eigenschaften und Ziele des Prüfens von objektorientierter Software

Die Ziele bei der Prüfung objektorientierter Software besitzen keine Unterschiede zu den Zielen des Prüfens funktional dekomponierter Software. Man könnte erwarten, dass daher auch die Mittel zur Erreichung dieser Ziele unverändert übernommen werden können. Dies gilt aber nur eingeschränkt. Es existieren tatsächlich kaum neue Prüftechniken für objektorientierte Software; aber die Eignung der bekannten Techniken ändert sich. Bisher geeignete Techniken werden ungeeignet, und Techniken, die bei klassischer Software ungeeignet schienen, sind nun geeignet. Die Unterteilung der Prüfung in die drei Phasen Modultest, Integrationstest und Systemtest bleibt erhalten. Die Tätigkeiten innerhalb dieser Phasen gehorchen jedoch anderen Regeln, und die Grenzen der Phasen sind weniger scharf definiert. Bei den klassischen Prüfverfahren können formale Beweise, statische Analysen und dynamische Tests unterschieden werden. In der Praxis werden dynamische Tests am häufigsten genutzt. Die wichtigsten dynamischen Testtechniken sind die funktions- und die strukturorientierten Testtechniken. Weil funktionsorientierte Testtechniken auf Spezifikationen basieren, setzen sie keine bestimmte Art der Realisierung voraus. Sie sind gleichermaßen auf funktional dekomponierte wie auf objektorientierte Software anwendbar. Ihre Eignung wird aber in der Regel von der Art der Spezifikation und bestimmten Eigenschaften der Software beeinflusst. Strukturorientierte Testtechniken basieren auf Kontrollflussgraphen. Derartige Graphen können für eine C++-Operation ebenso wie für eine C-Funktion erzeugt werden. Die strukturorientierten Techniken sind daher in der Objektorientierung einsetzbar. Das bedeutet aber nicht, dass die gleichen strukturorientierten Techniken wie bisher geeignet sind.

OO-Techniken besitzen Vorteile.

408

Ohne Zweifel besitzen objektorientierte Entwicklungen einige wesentliche Vorteile gegenüber funktional dekomponierenden Entwicklungen. Objektorientierte Analyse- und Entwurfstechniken zielen auf die Vermeidung konzeptioneller Fehler in frühen Entwicklungsphasen. Sie erleichtern die Nutzung kommerzieller Bibliotheken, die bereits qualitätsgesichert sind. Sie erhöhen die Produktivität durch Unterstützung der Wiederverwendung. Der bei Techniken wie Structured Analysis (SA) /DeMarco 85/, /Yourdon 00/ und Structured Design (SD) gefürchtete Methodenbruch beim Übergang von der Analyse- in die Entwurfsphase bleibt aus. Die Ergebnisse der Analysephase werden im Entwurf ergänzt, aber nicht gänzlich modifiziert. Die Objektorientierung ermöglicht ein durchgängiges Konzept für die Phasen Analyse, Entwurf und Implementierung und bietet ein klares Paradigma zur Problemanalyse. Ob dieses Paradigma in allen Anwendungsbereichen tragfähig ist, wird die Zukunft zeigen. Objektorientierte Programmiersprachen unterstützen auf eine natürliche

13 Prüfen von objektorientierter Software

Weise das seit langem bekannte Prinzip der Datenabstraktion, indem sie Funktionen um Daten gruppieren und so Klassen bilden. Datenabstraktion ist schon in einigen klassischen Programmiersprachen realisierbar, aber die funktional dekomponierten Software-Architekturen klassischer Software-Entwicklungen begünstigen die Nutzung dieses Prinzips nicht. Dieser Vielzahl positiver Aspekte der Objektorientierung, die sich im Wesentlichen auf die frühen Phasen der Entwicklung (Analyse, Entwurf und Realisierung) beziehen, stehen einige in klassischen Systemen nicht vorhandene Schwierigkeiten bei der Überprüfung – also in den späten Phasen – gegenüber. Die dynamischen Abläufe in objektorientierten Systemen sind statisch nur schwierig nachvollziehbar. Die Dynamik entsteht durch den Versand von Botschaften zwischen Objekten. Darüber hinaus wird das Verhalten eines Objekts durch die Werte seiner Attribute mitbestimmt. Hinzu kommen Komplexitäten durch Polymorphie, dynamisches Binden und Vererbung, mit der Möglichkeit, ererbte Eigenschaften zu ergänzen, zu überschreiben oder zu löschen. Die Anwendbarkeit manueller Prüftechniken (Inspektionstechniken) ist daher kompliziert. Die Abläufe in einer objektorientierten Software sind oft schwieriger verständlich als bei einer funktional dekomponierten Software. Dies reduziert die Verständlichkeit und begünstigt Fehler.

OO-Techniken besitzen leider auch Nachteile.

Zusammenfassend kann man davon ausgehen, dass Objektorientierung einerseits eine exzellente Analyse- und Entwurfsmethode ist, andererseits aber einige Probleme für die Prüfung schafft. Diese neuen Schwierigkeiten sind durchaus beherrschbar, aber man muss Regeln kennen und beachten, um sie kontrollieren zu können. Objektorientierte Programmierung kann in Bezug auf Sicherheits- und Echtzeiteigenschaften kritisch sein. Die dynamische Erzeugung und Zerstörung von Objekten und das damit einhergehende dynamische Binden erfordern zusätzliche Laufzeit, was möglicherweise im Widerspruch zu Echtzeitanforderungen steht. Bezeichnend ist, dass es keine wirklichen Echtzeitspezifikationen in objektorientierten Techniken gibt. Selbst die so genannte Real-Time UML /Douglass 98/ unterstützt das nur eingeschränkt. Konzepte wie z. B. Polymorphie und Vererbung erschweren den Nachweis der Korrektheit eines Programms. Bereits der Sprachumfang klassischer Programmiersprachen musste zur Ermöglichung eines formalen Korrektheitsbeweises gegen eine formale Spezifikation eingeschränkt werden. Einerseits ist zu erwarten, dass eine entsprechende Beschränkung objektorientierter Programmiersprachen einen ähnlichen Sprachumfang ergeben würde. Andererseits sind erfahrungsgemäß nur kleine Teile sicherheitskritisch, so dass ein formaler Korrektheitsnachweis nur an wenigen Stellen erforderlich sein wird. Für die übrigen Teile kann die objektorientierte Sprache vollständig genutzt werden. Das setzt allerdings voraus, dass eine Trennung kritischer und unkritischer Teile möglich ist. Die relative Abgeschlossenheit von Klassen und Objekten

13.1 Eigenschaften und Ziele des Prüfens von objektorientierter Software

OOP vs. Sicherheit und Echtzeit

409

begünstigt diesen Entwurf der Software entsprechend der Kritikalität. Sicherheitskritische Funktionen (z. B. Notabschaltung) können gekapselt und anders entwickelt werden, als die konventionellen Funktionen. Geeignete Testtechniken für objektorientierte Software sind vorhanden. Leider sind aber kaum käufliche Testwerkzeuge vorhanden, die diese Techniken unterstützen. Die vorhandenen Testwerkzeuge unterstützen oft Techniken, deren Eignung für objektorientierte Software fragwürdig ist.

13.2

Hinweise für die objektorientierte Entwicklung

Objektorientierte Programmiersprachen sind älter als objektorientierte Analyse- und Entwurfstechniken.

Programmiersprachen mit objektorientierten Eigenschaften (SIMULA67) sind bereits in den sechziger Jahren entwickelt worden. Die erste voll objektorientierte Programmiersprache (Smalltalk) stammt aus den siebziger Jahren. Zur Zeit erfreuen sich die Sprachen C++ und besonders Java einer wachsenden Beliebtheit in der Praxis. Objektorientierte Analyse- und Entwurfsmethoden wurden erst zu Beginn der neunziger Jahre vorgestellt /Coad, Yourdon 91/, /Rumbaugh et al. 91/, /Jacobson et al. 92/ nachdem sich Objektorientierung als Programmierparadigma – insbesondere im Bereich der graphischen Fenstersysteme – bereits durchgesetzt hatte. Den Standard der Praxis für die objektorientierte Analyse und den objektorientierten Entwurf bildet zur Zeit die Unified Modeling Language (UML) /Balzert 00/, /Booch et al. 98/, /Rupp et al. 07/.

Objektorientierung vs. objektorientierte Programmierung

Objektorientierte Analyse- und Entwurfstechniken sind eine bestimmte Methode zur Strukturierung von Problemen. Es ist wichtig, Objektorientierung als universelles Paradigma zur Beschreibung allgemeiner Systeme von der objektorientierten Programmierung zu unterscheiden, die die adäquate Möglichkeit zur Kodierung objektorientiert entworfener Software darstellt. Ein wesentlicher Vorteil der Nutzung objektorientierter Methoden ist die Qualität der entstehenden Architektur. Objektorientierte Software besitzt in der Regel eine bessere Struktur als funktional dekomponierte Software. Die strenge Modularisierung ist eine Haupteigenschaft der Objektorientierung, die sich positiv auf die Prüfung auswirkt. Durch das Zusammenfassen von Daten und Verarbeitung können die Auswirkungen von Änderungen oft lokal gehalten werden. Die Wiederverwendung wird begünstigt. Es ist wichtig, das Modularisierungskonzept entsprechend der Objektorientierung konsequent durchzuhalten und nicht aufzuweichen. Das Abgeschlossenheitskonzept soll möglichst nicht durchbrochen werden (z. B. keine friend-Klassen in C++, keine public-Attribute, keine Zugriffe auf Attribute unter Umgehung der dafür zuständigen Operationen). Auf diese Weise wird die unabhängige Testbarkeit der Klassen aufgrund ihrer Abgeschlossenheit sichergestellt. Dies ist eine wichtige Voraussetzung für den objektorientierten Modultest. Darüber hinaus soll durch konsequente Anwendung der Verfeinerung von der Analyse über den Entwurf in die Kodierung eine Konsis-

Modularisierung

410

13 Prüfen von objektorientierter Software

tenz der Strukturelemente der Software mit der Spezifikationsstruktur hergestellt werden. Vererbung ist eine wichtige Eigenschaft objektorientierter Methoden, die sowohl positive als auch negative Aspekte besitzt. Sinnvoll und mit Zurückhaltung angewendete Vererbung wirkt positiv. Sie gestattet eine Reduktion der Komplexität. Die Voraussetzungen sind, dass die Vererbungshierarchien nicht zu tief werden, dass eine einheitliche Regel für die Identifikation von Unterklassen und Oberklassen angewandt wird und dass Mehrfachvererbung mit Vorsicht verwendet wird.

Vererbung

Die genannten Regeln sollen auch bei der Kodierung beachtet werden. Ein besonders geeignetes Hilfsmittel zur Offenbarung von Fehlersituationen sind Zusicherungen (siehe Kapitel 5). Sie verbessern die Beobachtbarkeit von Klasseninterna ohne das Kapselungsprinzip zu verletzen. Zusicherungen sollten insbesondere in der objektorientierten Programmierung zwingend verwendet werden.

Zusicherungen

13.3

Objektorientierter Modultest

In der klassischen Entwicklung wird in der Regel eine abgeschlossene Funktionseinheit als kleinste unabhängig prüfbare Einheit betrachtet. Für die Entwicklung von Software bedeutet das in Abhängigkeit der Mechanismen, die die verwendete Programmiersprache zur Verfügung stellt, dass bei einem geeigneten Entwurf z. B. Prozeduren, Funktionen oder Unterprogramme getrennt voneinander getestet werden können. In der Objektorientierung stellen die einzelnen Operationen in den Klassen eine elementare Funktionalität zur Verfügung. Es ist jedoch falsch, zu schließen, dass aus diesem Grund Operationen unabhängig voneinander getestet werden können. Da die Operationen eines Objekts als Exemplar einer Klasse durch gemeinsam verwendete Attribute und gegenseitige Benutzung untereinander starke Abhängigkeiten aufweisen, sind sie – mit Ausnahme von Spezialfällen – nicht oder nur mit unvertretbar hohem Aufwand unabhängig testbar. Grundsätzlich können einzelne Operationen lediglich bei Klassen, die keinen internen Zustand besitzen, unabhängig getestet werden (z. B. die Operationen sin, cos, ln, usw. einer Klasse, die mathematische Funktionen zur Verfügung stellt). Derartige zustandslose Klassen sind jedoch Ausnahmen. Daher ist es sinnvoll, die Klasse bzw. das Objekt als kleinste unabhängig prüfbare Einheit objektorientierter Systeme zu betrachten. Der objektorientierte Integrationstest beginnt erst mit dem Test des Zusammenwirkens von Objekten verschiedener Klassen.

Objektorientierter Modultest = Klassentest

Eine Klasse ist eine Beschreibung einer Menge gleichartiger Objekte. Um eine Klasse dynamisch zu testen, müssen demnach spezifische Ausprägungen – Objekte – erzeugt werden. Erst nach der Objekterzeugung können Nachrichten an ein Testobjekt versandt werden. Damit einzelne Test-

13.3 Objektorientierter Modultest

411

fälle voneinander unabhängig sind, muss pro Testfall ein neues Testobjekt erzeugt werden. Andernfalls können Testfälle nicht in beliebiger Reihenfolge ausgeführt werden, wodurch die Wiederverwendung von Testfällen der Oberklasse beim Test ihrer Unterklassen behindert wird.

13.3.1 Testfälle für objektorientierte Software sind in der Regel Nachrichtensequenzen an Objekte.

Klassentest als objektorientierter Modultest

In der Regel wird beim objektorientierten Modultest eine einzelne Klasse oder ein Verbund einiger weniger Klassen geprüft. Die Testfälle sind Nachrichtensequenzen an Objekte der zu testenden Klasse. Problematisch ist, dass eine so genannte Fehlermaskierung auftreten kann. So könnte z. B. bei Ausführung einer Operationensequenz (m1, m2, m3) ein Fehlverhalten der Operation m1 durch die nachfolgende Ausführung der Operationen m2 und m3 verdeckt werden. Um einen Fehler zu erkennen, muss das Fehlverhalten bei der Testauswertung feststellbar sein. Klassen fassen Operationen und Daten (Attribute) zusammen und verhindern zusätzlich den direkten Zugriff auf die Attribute. Dieses Konzept der Datenkapselung verbessert einige wichtige Qualitätseigenschaften (z. B. die Änderbarkeit), verschlechtert aber gleichzeitig die Beobachtbarkeit, die eine wesentliche Voraussetzung für die Fehlererkennung ist. Um diesem Problem zu begegnen, sind mehrere Ansätze vorgeschlagen worden. Insgesamt wird aber nur eine Reduktion der Probleme und keine vollständige Beseitigung erreicht. Die Beobachtbarkeit und damit auch die Testbarkeit objektorientierter Software ist aufgrund der Datenkapselung geringer als bei funktional strukturierter Software.

Zuerst die nicht-zustandsverändernden Operationen prüfen; danach die zustandsverändernden Operationen

Berard beschreibt in /Berard 93/ eine Strategie, die eine bestimmte Reihenfolge der Integration einzelner Operationen einer Klasse in Testfälle vorsieht, um dem Problem zu begegnen: Es sollen diejenigen Operationen zuerst überprüft werden, die nicht zustandsverändernd sind, die also auf die Attribute der Klasse nicht schreibend zugreifen. Hat man ein ausreichendes Vertrauen in die nicht-zustandsverändernden Operationen aufgebaut, so können die zustandsverändernden Operationen mit Hilfe der bereits getesteten Operationen geprüft werden. Fraglich bleibt allerdings, wie das korrekte Funktionieren der nicht-zustandsverändernden Operationen überprüft werden kann, ohne dabei die übrigen Operationen zu verwenden.

Formaler Korrektheitsbeweis

Eine weitere Möglichkeit ist die Durchführung eines formalen Korrektheitsbeweises für die Operationen, die keine Zustandsveränderungen durchführen, um anschließend die zustandsverändernden Operationen mit ihrer Hilfe zu prüfen. Da die nicht-zustandsverändernden Operationen in der Regel sehr einfach aufgebaut sind, können sie im allgemeinen leicht formal verifiziert werden.

Zusicherungen erhöhen die Beobachtbarkeit.

Die Formulierung von Zusicherungen, die während der Testdurchführung automatisch geprüft werden, bietet eine Möglichkeit zur Erhöhung der

412

13 Prüfen von objektorientierter Software

Beobachtbarkeit, da aufgetretene Fehlersituationen dem Bediener direkt gemeldet werden. Zusicherungen sind boolesche Ausdrücke mit deren Hilfe Aussagen über den derzeitigen Programmzustand formuliert werden können (z. B. x > 0). Sie können einerseits als Testhilfe die Beobachtbarkeit des Testlings während der Testdurchführung erhöhen und nach dem Test entfernt werden. Andererseits können sie in der ausgelieferten Software verbleiben und als Maßnahme zur gezielten Meldung von Fehlverhalten dienen (z. B. in sicherheitskritischen Anwendungen). Spezielle Zusicherungen sind die so genannten Vorbedingungen (Preconditions) und Nachbedingungen (Postconditions) sowie Schleifeninvarianten. Vorbedingungen spezifizieren die Voraussetzungen für die Ausführung einer Operation. Nachbedingungen beschreiben den Zustand nach der Ausführung einer Operation. Schleifeninvarianten stellen die Verarbeitung, die in einer betrachteten Schleife erfolgt, auf formale Weise dar. Die einfachste aber auch die unsauberste Lösung ist, Testcode und Testwerkzeugen den uneingeschränkten Zugriff auf alle Attribute zu gestatten. Dies ist ein in C++ üblicher Weg. Die zu testende Klasse deklariert eine Testklasse als friend und hebt damit die Datenkapselung für die Testklasse auf. Turner und Robson /Turner, Robson 93/ lehnen dieses Vorgehen jedoch ab, weil wiederum der Zugriffscode innerhalb der Testwerkzeuge fehlerhaft sein kann und somit das Problem lediglich von der zu testenden Klasse auf die Testumgebung verschoben wird.

13.3.2

Die Aufhebung der Datenkapselung ist kritisch.

Ein Ansatz für die Überprüfung von Klassen

Im Folgenden wird als Beispiel zur Erläuterung der Prüftechniken ein objektorientiert modellierter Getränkeautomat benutzt (Abb. 13.1).

Die Notation ist an die Unified Modeling Language (UML) /Booch et al. 98/ angelehnt. Folgende Klassen sind modelliert: >

die Getränkeautomaten-Steuerung,

>

die Kundenbedieneinheit,

>

die Servicebedieneinheit,

>

der Münzprüfer,

>

die Getränke- / Becher-Ausgabe,

>

der Rückgeldauszahler

13.3 Objektorientierter Modultest

BEISPIEL

413

Getränk_ausverkauft () Bechervorrat_leer ()

Abbildung 13.1 Ein objektorientiert modellierter Getränkeautomat (Ausschnitt)

Objekt = Datenabstraktion

Objekte gewöhnlicher Klassen bilden eine Datenabstraktion durch Zusammenfassen von Operationen und Attributen. Derartige Datenabstraktionen existieren bereits in klassischen Programmen. Oft ist es sinnvoll, Objekte als Zustandsautomaten zu betrachten. Die Werte der Attribute repräsentieren den aktuellen Zustand, der durch die auf den Attributen arbeitenden Operationen modifiziert wird. Ein Zustandsautomat, der diesen Sachverhalt für objektorientierte Software beschreibt, stellt die Ausführungssequenzen der Operationen und die daraus resultierenden Ergebnisse dar. Für das Testen von Zustandsautomaten sind Testverfahren bekannt, die hier benutzt werden können (siehe Kapitel 2). Die Wahl konkreter Testdaten kann mit Hilfe der funktionalen Äquivalenzklassenbildung geschehen, um sicherzustellen, dass alle wesentlichen Fälle berücksichtigt werden. Ergänzend sollte eine strukturorientierte Abdeckungsmessung durchgeführt werden. Die Teststrategie besteht also aus einem Zustandstest, der die zu testenden Operationense-

414

13 Prüfen von objektorientierter Software

quenzen festlegt, der funktionalen Äquivalenzklassenbildung zur Wahl konkreter Testdaten und einer Kontrolle der erreichten Abdeckung im Quellcode.

13.3.3

Funktionsorientierter Test

In der Regel besitzen funktionsorientierte Testverfahren geeignete Voraussetzungen für die Anwendung auf objektorientierte Software. Von besonderer Bedeutung ist der Test von Klassen bzw. Objekten auf Basis von Spezifikationen in Form von Zustandsautomaten. Objekte besitzen einen durch die Werte der Attribute repräsentierten Zustand, der durch Schreibzugriffe der Operationen verändert wird. Die Ausführungsreihenfolge von Operationen ist wichtig. Die zu testenden Operationensequenzen können durch Anwendung eines konventionellen zustandsorientierten Testverfahrens auf die Spezifikation eines Objekts in Form eines Zustandsautomaten ermittelt werden. Konkrete Testdaten können ergänzend durch eine herkömmliche funktionsorientierte Äquivalenzklassenbildung der Operationenschnittstellen erzeugt werden. Zur systematischen Entwicklung von Testfällen aus spezifisch objektorientierten Analyse- und Entwurfsdokumenten existieren jedoch nur wenige Ansätze (siehe z. B. /Jacobson et al. 92/, /Sneed, Winter 01/). 13.3.3.1

Der funktionsorientierte Test ist oft eine Kombination aus einem zustandsbasierten Test und der funktionsorientierten Äquivalenzklassenbildung.

Zustandsbasierter Test von Operationssequenzen

In Abb. 13.2 ist die Spezifikation der Klasse Getränkeautomaten-Steuerung in Form eines Zustandsautomaten dargestellt. Die Zustände sind mit Hilfe der zugehörigen Werte der lokalen Daten der Klasse – ihrer Attribute – bezeichnet.

Zustandsautomat als Spezifikation

Ein Zustandsübergang kann durch ein externes oder internes Ereignis ausgelöst werden. In Abb. 13.2 sind diese Ereignisse als Kantenbeschriftung vor dem Schrägstrich angegeben. Ein externes Ereignis ist z. B. der Empfang einer Botschaft. Nach dem Schrägstrich sind Aktionen notiert, die beim Zustandsübergang (auch zum identischen Folgezustand) ausgelöst werden. Dies können Modifikationen der Attribute der Objekte sein sowie Aktivierungen von lokalen Operationen der Objekte und das Versenden von Botschaften an andere Objekte. Man kann diese Aktionen als eine grobe Spezifikation der Operation verstehen, die durch das entsprechende Ereignis bezeichnet wird. So wird z. B. durch die Botschaft Getränk_wählen (G) die dazu passende Operation des Objekts Getränkeautomaten-Steuerung aktiviert. Diese muss den Wert G dem Attribut Gew_Getränk zuweisen. Ferner muss die Botschaft Preis_ermitteln (G) versandt, das Ergebnis in Preis gespeichert und durch Versenden der Botschaft Betrag_anzeigen (Preis) auf der Kundenbedieneinheit angezeigt werden.

13.3 Objektorientierter Modultest

415

Abbildung 13.2 Spezifikation der Klasse „Getränkeautomat-Steuerung“

Ein Testschritt umfasst Startzustand, Ereignis, Aktion und Folgezustand.

Ein Schritt eines Testfalls besteht bei Zugrundelegung einer zustandsorientierten Spezifikation also aus dem Eintritt eines Ereignisses in einem bestimmten Zustand, dem Auslösen von Aktionen und gegebenenfalls einem Zustandswechsel.

Minimalstrategie: Abdeckung aller Zustände

Eine akzeptierte minimale Teststrategie ist die mindestens einmalige Abdeckung aller Zustände durch Testfälle. Besser ist das mindestens einmalige Durchlaufen aller Zustandsübergänge, das die erstgenannte Forderung implizit ebenfalls erfüllt. Die Testfälle bestehen aus Ereignissequenzen und erwarteten Aktionen. Es werden keine einzelnen Operationen, sondern Operationensequenzen und ihre Wechselwirkungen über die Attribute getestet. Für die Erzeugung von Testfällen ist es wichtig zu wissen, welche Form der Beschreibung im Zustandsautomat gewählt worden ist.

WICHTIG: Art des Zustandsautomaten beachten (vgl. Kapitel 2)

In dem Beispiel nach Abb. 13.2 können offensichtlich Ereignisse auftreten, zu denen kein Zustandsübergang existiert. Es ist z. B. denkbar, dass die Getränkeautomaten-Steuerung im Zustand Getränk_gew eine Botschaft Geld_zurückgeben () empfängt, weil ein Kunde die Geldrückgabetaste betätigt hat. Da aber in diesem Zustand noch kein Geld eingegeben wurde, ist keine Reaktion notwendig. Die Botschaft kann ignoriert werden und ist daher im Zustandsautomat an dieser Stelle nicht als Kantenbeschriftung notiert. Der Eintritt von Ereignissen, zu denen keine Kantenbeschriftung existiert, ist kein Fehlerfall. Daneben existieren Zustandsautomaten, bei denen davon ausgegangen wird, dass Ereignisse, die nicht notiert sind, nicht auftreten dürfen. Der Eintritt eines Ereignisses, zu dem keine Kantenbeschriftung existiert, ist

416

13 Prüfen von objektorientierter Software

dann ein Fehlerfall. Diese Form der Beschreibung bietet im Unterschied zur zuvor beschriebenen Form des Automaten eine einfache Möglichkeit zur Erzeugung von Testfällen für Fehlersituationen. Die oben angegebenen zustandsorientierten Testfälle besitzen einen Freiheitsgrad in bezug auf die konkret zu wählenden Parameter. Um diese zu bestimmen, ist es sinnvoll, als zusätzliche Testtechnik die funktionsorientierte Äquivalenzklassenbildung zu verwenden. 13.3.3.2

Funktionsorientierte Äquivalenzklassenbildung für den Test von Operationen

Im Folgenden werden für die Operation Rückgeld_auszahlen () der Klasse Rückgeldauszahler funktionsorientierte Testfälle nach dem Verfahren der funktionsorientierten Äquivalenzklassenbildung erzeugt. Zur Klasse Rückgeldauszahler ist die folgende Spezifikation vorhanden: Die Klasse Rückgeldauszahler enthält die Information über die für die Rückgeldauszahlung verfügbaren Münzen nach Art und Anzahl. Insgesamt sind max. 50 Münzen à 2 e, 100 Münzen à 1 e, 100 Münzen à 0,50 e, 100 Münzen à 0,20 e und 200 Münzen à 0,10 e möglich. Kleinere Münzen als 0,10 e werden nicht verarbeitet. Die Operation Rückgeld auszahlen () ermittelt die Art und Anzahl der auszuzahlenden Münzen nach den folgenden Regeln:

Spezifikation der Klasse Rückgeldauszahler

Gezahlt wird mit der geringsten Anzahl Münzen, d. h. der Rückgeldbetrag wird zunächst gegebenenfalls mit 2 e-Münzen beglichen, dann mit 1 e-Münzen, anschließend mit 0,50 e-Münzen, 0,20 e-Münzen und 0,10 e-Münzen. Falls eine benötigte Münzsorte nicht mehr verfügbar ist, so wird mit der nächstkleineren Sorte zurückgegeben. Falls weniger als zwanzig 10-Cent-Münzen verfügbar sind, so wird die Botschaft Kein_Wechselgeld (ja) versandt, um die Passend zahlen-Anzeige zu aktivieren. Dies geschieht auch, wenn ein Gesamtbetrag des Wechselgelds mit Ausnahme der 2 e-Münzen von 5 e unterschritten wird. Sonst wird die Botschaft Kein_Wechselgeld (nein) versandt. Diese Beschreibung kann in die Äquivalenzklassenaufstellung nach Tab. 13.1 umgesetzt werden. Die Äquivalenzklassenaufstellung kann in die Testfälle nach Tab. 13.2 und 13.3 umgesetzt werden.

13.3.4

Strukturorientierter Test

Strukturorientierte Testtechniken benutzen Modelle der inneren Struktur des Testlings als Referenz. In bezug auf Software sind das z. B. Kontrollflussgraphen zur Darstellung der Kontrollstruktur, die – mit Datenflussattributen versehen – auch zur Beschreibung des Datenflusses ver-

13.3 Objektorientierter Modultest

417

Tabelle 13.1 Äquivalenzklassen der Methode „Rückgeld_auszahlen ()“

Tabelle 13.2 Testfälle (gültige Äquivalenzklassen)

Testfall-Nr.

7

8

9

10

11

12

13

14

15

16

17

Rückgeld

1

1€

1€

1€

1€

1€

1€

1€

1€

1€

-0,10 €

Münzvorrat 2

51

10

20

10

10

-1

20

30

20

14

10

1

10

20

10

10

10

-1

10

10

10

10

5

10

1

101

10

10

10

30

-1

22

24

10

2

10

1

10

101

9

10

40

2

-1

8

10

0,10 €

30

42

30

40

201

10

50

49

30

-1

50

Tabelle 13.3 Testfälle (ungültige Äquivalenzklassen)

wendet werden. Diese Testtechniken können prinzipiell auf jeden Testling angewendet werden, der durch die Modelle dargestellt werden kann. In der Praxis werden sie für die Überprüfung von Software verwendet. Man spricht dann z. B. von einem Zweigüberdeckungstest oder einem all defs-Test. Grundsätzlich existieren kaum Abhängigkeiten der Prüftechniken von einer bestimmten Art der Realisierung des Testlings. Daher können klassi-

418

13 Prüfen von objektorientierter Software

sche Prüfverfahren prinzipiell auch für objektorientierte Prüfungen eingesetzt werden. 13.3.4.1

Kontrollflussorientierter Test

Kontrollflussorientierte strukturelle Testverfahren besitzen bei der Überprüfung klassischer Software eine nennenswerte Verbreitung. Sie fordern die Überdeckung – den mindestens einmaligen Test – von Elementen der Kontrollstruktur (z. B. Anweisungen, Zweige, Bedingungen). Einerseits ist ihre Eignung für die Prüfung objektorientierter Software zweifelhaft, da die Kontrollstruktur einzelner Operationen innerhalb von Klassen üblicherweise wesentlich einfacher ist, als die Kontrollstruktur von Funktionen in imperativ implementierter Software. Darüber hinaus erschwert der von Meyer empfohlene Ansatz des Shopping-list approach /Meyer 88/ – Klassen umfassend wiederzuverwenden und wiederverwendbar zu erstellen – eine vollständige Überdeckung, da in der Regel nicht die gesamte Funktionalität einer wiederverwendeten, dienstanbietenden Klasse genutzt wird. Andererseits kann man davon ausgehen, dass ein Teil der in einer objektorientierten Sprache codierten Software komplizierte Operationen enthält, z. B. weil die Struktur nicht wirklich objektorientiert ist oder die Bereitstellung der Funktionalität komplizierte Verarbeitungslogik erfordert. In diesem Fall kann die Verwendung kontrollflussorientierter Testtechniken sinnvoll sein. Ein wesentlicher Teil der kommerziell verfügbaren Werkzeuge unterstützt kontrollflussorientierte Testtechniken. Daher wird man hier in der Regel eine kontrollflussorientierte Technik anwenden müssen. Diese ist oft nicht optimal geeignet, da z. B. eine Überdeckung aller Zweige der Kontrollstruktur einzelner Operationen leicht erreicht werden kann. Daraus folgt jedoch, dass nicht überdeckte Teile der Struktur auf Unzulänglichkeiten des durchgeführten funktionalen Tests hinweisen, da sie ja im Prinzip leicht getestet werden könnten. Im Folgenden wird als Beispiel eine mögliche Realisierung der Operation Rückgeld_auszahlen () in C++ verwendet:

int Rueckgeld_auszahlen (int Betrag) // Betrag in Cent // Zahlt Münzen aus; gibt Restbetrag zurück; // Meldet "‘Kein Wechselgeld"’, gibt im Fehlerfall -1 zurück { int Anz2, Anz1, Anz050, Anz020, Anz010 ; int Vorrat2, Vorrat1, Vorrat050, Vorrat020, Vorrat010; Vorrat2 = Euro2.Anzahl(); Vorrat1 = Euro1.Anzahl(); Vorrat050 = Euro050.Anzahl(); Vorrat020 = Euro020.Anzahl(); Vorrat010 = Euro010.Anzahl(); // Bereichsprüfung

13.3 Objektorientierter Modultest

Die Eignung kontrollflussorientierter Testtechniken für objektorientierte Software ist zweifelhaft.

OO-Testwerkzeuge unterstützen in der Regel kontrollflussorientierte Testtechniken.

BEISPIEL

419

if ((Betrag < 0) || (Vorrat2 < 0)|| (Vorrat1 < 0) || (Vorrat050 < 0) || (Vorrat020 < 0) || (Vorrat010 < 0)) return (-1); Anz2 = Betrag / 200; if (Anz2

1000

Der Wert 1000 wird eine Verletzung der Zusicherung der Operation Geld_eingeben () verursachen. Die Operation Geld_eingeben () ist so zu modifizieren, dass der Wert 1000 korrekt verarbeitet werden kann.

13.4.2.3

Integrationstest von Vererbung bei dienstnutzenden und dienstanbietenden Klassen

Die Voraussetzungen sind auch hier die ordnungsgemäße Durchführung des Modultests der einzelnen beteiligten Klassen und des Integrationstests der Basisklassen. Die Testdurchführung besteht in der Durchführung des Integrationstests von dienstanbietenden abgeleiteten Klassen und der Durchführung des Integrationstests von dienstnutzenden abgeleiteten Klassen wie oben beschrieben. Gegebenenfalls sind zusätzliche Testfälle für Wechselwirkungen zwischen der dienstanbietenden und der dienstnutzenden Unterklasse erforderlich.

13.4 Objektorientierter Integrationstest

Vererbung beim Dienstnutzer und Dienstanbieter

433

BEISPIEL

In dem erweiterten Getränkeautomaten nach Abb. 13.7 sind Beziehungen zwischen Unterklassen vorhanden, die zwischen ihren Oberklassen nicht vorhanden waren. Zwischen den durch Vererbung entstandenen Klassen Rückgeldauszahler_Banknotengerät und Münzprüfer/Banknotenleser besteht eine Dienstanbieter-Dienstnutzer-Beziehung. Zusätzlich zu den Testfällen, die man durch Anwendung der in den zwei vorangehenden Unterabschnitten beschriebenen Regeln erhält, ist diese durch Überprüfung der Interaktion durch die Botschaft Keine_Banknoten_akzeptieren () zu testen. Die zusätzlichen Testfälle sind: Keine_Banknoten_akzeptieren ( ja) Keine_Banknoten_akzeptieren (nein) Eine analoge Situation existiert zwischen den Klassen Rückgeldauszahler_Banknotengerät und Kundenbedieneinheit_Banknotengerät.

13.4.2.4 Ziel: Minimierung des Aufwands für Testsoftware

Integrationstest und Testumgebungen

Ein wichtiges generelles Ziel für den Integrationstest ist die Minimierung des Aufwandes zur Erstellung von zusätzlicher Testsoftware. Beim Test von objektorientierter Software wird vor allem für die Erstellung von Teststubs ein hoher Aufwand veranschlagt /Jüttner et al. 95/. Jüttner begründet dies damit, dass Teststubs bestimmte Zustände der simulierten Klasse annehmen können müssen und zyklische Abhängigkeiten zwischen simulierter und zu testender Klasse bestehen können. Oft wird deshalb ein Bottom up-Vorgehen für den objektorientierten Integrationsprozess vorgeschlagen. McGregor und Korson /McGregor, Korson 94/ schlagen vor, die Entwicklungskosten von Teststubs ganz einzusparen, indem an allen Anwendungsklassen gleichzeitig gearbeitet wird, so dass statt eines Teststubs die jeweilige Anwendungsklasse beim Test zum Einsatz kommt. Nachteil dieser als Wave-Front-Integration bezeichneten Vorgehensweise liegt in dem höheren Kommunikationsaufwand der Software-Entwickler. Strategien zur Minimierung der Verwendung von Teststubs beim Integrationstest finden sich in /Overbeck 94/, /Overbeck 95/, /Kung et al. 95/ sowie /Jüttner et al. 95/. Die Implementierung von Testtreibern wird demgegenüber als wesentlich einfacher eingestuft. Es gibt bereits einige Ansätze für deren Implementierung und Generierung /Doong, Frankl 91/, /Doong, Frankl 94/, /Hoffman, Strooper 95/, /Hunt 96/. Ein interaktionsbasiertes Vorgehen zur Ermittlung einer Interaktionsstrategie wird in /Winter 00/ beschrieben.

434

13 Prüfen von objektorientierter Software

13.5

Objektorientierter Systemtest

Der Systemtest betrachtet die Software als „schwarzen Kasten“. Es ist prinzipiell unerheblich, ob das System intern objektorientiert oder klassisch aufgebaut ist. In bezug auf die Aufgaben und Ziele gibt es daher keine Unterschiede des objektorientierten Systemtests gegenüber dem Test klassischer Software. Darüber hinaus sind die Techniken des Systemtests stets auf hybride Systeme aus Software und Hardware anwendbar. Der Systemtest ist der Test der fertigen Software gegen die in der Anforderungsdefinition festgelegten Funktions-, Leistungs- und Qualitätsanforderungen. In Frage kommen Testfälle aus der Anforderungsdefinition, echte oder typische Daten, mit denen die Software im laufenden Betrieb versorgt wird, aber auch Erfahrungswerte und kritische Daten. Ein Test unter den realen Einsatzbedingungen mit der realen Konfiguration ist erwünscht. Neben der Qualitätssicherungsabteilung werden oft Benutzer oder andere Spezialisten teilnehmen. Im Systemtest können die Tätigkeiten Funktionstest, Leistungstest, Stresstest, Regressionstest und Beta-Test unterschieden werden.

Der Systemtest ist ein Black Box-Test

Der Funktionstest überprüft, ob alle definierten Funktionen vorhanden und wie vorgesehen implementiert sind. Als Referenz dient die Anforderungsdefinition, aus der systematisch und vollständig mit Hilfe von funktionsorientierten Testtechniken die Testfälle hergeleitet werden. Hier existieren Unterschiede zu klassischen Systemen, da die verwendeten funktionsorientierten Testtechniken zu der objektorientiert erstellten Anforderungsdefinition passen müssen. Entsprechende Ansätze sind z. B. in /Jüttner et al. 95/, /Jorgenson, Erickson 94/, /McGregor, Korson 94/, /Poston 94/ beschrieben.

Funktionstest

Als Basis für die Erzeugung funktionsorientierter Testfälle aus objektorientierten Analyse-Diagrammen bietet sich je nach verwendeter OOATechnik die Nutzung von Datenflussdiagrammen, Zustandsautomaten, Sequence Charts oder der so genannten Use Cases an. Use Cases sind Szenarien der Verwendung eines Systems aus der Sicht eines Benutzers. Das kann ein Mensch oder anderes System sein. Use Cases sind nicht sehr systematisch. Insbesondere kann keine Vollständigkeit bei komplizierten Systemen erwartet werden. Eine relativ systematische Notation für Use Cases bieten die so genannten Sequence Charts, die gegebenenfalls zusätzlich mit Zeitbedingungen versehen werden können. Sequence Charts sind im Wesentlichen identisch mit den zur Spezifikation von Datenübertragungsprotokollen oft verwendeten Transaktionsflussdiagrammen. Es können zwei unterschiedliche systematische Notationen unterschieden werden: >

Lineare Sequenzen in zeitlicher Abfolge (Timethreads),

>

Baumförmige Darstellung der Szenarien (im Sinne eines Entscheidungsbaums).

13.5 Objektorientierter Systemtest

Nutzung von Use Cases

435

Die lineare Darstellung ist Transaktionsflussdiagrammen sehr ähnlich. Dies ist vorteilhaft, da Testtechniken für Transaktionsflussdiagramme existieren. Ferner ist das Aufstellen linearer Sequenzen einfacher und klarer als die Notation in Form von Bäumen. Weil eine Sequenz eine von vielen möglichen Systembenutzungen darstellt, besitzt sie Beispielcharakter. Da Vollständigkeit aber gar nicht erst angestrebt wird, können insbesondere unsinnige Fälle vermieden werden. Die baumartige Notation strebt eine eingeschränkte Vollständigkeit an, da bei jedem Schritt der Erstellung jeweils die Aufmerksamkeit auf eine bestimmte Situation und die möglichen Entscheidungen des Benutzers fokussiert wird. Weil alle Fälle betrachtet werden, sind oft unsinnige Fälle enthalten. Ferner werden die Bäume häufig umfangreich, so dass man sich bemühen muss, sie hierarchisch zu strukturieren. Grundsätzlich besitzt diese Vorgehensweise starke Ähnlichkeiten zur Aufstellung eines Entscheidungstabellenverbunds. Für Entscheidungstabellen sind ebenfalls Testtechniken bekannt, die verwendet werden können. In /Jüttner et al. 95/ und /Jorgenson, Erickson 94/ wird eine zusätzliche Testphase zwischen Integrationstest und Systemtest vorgeschlagen. In dieser Testphase soll das Gesamtsystem unter Berücksichtigung interner Systemzustände getestet werden. In /McGregor, Korson 94/ werden zusätzliche Testfälle zur Überprüfung der Erweiterbarkeit des Systems gefordert. In /Poston 94/ wird ein Werkzeug zur automatischen Testfallgenerierung anhand von OMT-Dokumenten /Rumbaugh et al. 91/ vorgestellt.

436

WICHTIG: Regressionstest

Im Falle von Versionsentwicklungen eines Software-Systems, aber auch im Falle neuer Versionen als Folge notwendiger Fehlerkorrekturen ist ein Regressionstest erforderlich. Dieser besteht in der Wiederholung der bereits durchgeführten Testfälle und dient dazu, festzustellen, ob die bereits getestete Funktionalität noch wie zuvor erbracht wird. Das Ziel ist, Seiteneffekte von Erweiterungen der Funktionalität und von Fehlerkorrekturen aufzudecken. Regressionstests sind möglichst zu automatisieren und zwar einschließlich des Soll-/Ist-Ergebnisvergleichs.

Leistungstest

Leistungstests dienen zur Überprüfung des in der Anforderungsdefinition festgelegten Leistungsverhaltens. Dies betrifft sowohl die verarbeitbaren Mengen – z. B. Anzahl angeschlossener Sensoren – als auch das Antwortzeitverhalten. Leistungstests betreiben die Software an der Grenze der verkraftbaren Last, ohne diese Grenze zu überschreiten. Die Software muss bei Leistungstests folglich ein normales Verhalten zeigen. Der Test des Zeitverhaltens kann z. B. gegen entsprechend annotierte Use Cases durchgeführt werden. Eine Besonderheit objektorientiert programmierter Software ist das so genannte dynamische Binden, das die garantierte Einhaltung oberer Zeitschranken erschwert. In der Regel wird dynamisches Binden bei zeitkritischen Abläufen verboten. Dies kann sinnvoll durch ein Review der betroffenen Klassen geprüft werden. Das gehört allerdings in den Bereich des objektorientierten Komponententests.

13 Prüfen von objektorientierter Software

Beim Stresstest werden die Grenzen der verkraftbaren Last gezielt überschritten, während der Software bzw. dem System gleichzeitig die erforderlichen Ressourcen entzogen werden. Eine typische Testsituation ist die Messung des Antwortzeitverhaltens einer sicherheitskritischen als Mehrprozessorsystem aufgebauten Steuerung bei Überlast und Ausfall eines Prozessors. Hier sollen Fragen beantwortet werden, wie z. B.: Wie verhält sich ein System nach einer aufgetretenen Überlast, wenn die Last in den normalen Bereich zurückgeht? Stresstests erfordern in der Regel eine geeignete Werkzeugunterstützung, um Last zu simulieren. Regressionstestwerkzeuge enthalten oft derartige Stresstestkomponenten.

Stresstest

Der Beta-Test besteht in der Installation der Software bei einigen speziell ausgewählten Pilotkunden, mit dem Ziel noch vorhandene Fehler zu erkennen und abzustellen, bevor die Software in größerer Stückzahl in den Markt gebracht wird.

Beta-Test

13.6

Bewertung des Prüfens von objektorientierter Software

Objektorientierte Analyse- und Entwurfstechniken sowie objektorientierte Programmiersprachen sind auf dem Vormarsch. Daher sind entsprechende Prüfstrategien notwendig. Die kleinste unabhängig testbare Einheit in der objektorientierten Software-Entwicklung ist in der Regel ein Objekt als Instanz einer Klasse. Klassen können oft geeignet mit Hilfe von Zustandsautomaten spezifiziert werden. Daher ist der zustandsautomatenbasierte Test oft eine geeignete Testtechnik. Testen auf Basis von Zustandsautomaten liefert als Testfälle die zu prüfenden Operationssequenzen. Für die Ermittlung der Schnittstellenparameter der Operationen bietet sich die funktionsorientierte Äquivalenzklassenbildung an. Es ist zu erwarten, dass kontrollflussorientierte Testtechniken – z. B. der Zweigüberdeckungstest – in der objektorientierten Software-Entwicklung ungeeigneter sind als in der klassischen Software-Entwicklung. Datenflussorientierte Testtechniken berücksichtigen die Struktur objektorientierter Software insbesondere innerhalb von Klassen besser als kontrollflussorientierte Testtechniken. Für datenflussorientiertes Testen existieren aber kaum praxisgeeignete Werkzeuge. Daher wird man in der Regel auf kontrollflussorientierte Testtechniken, insbesondere auf den Zweigüberdeckungstest, zurückgreifen müssen. Der Integrationstest kann insbesondere bei Versionsentwicklungen von den in der objektorientierten Entwicklung explizit vorliegenden Vererbungsstrukturen profitieren. In vielen Fällen können Testfälle aus der Vorläuferversion wiederverwendet werden. Der Testplanungsaufwand kann so deutlich reduziert werden. Falls die Testfälle automatisch wiederholt werden können – z. B. mit einem Regressionstestwerkzeug – so ergibt sich eine weitere Reduktion des Aufwands für den Integrationstest. Mit Ausnahme der Berück-

13.6 Bewertung des Prüfens von objektorientierter Software

437

sichtigung objektorientierter Spezifikationen gibt es im objektorientierten Systemtest wenig Unterschiede zu dem Systemtest funktional dekomponierter Software. Bei der objektorientierten Programmierung sollten unbedingt Zusicherungen verwendet werden. Sie erhöhen die in der Objektorientierung schlechte Beobachtbarkeit von Klasseninterna, ohne das Kapselungsprinzip zu durchbrechen.

CHECKLISTE

438

>

Verwenden Sie Zusicherungen. Sinnvoll ist, mindestens die Angabe von Eingangszusicherungen, Ausgangszusicherungen und Schleifen- invarianten vorzusehen.

>

Falls Sie eine objektorientierte Entwurfsmethodik verwenden, die Zustandsautomaten als Beschreibungsmittel für das Verhalten von Klassen enthält, so sollten Sie über die Verwendung einer zustandsbasierten Testtechnik nachdenken.

>

Die funktionsorientierte Äquivalenzklassenbildung ist eine geeignete Testtechnik für den Test von Operationen und für den Integrationstest. Sie sollten diese Technik daher systematisch anwenden.

>

Falls Sie ein datenflussorientiertes Testwerkzeug finden sollten, das zu den Rahmenbedingungen ihrer Entwicklung passt, so sollten Sie über dessen Einsatz nachdenken. Alternativ bietet sich die Nutzung eines Werkzeugs an, das eine kontrollflussorientierte Testtechnik, z. B. den Zweigüberdeckungstest, unterstützt. Sie sollten die Ergebnisse eines Zweigüberdeckungstests in der objektorientierten Software-Entwicklung vorsichtig beurteilen, da der Wert einer vollständigen Zweigüberdeckung in der objektorientierten Welt oft geringer ist als in der klassischen Software-Entwicklung.

13 Prüfen von objektorientierter Software

14 Prüfen von eingebetteter Software Viele technische Systeme – z. B. in der Medizintechnik, der Verkehrstechnik und der Automatisierungstechnik – sind ohne Software undenkbar /Liggesmeyer, Rombach 05/. In der Regel fordert man für derartige Systeme eine hohe Zuverlässigkeit und Verfügbarkeit. Darüber hinaus können Systeme Gefährdungen verursachen. Diese führen zu Sicherheitsanforderungen, die bei einigen Systemen Zulassungen durch unabhängige Prüfstellen erfordern. Für kritische Anwendungsbereiche werden häufig quantifizierte Aussagen zu Qualitätsmerkmalen gefordert. Für Hardware ist das durchaus üblich; für Software nicht. Im Folgenden werden Verfahren für die Prüfung eingebetteter Software beschrieben. Neben dynamischen Testtechniken besitzen Sicherheits- und Zuverlässigkeitsmodelle und statistische Analysetechniken eine hohe Bedeutung. Diese Techniken dienen zur systematischen quantitativen Bewertung der Qualitätseigenschaften Sicherheit, Zuverlässigkeit und Verfügbarkeit.

Übersicht 14.1

Eigenschaften und Ziele des Prüfens von eingebetteter Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

14.2

Wichtige Eigenschaften von eingebetteter Software . . . . . . . . 440

14.3

Dynamisches Testen von sicherheitskritischer Software . . . . . 443

14.4

Sicherheits- und Zuverlässigkeitsmodellierung . . . . . . . . . . . . . 445

14.5

Stochastische Software-Zuverlässigkeitsanalyse . . . . . . . . . . . . 453

14.6

Bewertung des Prüfens von eingebetteter Software . . . . . . . . 478 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

439

14.1

Korrektheitsmängel erzeugen Risiken

Funktionale vs. nichtfunktionale Qualitätseigenschaften

Sicherheit = Abwesenheit von Risiko

440

Eigenschaften und Ziele des Prüfens von eingebetteter Software

Selbstverständlich ist ein Ziel des Prüfens von eingebetteter Software die Kontrolle des Qualitätsmerkmals Korrektheit. Einerseits unterscheidet sich dies nicht wesentlich von der Prüfung „konventioneller“, nicht eingebetteter Software. Andererseits existieren für eingebettete Software oft höhere Anforderungen an die Korrektheit, weil Fehler Risiken verursachen können. Ungeachtet dieses Zusammenhangs zwischen dem Qualitätsmerkmal Korrektheit einerseits und den Qualitätsmerkmalen Sicherheit, Zuverlässigkeit und Verfügbarkeit andererseits, ordnet man die genannten Qualitätsmerkmale oft zwei unterschiedlichen Gruppen zu. Man unterscheidet funktionale und nicht-funktionale Qualitätseigenschaften. Dynamisches Testen zielt auf die Prüfung der korrekten Funktion. Ein vollständiger Korrektheitsnachweis kann durch dynamisches Testen nicht erreicht werden. Wenn ein vollständiger Korrektheitsnachweis gefordert ist, so müssen formale Beweistechniken eingesetzt werden. Formale Beweise haben daher bei sicherheitskritischer, eingebetteter Software eine gewisse Verbreitung. Für Sicherheits-, Zuverlässigkeitsund Verfügbarkeitsuntersuchungen werden spezielle Techniken eingesetzt, deren Ziele z. B. das Aufspüren von Risiken oder die Ermittlung von Zuverlässigkeitskennwerten sind. Es werden modellierende und messende Techniken unterschieden. Die messenden Techniken erfordern in der Regel eine stochastische Analyse der Messwerte. Modellierungstechniken können zu einem frühen Zeitpunkt – vor der Realisierung – Probleme identifizieren. Die Qualität der Ergebnisse wird entscheidend von der Qualität des Modells beeinflusst. Die Erstellung eines präzisen Modells ist gegebenenfalls aufwändig. Stochastische Analysen erfordern in der Regel keine Modellerstellung. Darüber hinaus liefern sie verlässliche Ergebnisse, da sie auf Messungen basieren. Nachteilig ist, dass die Realisierung soweit vorangeschritten sein muss, dass Messungen möglich sind. Werden hier gravierende Probleme erkannt, so sind gegebenenfalls nennenswerte Modifikationen erforderlich.

14.2

Wichtige Eigenschaften von eingebetteter Software

14.2.1

Sicherheitskritikalität

Die Norm IEC 61508 /IEC 61508 98/ definiert Sicherheit als die Abwesenheit unakzeptabler Risiken. Bemerkenswert ist, dass Sicherheit entsprechend dieser Norm nicht die Abwesenheit von Risiko ist. Vielmehr muss das Restrisiko auf einen annehmbaren Wert begrenzt sein. Dies wirft unmittelbar die Frage auf: „Wie hoch ist ein annehmbares Restrisiko?“

14 Prüfen von eingebetteter Software

/Birolini 97/ definiert Sicherheit als Maß für die Fähigkeit einer Betrachtungseinheit, weder Menschen, Sachen noch die Umwelt zu gefährden. Man unterscheidet die Sicherheit eines ausfallfreien Systems (Unfallverhütung) von der technischen Sicherheit des ausfallbehafteten Systems. Die angegebenen Definitionen betrachten Sicherheit stets im Zusammenhang mit Gefährdungen. Im englischen Sprachraum wird für diese Eigenschaft der Begriff safety verwendet. Darüber hinaus existiert die Eigenschaft security, die mit Datensicherheit übersetzt werden kann. Sie erfasst die Eigenschaft eines Systems, Informationsverluste und unbefugten Datenzugriff zu verhindern. Für safety ist die Gefährdung von Personen durch ein betrachtetes System relevant, während für security die Gefährdung eines Systems durch Personen („Hacker“) entscheidend ist. Im Folgenden wird im Wesentlichen safety betrachtet.

Sicherheit vs. technische Sicherheit

Safety = Fähigkeit einer Betrachtungseinheit, nur hinreichend kleine Gefährdungen zu verursachen Security = Datensicherheit

Software ist inhärent sicher im Sinne von safety. Solange die Software quasi als „reines Software-Produkt“ – d. h. ohne direkte Ankopplung an einen technischen Prozess – auf einem Computer abläuft geht von ihr keine Gefährdung aus. Ein Textverarbeitungsprogramm ist ein Beispiel für ein derartiges Software-Produkt. Ein Beispiel für sicherheitskritische Software ist die Turbinensteuerung eines Verkehrsflugzeugs. Hier „erbt“ die Software ihre Sicherheitskritikalität von ihrem technischen Kontext. Die Bewertung der Sicherheitskritikalität einer Software erfordert daher Kenntnisse über ihre Einsatzumgebung. Diese definiert die möglichen Konsequenzen einer Fehlfunktion der Software. Die Sicherheitskritikalität wird in der Regel durch Einordnung in eine von mehreren Kritikalitätsstufen bewertet. Die Kritikalitätsstufen sind in den unterschiedlichen Anwendungsbereichen unterschiedlich definiert. Sie folgen aber insgesamt der Regel: Je größer die möglichen Auswirkungen eines Fehlverhaltens der Software sind, umso sicherheitskritischer ist die Software. Die Turbinensteuerung eines Verkehrsflugzeugs ist daher deutlich sicherheitskritischer als die Software, die die Leselampen des gleichen Flugzeugs steuert.

„Reine“ Software ist sicher.

Es ist eigentlich nicht korrekt, von sicherheitskritischer Software zu sprechen, da Sicherheitskritikalität eine Eigenschaft eines Hardware-/Software-Systems ist. Die Sicherheitskritikalität einer Software ist ohne ihren Nutzungskontext nicht definiert.

Die Bewertung der Sicherheitskritikalität erfordert Kontextwissen.

14.2.2

Eingebettete Software kann sicherheitskritisch sein.

Zuverlässigkeit und Verfügbarkeit

Für Zuverlässigkeit existieren mehrere genormte Definitionen und zahlreiche Definitionen in der Fachliteratur. Die DIN EN ISO 9000 /DIN EN ISO 9000 05/ definiert Zuverlässigkeit als Sammelbegriff zur Beschreibung der Verfügbarkeit und ihrer Einflussfaktoren Funktionsfähigkeit, Instandhaltbarkeit und Instandhaltungsbereitschaft. Dies ist eine Definition, die recht umfassend ist. Im Deutschen verwendet man für diese

14.2 Wichtige Eigenschaften von eingebetteter Software

Verlässlichkeit (Dependability) vs. Zuverlässigkeit (Reliability)

441

Eigenschaft oft den Begriff „Verlässlichkeit“; im Englischen ist „Dependability“ üblich. Zuverlässigkeit ist eine stochastische Eigenschaft.

Die Norm DIN 40041 /DIN 40041 90/ definiert Zuverlässigkeit als Teil der Qualität im Hinblick auf das Verhalten der Einheit während oder nach vorgegebenen Zeitspannen bei vorgegebenen Anwendungsbedingungen. Für diesen Zuverlässigkeitsbegriff im engeren Sinne wird im Englischen der Begriff reliability verwendet. Sie ist ein Maß für die Fähigkeit einer Betrachtungseinheit, funktionstüchtig zu bleiben, ausgedrückt durch die Wahrscheinlichkeit, dass die geforderte Funktion unter vorgegebenen Arbeitsbedingungen während einer festgelegten Zeitdauer ausfallfrei ausgeführt wird. Diese Definition gestattet eine Beschreibung der Zuverlässigkeit mit Hilfe stochastischer Techniken. So kann der Erwartungswert für die Zeitspanne bis zum Ausfall eines Systems – die so genannte Mean Time to Failure (MTTF) – angegeben und als Zuverlässigkeitsmaß verwendet werden. Bei reparierbaren Systemen verwendet man den Erwartungswert der Zeitspanne zwischen zwei aufeinander folgenden Ausfällen – die so genannte Mean Time between Failure (MTBF). Alternativ kann die Überlebenswahrscheinlichkeit R(t) verwendet werden. Sie gibt die Wahrscheinlichkeit an, ein System, das zum Zeitpunkt Null in Betrieb genommen wurde, zum Zeitpunkt t noch intakt anzutreffen. Im Folgenden wird Zuverlässigkeit im letztgenannten, engeren Sinne verwendet. Zuverlässigkeit ist eine mit Mitteln der Stochastik beschreibbare Eigenschaft. Sie ist im allgemeinen nicht konstant, sondern wird bei Software im Zuge der mit Fehlerkorrekturen einhergehenden Zunahme der Stabilität größer sowie durch neue Fehler im Rahmen von Funktionalitätserweiterungen kleiner. Bei Hardware-Komponenten sind Einflüsse des Verschleißes zu beachten. Die beobachtete Zuverlässigkeit wird ferner durch die Art der Benutzung eines Systems bestimmt. Es ist oft möglich, Zuverlässigkeitsprognosen mit statistischen Verfahren zu erzeugen.

Verfügbarkeit

MTBF und MTTR

442

Verfügbarkeit ist ein Maß für die Fähigkeit einer Betrachtungseinheit, zu einem gegebenen Zeitpunkt funktionstüchtig zu sein. Sie wird ausgedrückt durch die Wahrscheinlichkeit, dass die Betrachtungseinheit zu einem gegebenen Zeitpunkt die geforderte Funktion unter vorgegebenen Arbeitsbedingungen ausführt. Als Maß für Verfügbarkeit kann der Quotient MT BF MT BF + MT T R verwendet werden. Der Wert dieses Quotienten kann auf zwei Arten gesteigert werden. Man kann die MTBF vergrößern, also die Zuverlässigkeit erhöhen, oder die MTTR (Mean Time to Repair) verringern, also die Stillstandszeitintervalle nach Ausfällen verkürzen. Während die Steigerung der MTBF auch auf die Zuverlässigkeit wirkt, beeinflusst die Verringerung der MTTR nur die Verfügbarkeit. Beide Eigenschaften sind für Software, Hardware und Hardware-/Software-Systeme definiert.

14 Prüfen von eingebetteter Software

14.2.3

Echtzeitfähigkeit

Echtzeitfähigkeit ist eine charakteristische Eigenschaft reaktiver Systeme. Man findet häufig eine Unterscheidung von „harter“ und „weicher“ Echtzeitfähigkeit . Bei der harten Echtzeitfähigkeit sind Reaktionen, die zu spät erfolgen, nicht korrekt. Sie haben die gleiche Wirkung wie eine rechtzeitige, aber falsche Reaktion. Bei der weichen Echtzeitfähigkeit sind verspätete Reaktionen störend; sie führen aber nicht unmittelbar zu kritischen Situationen.

Harte vs. weiche Echtzeitfähigkeit

Die Erfüllung von Zeitbedingungen wird oft als nicht-funktionale Qualitätseigenschaft eingestuft. Bei nicht-reaktiven Systemen (z. B. in der kaufmännischen Datenverarbeitung) ist das sinnvoll, da in der Regel keine harten Zeitschranken für Antwortzeiten existieren. Die Einhaltung von Zeitbedingungen ist bei derartigen Anwendungen ein Aspekt der Benutzungsfreundlichkeit („weiche Echtzeitfähigkeit“). Im Gegensatz dazu ist bei technischen Systemen (z. B. Steuerungssystemen) die Nichteinhaltung von Zeitschranken kritisch, da z. B. Instabilitäten auftreten können. Die Auswirkungen einer nicht rechtzeitigen Reaktion sind dann vergleichbar mit denen eines falschen Ausgabewertes, so dass die Erfüllung von Zeitbedingungen als funktionale Qualitätseigenschaft betrachtet wird („harte Echtzeitfähigkeit“).

14.3

Dynamisches Testen von sicherheitskritischer Software

Einerseits passen die Eigenschaften formaler Beweisverfahren besser zu den Anforderungen des Prüfens sicherheitskritischer Software. Andererseits sind dynamische Testverfahren – ungeachtet der bekannten Nachteile – in der Praxis weit verbreitet. Es ist nicht zu erwarten, dass sich dies in absehbarer Zeit ändern wird. Nachteilig ist insbesondere der Stichprobencharakter aller dynamischer Testtechniken, der einen Nachweis der Korrektheit unmöglich macht. Tatsächlich ist die Stichprobe der möglichen Betriebssituationen, die beim Testen als Testfallmenge ausgeführt wird, im Normalfall sehr klein im Verhältnis zur Menge der möglichen Fälle.

Nachteil: Stichprobencharakter

Diesem auf den ersten Blick gravierenden Nachteil stehen einige ebenso wichtige Vorteile gegenüber. Die Erfahrung zeigt, dass man durch systematisches, sorgfältig konzipiertes Testen hinreichend fehlerarme Software erreichen kann. Ferner ist es durch Anwendung statistischer Testverfahren in Kombination mit statistischen Modellierungsansätzen (siehe Abschnitt 14.5) möglich, abgesicherte, quantifizierte Aussagen über die Zuverlässigkeit zu erzeugen. Testen kann in der realen Betriebsumgebung durchgeführt werden, was die Erkennung einiger Probleme gestattet, die z. B. durch formale Be-

14.3 Dynamisches Testen von sicherheitskritischer Software

Vorteile: Beachtung der Betriebsumgebung, Zeitmessungen, Skalierbarkeit 443

weistechniken nicht erkannt werden. Dies sind z. B. Compilerfehler, Schnittstellenprobleme, Zeitverhalten und Kommunikationsprobleme mit der Hardware. Testen ist insbesondere der einfachste Weg zur Beurteilung von Zeitbedingungen. Ein Testfall ist ein Stellvertreter einer realen Betriebssituation. Daher ist das Vertrauen, das durch einen erfolgreich absolvierten Testfall in bezug auf die korrekte Funktion des Systems im realen Betrieb entsteht, sehr hoch. Niemand wird eine formal verifizierte Software ausliefern, ohne mindestens einige Testfälle durchzuführen. Die rationale Ursache für dieses Verhalten ist die Möglichkeit, dass Fehler der genannten Kategorien enthalten sind, die durch dynamisches Testen erkannt werden können. Hinzu kommt, dass man sehen möchte, wie das System funktioniert. Und auch das kann nur mit Hilfe dynamischen Testens geschehen. Ein weiterer Vorteil des dynamischen Tests ist seine unkomplizierte Skalierbarkeit. Während ein formaler Korrektheitsbeweis stets vollständig durchgeführt werden muss, kann dynamisches Testen ohne vollständigen Verlust des Ergebnisses abgebrochen werden. Diese Flexibiltät ist in der praktischen Anwendung einer Technik außerordentlich wichtig. Dynamisches Testen wäre geeigneter, wenn es vollständige Aussagen liefern könnte, wenn es abgesicherte Aussagen zur Qualität erzeugen könnte und wenn es systematischer und reproduzierbarer wäre. Mit Ausnahme der ersten können alle diese Forderungen erfüllt werden. Vollständigkeit kann angenähert werden.

Der Back to Back-Test ist für eingebettete Software oft sinnvoll.

444

Die Vollständigkeit wird durch eine sorgfältige, systematische Auswahl der Testfälle angenähert, die sicherstellt, dass die Testfälle möglichst gute Stellvertreter der möglichen Betriebssituationen sind. Diese Systematik stellt gleichzeitig eine gewisse Reproduzierbarkeit der Testvorgehensweise sicher. Die Reproduzierbarkeit des Qualitätsnachweises gelingt durch automatisierte Regressionstests, die eine neue Version der Software gegen das Verhalten der Vorläuferversion testen. Abgesicherte Aussagen zur Qualitätseigenschaft Zuverlässigkeit können, wie bereits erwähnt, durch statistische Verfahren gewonnen werden. Für den Test sicherheitskritischer Software können die in den Kapiteln 2 bis 5 beschriebenen dynamischen Testtechniken verwendet werden. Der Back to Back-Test ist besonders auf die spezifischen Eigenschaften von sicherheitskritischer Software zugeschnitten. Er ist wirtschaftlich einsetzbar, falls hohe Anforderungen an die Korrektheit und Zuverlässigkeit vorhanden sind und eine automatische Beurteilung der Ausgaben des Testlings erforderlich und möglich ist. Insbesondere in technischen Steuerungsanwendungen ist dies oft erfüllt. Der Signalcharakter der Eingaben und Ausgaben erschwert eine manuellen Ergebnisbeurteilung. Das mit Fehlverhalten verbundene Gefährdungspotential rechtfertigt den Mehraufwand für die mehrfache Codierung der üblicherweise nicht sehr umfangreichen sicherheitskritischen Routinen. Da der Back to Back-Test keine Forderungen an die Auswahl der Testdaten stellt, kann dieser Freiheitsgrad sinnvoll genutzt werden. Möglich ist z. B. ein statistischer Test

14 Prüfen von eingebetteter Software

entsprechend des Benutzungsprofils, mit dessen Hilfe quantifizierte Aussagen zur Zuverlässigkeit erzeugt werden können. Ferner existieren Testtechniken für technische Software, die an spezifische Voraussetzungen gebunden sind. /Watkins 82/ beschreibt eine Technik, die eine Automatisierung des Tests von Steuerungssoftware gestattet. Diese Technik kann nur eingesetzt werden, falls die Software in einen Regelkreis eingebunden ist und hinreichend Funktionen berechnet. Beim Hardware-in-the-Loop-Testen wird die vom Prüfling verwendete Umgebung weitgehend simuliert /Hörcher 99/, /Peleska, Zahlten 99/. Neben dem zu prüfenden System wird daher mindestens ein weiterer Computer beim Test verwendet, der den Test steuert. Die Simulation der Umgebung des zu testenden Systems bietet insbesondere die Möglichkeiten, Beobachtungspunkte zu nutzen, die in der realen Umgebung nicht zugänglich sind. Darüber hinaus wird durch die Testablaufsteuerung sichergestellt, dass die Simulationen in einem festen Zeittakt ausgeführt werden. Das ist eine wichtige Voraussetzung zur Validierung der Echtzeitfunktionen. Die Simulation gestattet insbesondere die automatisierte Durchführung komplexer Abläufe. So ist es z. B. möglich, Hardwareausfälle durch die elektronische Abschaltung von Schnittstellen zu simulieren.

14.4

Sicherheits- und Zuverlässigkeitsmodellierung

14.4.1

Eigenschaften und Ziele der Sicherheits- und Zuverlässigkeitsmodellierung

Modellierende Techniken können Probleme vorausschauend aufspüren. Es handelt sich um präventive Ansätze. Leider ist die Verlässlichkeit der Ergebnisse nur so groß, wie die Übereinstimmung zwischen dem Modell und der Realität. Für Sicherheitsnachweise und Zuverlässigkeitsermittlungen technischer Systeme und Anlagen werden in der Praxis verbreitet die Techniken FMECA (Failure Mode, Effects and Criticality Analysis) /DIN EN 60812 06/, /IEC 60812 06/, Zuverlässigkeitsblockdiagramm /IEC 61078 06/, Fehlerbaumanalyse /DIN 25424 90/, /IEC 61025 06/ und Markov-Analysen /IEC 61165 06/ genutzt. Die Anwendung dieser Techniken fordert Erfahrung und eine genaue Kenntnis des Systems. Die FMECA dient zur Identifikation und Priorisierung von Risiken sowie zum Finden von Abhilfemaßnahmen. Im Grunde handelt es sich bei der FMECA um eine auf Risiken fokussierte Inspektionstechnik. Ein wichtiges Ziel bei der Durchführung einer FMECA ist die Erreichung von Vollständigkeit. Es sollen möglichst keine gravierenden Risiken übersehen werden. Die FMECA liefert nicht wirklich Ausfallwahrscheinlichkeit. Vielmehr werden die Risiken auf einer Ordinalskala in eine Reihenfolge gebracht, um

14.4 Sicherheits- und Zuverlässigkeitsmodellierung

Hardware-in-theLoop-Test

Vorteil: Prävention Nachteil: Modellierungsaufwand und Fehler des Modells

FMECA

445

die besonders schwerwiegenden Risiken zu identifizieren und mit Priorität zu bearbeiten. Zuverlässigkeitsblockdiagramm

Zuverlässigkeitsblockdiagramme liefern quantifizierte Zuverlässigkeitsaussagen. Aus den Zuverlässigkeiten der Module und der Architektur des Systems können Zuverlässigkeitsaussagen für das System hergeleitet werden. In Zuverlässigkeitsblockdiagrammen werden keine Ausfallmodi unterschieden. Eine Betrachtungseinheit ist entweder intakt oder defekt. Darüber hinaus setzen Zuverlässigkeitsblockdiagramme voraus, dass die Module statistisch unabhängig voneinander ausfallen. Zuverlässigkeitsblockdiagramme werden im Wesentlichen zur Analyse von Hardware verwendet. Sie werden daher im Folgenden nicht weiter beschrieben.

Fehlerbäume

Fehlerbäume liefern qualitative und quantitative Aussagen zur Sicherheit und Zuverlässigkeit bezüglich eines bestimmten, genau definierten Ausfalls /Kaiser et al. 03/. Im Gegensatz zu Zuverlässigkeitsblockdiagrammen können in Fehlerbäumen Ausfallmodi unterschieden werden. Die Ausfallursachen müssen entweder statistisch unabhängig voneinander oder identisch sein. Anders formuliert: Zwei Ursachen eines Fehlerbaums sind entweder identisch – d. h. die selbe Ursache ist mehrfach dargestellt – oder sie sind vollständig unabhängig voneinander. Teilabhängigkeiten können in Fehlerbäumen nicht dargestellt werden. Dies ermöglichen erst Markov-Modelle. Derartige Anhängigkeiten treten auf, wenn durch einen Ausfall andere Ausfälle wahrscheinlicher oder unwahrscheinlicher werden. Solche Ausfälle sind weder identisch noch statistisch unabhängig. Sie können daher in Fehlerbäumen nicht korrekt berücksichtigt werden.

Markov-Modelle

14.4.2 Die FMECA ist präventiv.

Software-FMECA

Die Fehlermöglichkeits-, -einfluss- und -kritikalitätsanalyse (Failure Mode, Effects and Criticality Analysis, FMECA) ist eine vorbeugende Methode zur Identifikation von Problemen, ihrer Risiken und Auswirkungen. Sie verfolgt die folgenden Ziele: >

Erkennung von Risiken und Problembereichen

>

Identifizieren von Risikopotenzialen

>

Quantifizierung von Risiken

>

Finden von Abhilfemaßnahmen

Eine FMECA kann als Komponenten-FMECA (z. B. für eine Baugruppe), als System-FMECA (z. B. für ein Medizingerät) oder als Prozess-FMECA (z. B. für einen System-Entwicklungsprozess) durchgeführt werden. Eine FMECA wird in den folgenden Schritten durchgeführt:

446

14 Prüfen von eingebetteter Software

>

Ausfallanalyse: Zusammenstellung möglicher Ausfälle einschließlich verfügbarer Information zu Art, Ursachen und Folgen

>

Risikobewertung mit Hilfe der Risikoprioritätszahl (RPZ): RPZ = Eintrittswahrscheinlichkeit · Gewicht der Folgen · Wahrscheinlichkeit des Nichtentdeckens Die RPZ ist ein Wert zwischen 1 und 1000, falls für die drei Einflussfaktoren ein Wert zwischen 1 und 10 verwendet wird (1: kein Risiko, geringe Ausprägung; 10: hohes Risiko, hohe Ausprägung). Die Risikoprioritätszahl bildet eine Rangfolge für die Fehlerursachen. Fehlerursachen mit einer hohen Risikoprioritätszahl sind vorrangig zu beseitigen.

>

Maßnahmenvorschläge erzeugen: Die Maßnahmen sollen auf die Vermeidung von Fehlerursachen ausgerichtet sein. Bei einer hohen Auftrittswahrscheinlichkeiten von Fehlerursachen ist eine Verbesserung erforderlich, selbst bei einem geringen Gewicht der Folgen und hoher Entdeckungswahrscheinlichkeit. Dies gilt ebenfalls bei schwerwiegenden Folgen. Aufgrund der gravierenden Auswirkungen müssen ebenfalls Maßnahmen ergriffen werden. Bei einer zu geringen Erkennungswahrscheinlichkeit ist diese zu steigern.

Anschließend werden Maßnahmen beschlossen, das Restrisiko durch eine erneute Berechnung der RPZ analysiert und eine Kosten-/NutzenAnalyse durchgeführt. Die FMECA zielt auf die Erkennung gravierender Probleme. Ihre genauere quantitative Untersuchung kann anschließend z. B. mit einer Fehlerbaumanalyse erfolgen. Die FMECA wird auch für Software in der Praxis verwendet /Mäckel 01/.

14.4.3

Fehlerbaumanalyse

Die Fehlerbaumanalyse ist eine Analysemethode zur qualitativen und quantitativen Beurteilung einer bestimmten betrachteten Wirkung. Ursachen für den Eintritt der Wirkung können z. B. fehlerhafte Komponenten sein. Sie wird insbesondere bei komplexen Systemen eingesetzt, um sicherheitskritische Auswirkungen von Ausfällen zu analysieren. Die Fehlerbaumanalyse erzeugt ein gut lesbares, graphisches Modell des Zusammenhangs zwischen Ursachen und einer bestimmten betrachteten Wirkung.

Qualitative und quantitative Analyse

Das Konzept der Fehlerbaumanalyse ist im Jahre 1961 von der Firma Bell Telephone Laboratories entwickelt worden /Lees 83/, um die Zuverlässigkeit des Minuteman Launch Control Systems zu verbessern. Später wurde die Fehlerbaumanalyse von der Boeing Company für den rechnerunterstützten Einsatz modifiziert.

14.4 Sicherheits- und Zuverlässigkeitsmodellierung

447

Die Fehlerbaumanalyse ist eine Standardtechnik.

Fehlerbaumanalysen können für Systeme aller Art verwendet werden. Bei der Auswertung können auch zeitliche Abhängigkeiten, z. B. in Form von Reparaturen oder Inspektionsstrategien, berücksichtigt werden. Der Zweck der Fehlerbaumanalyse ist die Ermittlung der logischen Verknüpfungen von Komponenten- oder Teilsystemausfällen, die zu einem betrachteten unerwünschten Ereignis führen. Die Ergebnisse dieser Untersuchungen tragen zur Systembeurteilung im Hinblick auf Betrieb und Sicherheit bei. Die Fehlerbaumanalyse ist eine weit verbreitete Standardtechnik zu der Normen existieren /DIN 25424 90/, /IEC 61025 06/. Wie bereits erwähnt, können mit Fehlerbaumanalysen sowohl qualitative als auch quantitative Analysen durchgeführt werden. Ziel der qualitativen Analyse ist die systematische Identifizierung aller möglichen Ausfallkombinationen, die zu einem vorgegebenen unerwünschten Ereignis führen. Ziel der quantitativen Analyse ist die Ermittlung von Zuverlässigkeitskenngrößen, z. B. die Eintrittshäufigkeit des unerwünschten Ereignisses oder die Nichtverfügbarkeit des Systems.

Notationselemente des Fehlerbaums

1 = ausgefallen; 0 = intakt

448

Grundsätzlich ist jeder Fehlerbaum eine hierarchische boolesche Funktion, die beschreibt, wie Ursachen über Zwischenwirkungen ein betrachtetes unerwünschtes Ereignis hervorrufen. Er wird mit den üblichen Symbolen für logische Verknüpfungen notiert, die um einige zusätzliche Symbole erweitert sind. Die Abb. 14.1 und 14.2 zeigen die in der DIN 25424 Teil 1 genormten Symbole. Teil 2 der Norm fügt die Symbole in Abb. 14.3 hinzu. Die Nicht-Verknüpfung negiert den Wert des Eingangs. Bei einer Oder-Verknüpfung tritt die Wirkung ein (A=1), falls mindestens eine der an den Eingängen notierten Ursachen wahr ist. Bei einer Und-Verknüpfung tritt die Wirkung ein (A=1), falls alle an den Eingängen notierten Ursachen wahr sind. Falls sich der Wert an Eingang E1 einer Sekundär-Verknüpfung von logisch 0 nach logisch 1 ändert, so wird mit einer von Eingang E2 angegebenen Dauer und Wahrscheinlichkeit der Wert des Ausgangs auf logisch 1 gesetzt. Dies dient zur Beschreibung von Sekundärausfällen, die möglicherweise von einem Primärausfall hervorgerufen werden. Die Reserve-Verknüpfung zeigt das folgende Verhalten: E1 und E2 sind die Eingänge der Verknüpfung. Sie stellen redundante Funktionselemente dar. E1 ist in Betrieb. E2 ist in Reserve. Ändert sich E1 von logisch 0 nach logisch 1, d. h. fällt E1 aus, so wird auf E2 durch die Umschalteinrichtung E12 umgeschaltet. Nach der Reparatur kann durch die Umschalteinrichtung E21 auf die Einheit E1 zurückgeschaltet werden. Der Ausgang A besitzt den Wert logisch 1, falls beide Einheiten ausgefallen sind (E1 = E2 = 1) oder die Betriebseinheit und die zugehörige Umschalteinheit ausgefallen sind. Die Vorgehensweise bei der Erstellung eines Fehlerbaums ist eine Top Down-Analyse, also eine Verfeinerung der Wirkzusammenhänge beginnend mit dem betrachteten unerwünschten Ereignis in Richtung der Ursachen. Da Ausfälle betrachtet werden, stellt der logische Wert 1 (wahr) das Vorhandensein einer Ursache (z. B. den Ausfall eines Funktionsele-

14 Prüfen von eingebetteter Software

Abbildung 14.1 Verknüpfungssymbole des Fehlerbaums

Abbildung 14.2 Zusatzsymbole des Fehlerbaums

Abbildung 14.3 Zusätzliche Symbole aus der DIN 25424 Teil 2

ments) dar. Der logische Wert 0 (falsch) stellt die intakte Situation dar. Im Gegensatz zum Zuverlässigkeitsblockdiagramm arbeitet der Fehlerbaum nicht mit der Überlebenswahrscheinlichkeit R, sondern mit der Ausfallfunktion F. Zur manuellen Durchführung einer Fehlerbaumanalyse gibt die Norm /DIN 25424 90/ Hinweise. Die Systemanalyse besteht aus den Schritten: >

Analyse der Systemfunktionen,

>

Analyse der Umgebungsbedingungen,

>

Analyse der Hilfsquellen (z. B. Energieversorgung),

>

Analyse der Komponenten,

>

Analyse der Organisation und des Verhaltens.

Fehlerbäume aus Und-, Oder-, Exklusiv-Oder-, m/n- und Nicht-Verknüpfungen können auch quantitativ ausgewertet werden. Die Norm DIN 25424 definiert als Nichtverfügbarkeit einer Betrachtungseinheit die Wahrscheinlichkeit, sie zum Zeitpunkt t ausgefallen anzutreffen. Dies entspricht der Definition der Verteilungsfunktion der Lebensdauer F(t).

14.4 Sicherheits- und Zuverlässigkeitsmodellierung

Quantitative Auswertung

449

Und-Verknüpfung

Sind den Eingängen E1 und E2 einer Und-Verknüpfung die Ausfallfunktion F1 (t) und F2 (t) zugeordnet, so ist die Ausfallfunktion FA (t) des Ausgangs: FA (t) = F1 (t) F2 (t) Für eine Und-Verknüpfung mit n Eingängen gilt: n

FA (t) = ∏ Fi (t) i=1

Oder-Verknüpfung

Sind den Eingängen E1 und E2 einer Oder-Verknüpfung die Ausfallfunktion F1 (t) und F2 (t) zugeordnet, so ist die Ausfallfunktion FA (t) des Ausgangs: FA (t) = F1 (t) + F2 (t) − F1 (t) F2 (t) Für eine Oder-Verknüpfung mit n Eingängen gilt: n

n

i=1

i=1

FA (t) = 1 − ∏ Ri (t) = 1 − ∏(1 − Fi (t)) Eine Voraussetzung für die Gültigkeit der angegebenen Formeln ist die statistische Unabhängigkeit der verknüpften Ereignisse. Abb. 14.4 zeigt eine Fehlerbaumberechnung.

Abbildung 14.4 Quantitative Auswertung eines Fehlerbaums

Repeated Events

450

Eine spezielle Form der Abhängigkeit ist die Identität von Ereignissen (Repeated Events). Diese liegt vor, falls ein Ereignis Eingang mehrerer Verknüpfungen des Fehlerbaums ist. In Abb. 14.5 gilt dies für E2 . Eine quantitative Auswertung des Fehlerbaums würde ein falsches Ergebnis liefern, da die vier Eingangsereignisse aufgrund des doppelt aufgeführten Ereignisses E2 nicht statistisch unabhängig sind. Durch Anwendung der booleschen Algebra kann der Fehlerbaum so umgeformt werden, dass E2 nicht doppelt aufgeführt werden muss (Abb. 14.5). Die Auswertung dieses Fehlerbaums liefert nun das korrekte Ergebnis, da die drei Eingangsereignisse statistisch unabhängig sind. Fehlerbäume mit mehrfach aufgeführten Ereignissen können systematisch analysiert werden.

14 Prüfen von eingebetteter Software

Abbildung 14.5 Vermeidung mehrfach aufgeführter Ereignisse

14.4.4

Markov-Modellierung

Markov-Modelle basieren auf einer Beschreibung des Systemverhaltens mit Zustandsautomaten.

Ein System mit Ausfallrate λ und Reparaturrate μ soll mit Hilfe eines Markov-Modells analysiert werden. Das Markov-Modell besitzt die Zustände A und B. A ist der Zustand, in dem das System intakt ist. B ist der Zustand, in dem das System ausgefallen ist. Das System geht mit der Ausfallrate λ (vgl. Abschnitt 14.5.2) vom intakten Zustand in den ausgefallenen Zustand über. Mit der Reparaturrate μ wechselt es vom ausgefallenen Zustand in den intakten Betrieb (Abb. 14.6).

Markov-Modell = erweiterter Zustandsautomat BEISPIEL

Abbildung 14.6 Markov-Modell

Für die zeitliche Änderung der Aufenthaltswahrscheinlichkeiten in den Zuständen A bzw. B gilt: dPA (t) = −λ PA (t) + μPB (t) dt dPB (t) dPA (t) = λ PA (t) − μPB (t) = − dt dt PA (t) + PB (t) = 1 Das Differentialgleichungssystem, das diese Formeln bilden, besitzt die folgende Lösung: μ μ PA (t) = + (c − )e−(μ+λ )t μ +λ μ +λ

14.4 Sicherheits- und Zuverlässigkeitsmodellierung

451

 PB (t) = 1 − PA (t) = 1 −

μ μ + (c − )e−(μ+λ )t μ +λ μ +λ



Einsetzen in die Differentialgleichungen zeigt dies:   μ μ −(μ+λ )t + (c − )e λ PA (t) − μ PB (t) = λ μ +λ μ +λ   μ μ + (c − )e−(μ+λ )t ) −μ 1 − ( μ +λ μ +λ =

μ λ μ − μ2 − λ μ + μ2 + (c − )(μ + λ )e−(μ+λ )t μ +λ μ +λ

= (c −

μ dPB (t) dPA (t) )(μ + λ )e−(μ+λ )t = =− μ +λ dt dt

Für t = 0 erhält man die initialen Aufenthaltswahrscheinlichkeiten in den Zuständen. Falls das System zum Zeitpunkt 0 sicher intakt ist, so besitzt die Konstante c den Wert 1. μ μ PA (t = 0) = + (c − =c μ +λ μ +λ PB (t = 0) = 1 − c Für t gegen unendlich erhält man den eingeschwungenen Zustand des Systems. μ lim PA (t) = t→∞ μ +λ μ lim PB (t) = 1 − t→∞ μ +λ Diese Aufenthaltswahrscheinlichkeiten sind von den initialen Aufenthaltswahrscheinlichkeiten unabhängig. Ist die Reparaturrate groß im Vergleich zur Ausfallrate, so geht die Wahrscheinlichkeit, dass sich das System im intakten Zustand befindet, gegen 1. Ist die Reparaturrate klein im Vergleich zur Ausfallrate, so geht die Wahrscheinlichkeit, das System intakt anzutreffen, gegen Null.

14.4.5

Bewertung der Sicherheits- und Zuverlässigkeitsmodellierung

Die beschriebenen Techniken besitzen ein weite Verbreitung in der Praxis. Ursprünglich war der Anwendungsbereich die Analyse von Hardware-Systemen. Heute werden sie vielfach zur Untersuchung von Hardware-/Software-Systemen und für eingebettete Software verwendet. Für die Entwicklung sicherheitskritischer, softwareintensiver Systeme existieren zahlreiche Standards, die die Anwendung der Techniken fordern. Die FMECA sollte mindestens für das zu entwickelnde System und seine kritischen Komponenten durchgeführt werden. Für die dabei erkannten schwerwiegenden Risiken bietet sich die Durchführung einer Feh-

452

14 Prüfen von eingebetteter Software

lerbaumanalyse zur quantitativen Bestimmung der Gefährdung an. Darüber hinaus können so wichtige und weniger wichtige Ausfallursachen getrennt werden. Dies ist für die Identifikation von Verbesserungen nützlich. Die Kombination von Markov-Modellen und Fehlerbäumen ist ebenfalls sinnvoll. Fehlerbäume können hier zur präzisen Bestimmung der Übergangsraten dienen. Die Entwicklung sicherheitskritischer, softwareintensiver Systeme ist ohne die geschilderten Techniken kaum denkbar.

14.5

Stochastische analyse

Software-Zuverlässigkeits-

14.5.1

Eigenschaften und Ziele der stochastischen Software-Zuverlässigkeitsanalyse

Die im vorhergehenden Abschnitt beschriebenen modellierenden Techniken besitzen den Vorteil der frühen, präventiven Anwendbarkeit. Ihr gemeinsamer Nachteil ist, dass die Präzision der Ergebnisse von der Qualität des Modells abhängig ist. Mit modellierenden Ansätzen kann – streng genommen – nichts bewiesen werden, weil das Risiko existiert, dass das Modell zu ungenau oder regelrecht falsch ist. Verlässlicher sind messende Ansätze. Diese verlangen allerdings eine Realisierung der Betrachtungseinheit, um sie vermessen zu können. Sollte sich bei den Messungen herausstellen, dass die gewählte Realisierung nicht geeignet ist, so müssen Änderungen vorgenommen werden. Ein Nachteil messender Verfahren ist offensichtlich ihre späte Anwendbarkeit. Ihr Vorteil ist, dass die Gültigkeit von Messungen an der realisierten Betrachtungseinheit nicht bezweifelt werden kann. Eine Messung ist ein echter Nachweis. Leider sind Messungen selten vollständig. Es handelt sich um Stichproben, die aber ggf. mit geeigneten statistischen Mitteln ausgewertet werden können, um ein statistisch abgesichertes Vertrauensniveau zu erhalten. Mit Fehlerbäumen kann Zuverlässigkeit modelliert werden. Mit den hier beschriebenen Verfahren kann sie gemessen, statistisch ausgewertet und für die Zukunft prognostiziert werden. Es ist üblich, die bei der stochastischen Zuverlässigkeitsanalyse verwendeten Ansätze als „Zuverlässigkeitsmodelle“ zu bezeichnen. Es handelt sich bei diesen Modellen um statistische Ansätze zur Auswertung von Ausfallbeobachtungen. Es ist wichtig, sie nicht mit den in Abschnitt 14.4 dargestellten Modellen zu verwechseln.

Nachteil: Nicht präventiv Vorteil: Echte Messungen

Zuverlässigkeit ist eine stochastische Eigenschaft eines betrachteten Systems. Sie wird durch die zeitliche Verteilung des Eintretens von Fehlerwirkungen – also von Fehlverhalten und Ausfällen – bestimmt. Für die Hardware-Bestandteile eines Systems wird oft davon ausgegangen, dass nur spontane Ausfälle aufgrund von Fertigungsfehlern, Verschleiß oder äußeren Einflüssen – z. B. Strahlung, Temperatur – auftreten. Systematische Konstruktionsfehler werden als Quelle von Fehlverhalten häufig

14.5 Stochastische Software-Zuverlässigkeitsanalyse

453

vernachlässigt. Bei Software-Bestandteilen sind die Fehler, die die Ausfälle verursachen, statisch vorhanden. Spontane Ausfälle einer fehlerfreien Software sind nicht möglich. Der zufällige Eintritt von Fehlverhalten bei Software kommt durch die in der Regel vielfältigen Benutzungsmöglichkeiten einer Software zustande. Diese können als ein Ziehungsprozess verstanden werden, der Fehlverhalten hervorbringt. Daher beeinflusst bei Software die Intensität und die Art der Benutzung die Häufigkeit, mit der Ausfälle auftreten, und damit auch die Zuverlässigkeit. Es entsteht der Eindruck, dass zwischen den Mechanismen, die Hardware-Zuverlässigkeit und Software-Zuverlässigkeit beeinflussen, gravierende Unterschiede existieren. Dieser Aspekt wird im Folgenden noch näher diskutiert. Die Durchführung stochastischer Zuverlässigkeitsanalysen für reine Hardware-Systeme ist Stand der Technik. Für Software-Systeme sind Zuverlässigkeitsanalysetechniken bekannt. In der praktischen Anwendung sind sie noch nicht verbreitet zu finden. Entscheidend für die Zuverlässigkeit ist die Häufigkeit des Eintretens von Fehlverhalten. Dies ist eine Eigenschaft, die sich dynamisch bei der Benutzung eines Systems zeigt. Ferner ist einsichtig, dass, falls die Zuverlässigkeit z. B. mit Hilfe der beobachteten Zeitspanne zwischen dem Eintreten zweier aufeinanderfolgender Ausfälle definiert wird, auch bei einem sehr zuverlässigen System einmal zwei Ausfälle zeitlich dicht aufeinander folgen können. Bei der Betrachtung der Qualitätseigenschaft Zuverlässigkeit muss folglich mit Mittelwerten und Wahrscheinlichkeiten gearbeitet werden. Zuverlässigkeit ist die Wahrscheinlichkeit des fehlerfreien Funktionierens eines Systems über eine bestimmte Zeitspanne in einer bestimmten Umgebung (Benutzungsart, Benutzungsintensität, Betriebsumgebung).

14.5.2 Beschreibung von Fehlverhalten über der Zeit

Grundlagen der stochastischen Zuverlässigkeitsanalyse

Zur Beschreibung der Beobachtung von Fehlverhalten in Abhängigkeit der Zeit existieren grundsätzlich die folgenden Möglichkeiten (Abb. 14.7): >

Zeitpunkte der Fehlverhalten

>

Zeitintervalle zwischen Fehlverhalten

>

Anzahl der insgesamt bis zu einem Zeitpunkt beobachtete Fehlverhalten

>

Anzahl der innerhalb eines betrachteten Zeitintervalls beobachteten Fehlverhalten

Es ist sinnvoll, je nach Verwendungszweck diese unterschiedlichen Beschreibungsformen zu benutzen. Als Basis für die Modellierung der Zuverlässigkeit sind einige grundlegende Definitionen erforderlich. Diese

454

14 Prüfen von eingebetteter Software

Abbildung 14.7 Beschreibung von Ausfällen über die Zeit

Definitionen werden aufgrund der besseren Vorstellbarkeit im Folgenden anhand von einfachen Beispielen aus der Welt der Hardware angegeben. Für Software existieren sie völlig analog. Betrachten wir einmal einen nicht reparierbaren Gegenstand – z. B. eine Glühbirne. Natürlich könnte man einen durchgebrannten Glühfaden austauschen, um die Birne zu reparieren. Das wird aber wirtschaftlich nicht sinnvoll sein, so dass sie nicht repariert werden soll. Für eine Betrachtungseinheit ist ihre Lebensdauer die Zeitspanne von ihrem Benutzungsbeginn bis zum Ausfallzeitpunkt. Die Lebensdauer der Glühbirne kann durch ein Experiment – eine Zeitmessung – ermittelt werden. Es ist direkt einsichtig, dass dieses Experiment recht lang dauern mag. Daher macht man sich bei einschlägigen Lebensdaueruntersuchungen für Hardware einige Gedanken darüber, wie die Dauer des Experiments verkürzt werden kann. Eine Möglichkeit ist z. B. bei Halbleitern der Betrieb bei einer erhöhten Umgebungstemperatur. Die so gewonnenen Daten müssen unter Ausnutzung physikalischer Gesetze mit einem nennenswerten mathematischen Aufwand auf die Nutzung mit normalen Betriebsparametern umgerechnet werden. Das Experiment mit einer Glühbirne ist allerdings nicht besonders aussagekräftig. Vielleicht ist die gewählte Glühbirne zufällig kein guter Stellvertreter für die Gesamtheit der betrachteten Glühbirnen. Sie könnte viel besser oder schlechter als die durchschnittliche Glühbirne sein. Um dieses Problem in den Griff zu bekommen, sollte für das Experiment eine größere Anzahl von Glühbirnen verwendet werden. Wir nehmen also eine größere Anzahl von Glühbirnen – z. B. 10 Glühbirnen – am Zeitpunkt 0 gleichzeitig in Betrieb. Für jede Glühbirne wird die Zeit von der Inbetriebnahme bis zum Auftreten des Ausfalls aufgezeichnet.

Gedankenexperiment

Man erhält so für jede Glühbirne ihre spezifische Lebensdauer T . Trägt man den Anteil der zum Zeitpunkt t ausgefallenen Glühbirnen über t auf, so erhält man die so genannte empirische Verteilungsfunktion der Lebensdauer. Es handelt sich dabei um eine Treppenfunktion, die bei dem Wert 0 beginnt und für große Zeiten gegen den Wert 1 geht (Abb. 14.8). Würde man nicht 10, sondern 100 oder gar 1000 Glühbirnen verwenden, so würde sich dieser Sachverhalt nicht ändern. Die Anzahl der „Treppenstufen“ nimmt entsprecht der Anzahl der Betrachtungseinheiten zu; die Funktion wird „glatter“.

Lebensdauer T

14.5 Stochastische Software-Zuverlässigkeitsanalyse

Die empirische Verteilungsfunktion der Lebensdauer

455

Abbildung 14.8 Lebensdauerverteilung der Beispieldaten

Verteilungsfunktion der Lebensdauer F(t)

Geht die Anzahl der Systeme gegen unendlich, so approximiert die empirische Verteilungsfunktion der Lebensdauer die Verteilungsfunktion der Lebensdauer F(t). Die empirische Verteilungsfunktion der Lebensdauer ist das Ergebnis eines Experiments. Die Verteilungsfunktion der Lebensdauer kann experimentell nicht ermittelt werden, weil das Experiment unendlich viele Betrachtungseinheiten umfassen müsste. Aber man kann die wahrscheinlichste Verteilungsfunktion der Lebensdauer aus der empirischen Verteilungsfunktion der Lebensdauer mit statistischen Mitteln bestimmen. So könnte man auf Basis der Ergebnisse des Experiments (Tab. 14.1), z. B. die in Abb. 14.8 gestrichelt eingezeichnete Verteilungsfunktion der Lebensdauer erzeugen. In der Verteilungsfunktion der Lebensdauer ist die Lebensdauer T eine so genannte Zufallsvariable und es gilt: F(t) = P{T ≤ t}. F(t) ist die Wahrscheinlichkeit, dass die Lebensdauer T kleiner oder gleich t ist, also eine Betrachtungseinheit spätestens zum Zeitpunkt t ausgefallen ist. Es gilt: F(t = 0) = 0, d. h. eine neue Betrachtungseinheit ist intakt, und lim F(t) = 1,

t→∞

d. h. jede Betrachtungseinheit fällt irgendwann aus. Die Überlebenswahrscheinlichkeit R(t)

Man definiert mit Hilfe von F(t) die Überlebenswahrscheinlichkeit R(t). Da F(t) die Wahrscheinlichkeit angibt, dass spätestens zum Zeitpunkt t ein Fehlverhalten aufgetreten ist, ist R(t) = 1 − F(t) die Wahrscheinlich-

Tabelle 14.1 Beispiel zur Lebensdauerverteilung

456

14 Prüfen von eingebetteter Software

keit, dass zum Zeitpunkt t noch kein Fehlverhalten aufgetreten ist. R(t) gibt also die Wahrscheinlichkeit an, dass am Zeitpunkt t das betrachtete System noch funktionsfähig ist. Die Wahrscheinlichkeitsdichte der Lebensdauer f (t) ist die erste zeitliche Ableitung der Verteilungsfunktion der Lebensdauer F(t). Sie beschreibt die Veränderung der Wahrscheinlichkeit, ein System ausgefallen anzutreffen, über der Zeit: dF(t) dt Ein wichtiges Maß für Zuverlässigkeit ist die Mean Time To Failure (MTTF) bzw. die Mean Time Between Failure (MTBF) bei reparierbaren Systemen. Die MTTF bzw. MTBF ist der Erwartungswert für die Zeitspanne bis zum Ausfall bzw. zwischen zwei aufeinander folgenden Ausfällen. Sie wird folgendermaßen ermittelt:

Wahrscheinlichkeitsdichte der Lebensdauer f(t)

f (t) =

T¯ = E(T ) =

∞

MTTF bzw. MTBF

t f (t)dt

0

Die Ausfallrate λ (t) ist der Grenzwert der in einem Zeitintervall ausgefallenen Einheiten, bezogen auf die zu Beginn des Zeitintervalls noch funktionsfähigen Einheiten, der entsteht, wenn die Länge des Zeitintervalls gegen Null geht. λ (t) =

Die Ausfallrate λ (t)

−dR(t)/dt f (t) dF(t)/dt = = R(t) R(t) R(t)

Man kann sich die Bedeutung der Ausfallrate folgendermaßen verdeutlichen. Die bedingte Wahrscheinlichkeit, dass ein System, das bis zum Zeitpunkt t ausfallfrei funktioniert hat, auch noch die Zeitspanne ohne Ausfall übersteht, ist: R(t + Δt) R(t) Also ist die Wahrscheinlichkeit, dass das System die Zeitspanne Δt nicht ohne Ausfall übersteht, d. h. innerhalb von ausfällt: 1−

1 − F(t + Δt) 1 − F(t) − (1 − F(t + Δt)) F(t + Δt) − F(t) R(t + Δt) = 1− = = R(t) 1 − F(t) 1 − F(t) 1 − F(t)

Da die angegebene Wahrscheinlichkeit für kleine Zeitintervalle proportional zu ist, wird der Ausdruck durch dividiert und der Grenzwert betrachtet, der entsteht, wenn die Länge des Zeitintervalls Δt gegen 0 geht: lim

Δt→0

1 f (t) 1 F(t + Δt) − F(t) F(t + Δt) − F(t) = lim = = λ (t) Δt 1 − F(t) R(t) Δt→0 Δt R(t)

Die Wahrscheinlichkeit, dass ein System mit dem Alter t innerhalb der des kleinen Zeitintervalls Δt ausfällt, ist also ungefähr: Δtλ (t) Die Auswahl einer Modellierungsfunktion und die anschließende Bestimmung der freien Parameter der Modellierungsfunktion im Hinblick auf

14.5 Stochastische Software-Zuverlässigkeitsanalyse

PROBLEME: Auswahl der Modellierungsfunktion und Bestimmung der freien Parameter 457

eine möglichst optimale Anpassung an eine Beobachtung sind Hauptprobleme bei der stochastischen Datenanalyse. Im Vorgriff auf Unterabschnitt 14.5.4.1, in dem dargestellt wird, wie systematisch entschieden werden kann, ob eine betrachtete Modellierungsfunktion eine geeignete Beschreibung gegebener Ausfalldaten gestattet, wird für die hier vorliegenden Daten von exponentialverteilten Lebensdauern ausgegangen. Es wird also angenommen, dass für den Fall, dass die Anzahl N der betrachteten Systeme gegen unendlich geht, die empirische Lebensdauerverteilung die folgende Lebensdauerverteilung F(t) approximiert: Exponentialverteilung

F(t) = 1 − e−λt Die Exponentialverteilung besitzt nur den Parameter λ , die so genannte Ausfallrate. Dieser Parameter ist auf Basis der Beobachtungen so zu bestimmen, dass eine entsprechend eines vorgegebenen Kriteriums optimale Anpassung der Funktion auf die beobachteten Daten erreicht wird. Es ist möglich, dies auf unterschiedliche Weise zu erreichen (siehe Unterabschnitt 14.5.4.2). Nach dem so genannten Maximum-Likelihood-Verfahren erhält man für die Exponentialverteilung den folgenden optimalen Wert für λ : N λ= n ∑ Ti i=1

Für die Ausfalldaten in Tab. 14.1 erhält man: λ = 0,0000353 / h. Durch Einsetzen dieses Werts in die Exponentialverteilung erhält man die dritte Zeile in Tab. 14.1 und den Funktionsverlauf für F(t) in Abb. 14.8. Die Überlebenswahrscheinlichkeit R(t) (siehe Abb. 14.9) erhält man aus F(t): R(t) = 1 − F(t) = e−λt Die Ausfallrate λ ist hier offensichtlich zeitlich nicht veränderlich. Einsetzen der Verteilungsfunktion in die Gleichung für die Ausfallrate bestätigt dies: λ (t) =

f (t) dF(t)/dt −dR(t)/dt λ e−λt = = = −λt = λ R(t) R(t) R(t) e

Eine zeitlich konstante Ausfallrate verursacht eine Exponentialverteilung der Lebensdauer. Jede der angegebenen Funktionen F(t), R(t), f (t) und λ (t) enthält die gesamte Information. Ist eine der Funktionen bekannt, so können die übrigen bestimmt werden. Die MTTF kann für die Beispieldaten mit der angegebenen Gleichung bestimmt werden: T¯ = E(T ) =  =λ

458

∞ 0

t f (t)dt = ∞

e−λt (−λt − 1) λ2

∞ 0

= 0

tλ e−λt dt = λ

∞

te−λt dt

0

1 λ

14 Prüfen von eingebetteter Software

Abbildung 14.9 R(t) und Ausfallrate

Für Ausfallverhalten, das durch exponentialverteilte Lebensdauern und damit konstante Ausfallraten bestimmt ist, ist die MTTF der Kehrwert der Ausfallrate und daher ebenfalls konstant. Dieser Zusammenhang gilt jedoch nicht allgemein, sondern nur im speziellen Fall der konstanten Ausfallrate, der für die Praxis durchaus bedeutend ist. Für das Beispiel aus Tab. 14.1 erhält man: 1 T¯ = = 28341h. λ Bei einem beliebig herausgegriffenen System (entsprechend Tab. 14.1) darf man eine Lebensdauer von 28341 Stunden erwarten. Das bedeutet aber nicht, dass zu diesem Zeitpunkt damit zu rechnen ist, dass die Hälfte aller Systeme noch intakt ist. Wie anhand des Verlaufs der Verteilungsfunktion der Lebensdauer F(t) in Abb. 14.8 zu erkennen ist, ist die bei exponentialverteilten Lebensdauern die Wahrscheinlichkeit, ein System zum Zeitpunkt t = T¯ defekt anzutreffen, bereits circa 0,632. Es muss also damit gerechnet werden, dass bereits 63,2 % aller Systeme ausgefallen sind.

Bei Exponentialverteilungen sind die Ausfallrate und die MTTF Kehrwerte voneinander.

T50 bezeichnet den Zeitpunkt, an dem erwartet werden kann, dass die Hälfte der Systeme ausgefallen ist. Für exponentialverteilte Lebensdauern gilt: 0, 5 = F(T50 ) = 1 − e−λ T50 T50 =

−ln(0, 5) 0, 693 1 ≈ < = T¯ λ λ λ

14.5 Stochastische Software-Zuverlässigkeitsanalyse

459

Für das Beispiel nach Tab. 14.1 ist der Wert von T50 folglich 19640 Stunden. Weibullverteilung und logarithmische Normalverteilung

Für die Hardwarezuverlässigkeitsmodellierung werden oft die Weibullverteilung und die logarithmische Normalverteilung verwendet. Beide Verteilungen gestatten die Beschreibung fallender, konstanter bzw. fast konstanter (bei der logarithmischen Normalverteilung) und steigender Ausfallraten. Daher kann Sie verwendet werden, um alle Teile der für Hardware oft beobachteten so genannten Badewannenkurve der Ausfallrate zu modellieren. Die Beschreibung der Frühausfälle fordert eine fallende Ausfallrate. Nach dem Abklingen der Frühausfälle bis zum Eintreten von Verschleißerscheinungen liegt eine konstante Ausfallrate vor. Im Verschleißbereich steigt sie an.

14.5.3 Idealisierende Annahme für Hardware: Keine Konstruktionsfehler

Hardware- und Software-Zuverlässigkeitsanalyse im Vergleich

Es wird oft vorausgesetzt, dass einige Unterschiede zwischen Hardwareund Software-Zuverlässigkeit existieren. Bei Hardware wird häufig angenommen, dass Fehlverhalten oder Ausfälle eine Folge von Fertigungsfehlern oder physikalischer Abnutzung sind. Konstruktionsfehler, die bei Software der Gegenstand des Interesses sind, werden in der Regel vernachlässigt. Bei Hardware wird daher für die Ausfallrate eine so genannte Badewannenkurve angenommen. Frühausfälle sind z. B. aufgrund von Fertigungsfehlern häufig. Anschließend wird das System stabil, um mit fortschreitender Zeit einen Anstieg der Ausfallrate durch Verschleißerscheinungen zu zeigen. Wenn eine defekte Komponente eines Systems gegen ein neues Teil gleichen Typs ausgetauscht wird, so nimmt die Zuverlässigkeit für dieses Teil den Neuwert an. Die Zuverlässigkeit des Systems erreicht durch Austausch von Komponenten gegen neue Komponenten hingegen im allgemeinen nicht den Neuwert der System-Zuverlässigkeit, da die übrigen Komponenten bereits zu einem gewissen Grad verschlissen sind. So erhält man z. B. durch den Austausch des Motors eines Autos kein neues Fahrzeug, da das Getriebe, die Karosserie, usw. entsprechend ihres Alters Verschleiß zeigen.

Idealisierende Annahme für Software: Ausschließlich Konstruktionsfehler

460

Wie bereits beschrieben, ist Software-Zuverlässigkeit durch Ausfälle und Fehlverhalten als Folgen von Konstruktionsfehlern bestimmt, die in dem System vorliegen, aber nur zufällig in Erscheinung treten. Setzt man eine perfekte Fehlerkorrektur voraus, so steigt die Zuverlässigkeit des Gesamtsystems nach der Fehlerkorrektur über den Neuwert. Durch fehlerhafte Korrekturen und Erweiterungen, die neue Fehler hinzufügen, kann die Zuverlässigkeit sinken. Ferner existieren für Software-Systeme oft viele unterschiedliche Formen der Benutzung, was dazu führen kann,

14 Prüfen von eingebetteter Software

dass unterschiedliche Benutzer eine voneinander abweichende Wahrnehmung der Zuverlässigkeit des gleichen Systems besitzen. Für Hardware kann man sich die idealisierte Situation folgendermaßen verdeutlichen. In Abb. 14.10 stellen weiße Kreise fehlerfreie Komponenten dar. Schwarze Kreise repräsentieren fehlerhafte Komponenten. Zu Beginn sind alle Komponenten fehlerfrei, d. h. alle Kreise sind weiß. Während des Betriebs treten Komponentenausfälle auf, d. h. weiße Kreise werden spontan schwarz. Dies wird unmittelbar erkannt, falls das System betrieben wird. Die Erkennung des Ausfalls hängt nicht von der Art des Betriebs ab, sondern nur davon, dass das System betrieben wird. Alle Komponenten sind gleichzeitig sichtbar. Ein Ausfall ist direkt erkennbar. Die idealisierte Situation für Software ist verschieden. Bei Software wird davon ausgegangen, dass Fehler enthalten sind. Diese sind jedoch nicht direkt erkennbar. Ein Betriebsfall – also auch ein Testlauf – einer Software entspricht einer Ziehung in einem bestimmten Bereich der Software. Falls eine fehlerhafte Stelle auf bestimmte Weise ausgeführt wird, so tritt ein Fehlverhalten auf. In Abb. 14.11 entspricht das der Aufde-

Abbildung 14.10 Hardware-Zuverlässigkeit

Abbildung 14.11 Software-Zuverlässigkeit

14.5 Stochastische Software-Zuverlässigkeitsanalyse

461

ckung eines Bereichs, der einen schwarzen Kreis enthält. Natürlich beeinflusst der Ziehungsprozess – also die Art des Betriebs – das Ausfallverhalten. Die Ausfallmechanismen von Hardware und Software mögen unterschiedlich sein. Man kann aber beide Prozesse mit Mitteln der Stochastik beschreiben. Bei einigen Systemen verwischen unter bestimmten Voraussetzungen die Unterschiede zwischen Hardware und Software in Bezug auf stochastische Zuverlässigkeitsanalysen bei einigen Systemen. In diesem Fall ist es möglich, beide Ausfallmechanismen mit einem einzigen Ansatz zu beschreiben. Die Realität: Heutige komplexe Hardware ist nicht frei von Konstruktionsfehlern

Bei komplexen Systemen – z. B. Industrieanlagen, verkehrstechnischen Systemen – kann man nicht von einer bereits zu Beginn perfekt konstruierten Hardware ausgehen. Vielmehr besitzt die Hardware zu Beginn einige Schwächen, die ähnlich wie Software-Fehler Ausfälle verursachen, was zu Verbesserungen der Hardware führt. Die Hardware wird also während der ersten Betriebsphasen noch verbessert. Die gleiche Beobachtung trifft auf hochintegrierte Schaltkreise zu. Schaltungsentwurf wird heute mit entsprechenden Entwurfssprachen durchgeführt. Damit ist Schaltungsentwurf eine Tätigkeit, die den gleichen Gesetzmäßigkeiten unterliegt, wie Software-Entwicklung. Es ist nicht einzusehen, warum dieser Prozess fehlerfreier durchgeführt werden können sollte, als Software-Entwicklung. Offensichtlich ist es für den Prozess der Entstehung von Fehlern gleichgültig, ob Hardware oder Software erzeugt wird. Entscheidend ist die Komplexität der zu bewältigenden Aufgabe. Die Annahme, dass Hardware frei von systematischen Fehlern sei, entstammt einer Zeit, in die Hardware im Vergleich zur Software eine sehr geringe Komplexität besessen hat. Das gilt für viele heute entwickelte Systeme nicht mehr, und daher ist die Vernachlässigung von Konstruktionsfehlern nicht haltbar. Der wahrscheinlich bekannteste Konstruktionsfehler in einem integrierten Schaltkreis ist der 1994 erkannte Fehler der Fließpunktdivision in Intels Pentium-Mikroprozessor, der so genannte FDIV-Fehler /Hüskes 95/, /Stiller 95a/. Eine Aufstellung von weiteren Fehlern in /Stiller 95b/ zeigt, dass derartige Konstruktionsfehler in komplexen integrierten Schaltkreisen keine Ausnahme sind.

Die Realität: Bei teuren Investitionsgütern wird Verschleiß oft durch Wartung überkompensiert. Solche Hardware zeigt kaum Verschleiß.

Eine ähnliche Annäherung von Hardware und Software findet für einige Systeme beim Verschleißverhalten statt. Anwendungen der hier entwickelten Forschungsergebnisse auf verschiedene große Systeme haben zu der zunächst einmal überraschenden Erkenntnis geführt, dass einige Hardware-/Software-Systeme auch bei langen Betriebszeiten keine nennenswerten Verschleißausfälle zeigen. Die Ursache ist präventive Wartung. Hardwarekomponenten werden regelmäßig oder bei Erreichen einer bestimmten Verschleißgrenze ausgetauscht, um kostspielige und unangenehme Ausfälle und Stillstandszeiten zu vermeiden. Die im Rahmen meiner Forschungsarbeiten durchgeführten zahlreichen Anwendungen der stochastischen Zuverlässigkeitsanalysetechniken auf unterschiedliche Systeme zeigen, dass in vielen Fällen und unter bestimmten Voraussetzungen die für Software konzipierten Zuverlässigkeitsmodelle auch

462

14 Prüfen von eingebetteter Software

zur Modellierung von Systemverhalten verwendet werden können. Empirischer Ergebnisse sind in /Liggesmeyer 00/ enthalten.

14.5.4

Software-Zuverlässigkeitsmodelle

Software-Zuverlässigkeitsmodellierung ist etwa seit Beginn der 70er Jahre eine eigenständige Disziplin. Eine aktuelle Übersicht des Themas ist in /Lyu 95/ enthalten. Es sind viele stochastische Zuverlässigkeitsmodelle vorgeschlagen worden, die unterschiedlichen Kategorien angehören. Es gibt mehrere Kriterien, um Modelle in Kategorien einzuteilen. Neben der Unterscheidung von Modellen mit endlicher und unendlicher Ausfallanzahl können elementare Modelltypen unterschieden werden. Verbreitete Modelle sind z. B. das elementare Ausführungszeiten-Modell von Musa /Musa et al. 87/, das Jelinski-Moranda-Modell /Jelinski, Moranda 72/ und das Littlewood-Verrall-Modell /Littlewood, Verall 73/. Darüber hinaus werden auch klassische Modelle für Hardware-Zuverlässigkeit (z. B. Weibullverteilungen) für Software verwendet.

Es existieren zahlreiche Zuverlässigkeitsmodelle.

Die Einschätzung der Eignung der Modelle ist aufgrund der Modellvielfalt und ihrer spezifischen Voraussetzungen für den Anwender kompliziert. Darüber hinaus ist neben der Bewertung der grundsätzlichen Eignung eines Modells eine Festlegung der Modellparameter erforderlich.

Die Modellauswahl ist schwierig.

14.5.4.1

Bestimmung von Modellparametern

Im Folgenden werden zwei unterschiedliche Verfahren vorgestellt, die dazu dienen, die freien Parameter einer bekannten Funktion so zu bestimmen, das die Funktion „gut zu gegebenen Beobachtungen passt“. Man benötigt derartige Verfahren, um ein ausgewähltes Zuverlässigkeitsmodell möglichst gut an vorliegende Ausfalldaten anzupassen. Beide Verfahren erfordern ein wenig Mathematik. Sie können die angegebenen Schritte nachvollziehen. Es reicht aber auch aus, wenn Sie die Grundideen der Verfahren kennen. Das Verfahren der kleinsten Fehlerquadrate bildet jeweils das Quadrat der Abweichung zwischen jeder Beobachtung und dem Wert, den das Zuverlässigkeitsmodell an dieser Stelle liefert. Anschließend werden die Parameter so bestimmt, dass die Summe dieser Quadrate einen möglichst kleinen Wert ergibt. Ist das gelungen, so bewertet dieses Verfahren die entsprechenden Parameter als beste Lösung.

Verfahren der kleinsten Fehlerquadrate: Least Squares

Ziel der so genannten Maximum-Likelihood-Verfahrens ist es, die freien Parameter so zu wählen, dass die Wahrscheinlichkeit maximiert wird, eine zur vorliegenden Beobachtung „ähnliche“ Beobachtung zu erzeugen.

Maximum-Likelihood-Verfahren

Das Ziel des Verfahrens der kleinsten Fehlerquadrate ist, die Parameter so zu bestimmen, dass die Summe der Quadrate der Abweichungen zwischen den berechneten und den beobachteten Werten minimal wird. Im

Least-SquaresAnpassung

14.5 Stochastische Software-Zuverlässigkeitsanalyse

463

Beispiel nach Tab. 14.1 sind die Parameter der Verteilungsfunktion so zu bestimmen, dass die Summe der Fehlerquadrate an den beobachten Ausfallzeitpunkten minimal wird. Bezeichnet Fi den Wert der empirischen Verteilungsfunktion an der Stelle ti , so ist der folgende Ausdruck zu minimieren: n

n

i=1

i=1

Δ = ∑ Δ2i = ∑ (F(ti ) − Fi )2 Wird die Exponentialverteilung verwendet, so erhält man: n

n

n

i=1

i=1

i=1

Δexp = ∑ Δ2iexp = ∑ (F(ti ) − Fi )2 = ∑ (1 − e−λti − Fi )2 Es ist der Wert λ zu ermitteln, der diesen Ausdruck minimiert. n

dΔexp = dλ

d( ∑ Δ2iexp ) i=1

dλ

n

= ∑ 2(1 − e−λti − Fi )ti e−λti i=1

Den gesuchten Wert λˆ erhält man durch Nullstellenbestimmung dieses Ausdrucks. n

ˆ

ˆ

!

∑ 2(1 − e−λti − Fi )ti e−λti = 0

i=1

Nummerisches Lösungsverfahren

Oft ist dies nicht analytisch möglich und wird daher mit einem geeigneten nummerischen Verfahren durchgeführt. Bezeichnet man im Falle der Exponentialverteilung die Funktion, deren Nullstelle gesucht ist, mit f (λ ), so erhält man mit der Iterationsformel der Newtonschen Iteration die folgende Vorschrift zur Bestimmung von λˆ : λn+1 = λn −

f (λn ) d f (λn ) dλ n

mit fexp (λ ) = ∑ 2(1 − e−λti − Fi )ti e−λti i=1

und

n d fexp (λ ) = ∑ 2ti2 [(Fi − 1)e−λti + 2e−2λti ] dλ i=1

Die Nullstellensuche nach dem Verfahren der Newtonschen Iteration liefert auf Basis der Ausfallzeiten nach Tab. 14.1 für die Exponentialverteilung einen Wert λˆ ≈ 3, 9326702 · 10−5 /h. Die Summe der Fehlerquadrate hat bei dieser Ausfallrate den Wert 2, 81517 · 10−3 . Definition der Weibullverteilung: 1 β F(t) = 1 − e− α t

Zum Vergleich soll die Weibullverteilung auf die gleichen Daten angepasst werden. n

n

n

i=1

i=1

i=1

1 β

Δweibull = ∑ Δ2iweibull = ∑ (F(ti ) − Fi )2 = ∑ (1 − e− α ti − Fi )2 Die Parameter α und β sind so zu bestimmen, dass der Wert dieses Ausdrucks minimal wird:

464

14 Prüfen von eingebetteter Software

n

dΔweibull = dα

d( ∑ Δ2iweibull ) i=1

dα



n

n

1 β

= ∑ −2(1 − e− α ti − Fi ) i=1

1 β

∑ −2 1 − e− αˆ ti − Fi



β ti

i=1

β

1 β

ti e− α ti α2

1 β

− e− αˆ ti ! =0 αˆ 2

n

dΔweibull = dβ n

∑2



d( ∑ Δ2iweibull ) i=1

dβ βˆ

− α1 ti

1−e

β

− α1 ti

= ∑ 2(1 − e i=1

− Fi

i=1

n

β

1 β

t ln ti e− α ti − Fi ) i α

1 βˆ

βˆ

ti ln ti e− α ti ! =0 α

Auch hier kann die Bestimmung von αˆ und βˆ mit Hilfe der Newtonschen Iteration durchgeführt werden. Bezeichnet man im Falle der Weibullverteilung die Funktionen, deren Nullstellen zu bestimmen sind, mit g(α) und h(β ), so erhält man mit der Iterationsformel der Newtonschen Iteration die folgende Bestimmungsvorschrift: αn+1 = αn −

g(αn ) dg(αn ) dα

und βn+1 = βn −

dh(βn ) dβ

β β β ti − α1 ti − α1 ti − Fi ) − 2 + 2e + 2Fi (1 − 2e α β  β β n − α1 ti β ti ti dh(β ) 2 βe − α1 ti (2 − 1)e + (Fi − 1)( − 1) = ∑ 2(ln ti ) ti dβ α α α i=1 β

1 β

n −2ti e− α ti dg(α) =∑ dα α3 i=1



h(βn )

Die Vorschrift für die Bestimmung von α ist von β abhängig und umgekehrt. Daher sind die gesuchten Parameter in einer gemeinsamen Newtonschen Iteration zu bestimmen. Man erhält die folgenden Ergebnisse: >

αˆ ≈ 2, 7384926 · 104

>

βˆ ≈ 1, 0073929

Die Summe der Fehlerquadrate der Weibullverteilung in bezug auf die Daten in Tab. 14.1 besitzt bei diesen Parameterwerten den Wert 2, 79702 · 10−3 . Die Weibullverteilung kann auf die vorliegenden Daten geringfügig besser angepasst werden, als die Exponentialverteilung. Das ist nicht überraschend, da die Exponentialverteilung einen Sonderfall der Weibullverteilung darstellt. Für β = 1 geht die Weibullverteilung in die Exponentialverteilung über. Die Ausfallrate λ der Exponentialverteilung entspricht dann dem Kehrwert des Parameters α der Weibullverteilung. Die Weibullverteilung kann daher immer mindestens genauso gut an eine Ausfallbeobachtung angepasst werden, wie die Exponentialverteilung. Im Regelfall gestattet der zusätzliche Freiheitsgrad, der durch den zusätzli-

14.5 Stochastische Software-Zuverlässigkeitsanalyse

465

chen Parameter β entsteht, eine bessere Anpassung. Dies gilt auch im vorliegenden Fall. Maximum-Likelihood-Anpassung

Das Maximum-Likelihood-Verfahren ist eine Technik zur Bestimmung der Parameter einer gegebenen Wahrscheinlichkeitsfunktion, so dass gegebene Daten approximiert werden. Es ist erforderlich, dass die Wahrscheinlichkeitsdichte bekannt ist. Ziel ist es, die freien Parameter so zu wählen, dass die Wahrscheinlichkeit maximiert wird, eine zur vorliegenden Beobachtung ähnliche Beobachtung zu erzeugen. Es ist unmöglich, eine der im Rahmen der Zuverlässigkeitsanalyse betrachtete bestimmte Beobachtung – also gegebene beobachtete Ausfallzeitpunkte – exakt zu reproduzieren. Die Ursache ist, dass eine kontinuierliche Verteilung vorliegt. Aus diesem Grund betrachtet man die Wahrscheinlichkeit, Ausfallzeiten nicht exakt, sondern mit einer tolerierbaren Abweichung Δt von den beobachteten Ausfallzeitpunkten zu erzeugen. Diese Wahrscheinlichkeit ist nicht gleich Null. Es ist zu erwarten, dass die Wahl des Zeitintervalls Δt die Bestimmung der Parameter beeinflusst. Dies wird jedoch vernachlässigt. Die so genannte Likelihood-Funktion ist das Produkt der Dichten an den beobachteten Ausfallzeitpunkten. Ihr Wert ist proportional zu der Wahrscheinlichkeit, Ausfallzeitpunkte zu beobachten, die von der vorliegenden Beobachtung maximal Δt abweichen. Die Likelihood-Funktion ist keine Zeitfunktion, sondern eine Funktion der festzulegenden Parameter der Verteilungsfunktion. Ziel des Verfahrens ist es, diejenigen Werte der Parameter dieser Funktion zu bestimmen, für die die Funktion maximal wird. Dies geschieht auf die übliche Weise durch Bildung der Ableitungen in bezug auf die zu bestimmenden Parameter und Bestimmung der Nullstellen. Im Folgenden wird der Parameter λ der Exponentialverteilung mit dem Maximum-Likelihood-Verfahren bestimmt: F(t) = 1 − e−λt , f (t) = λ e−λt Für die Likelihood-Funktion erhält man bei n beobachteten Ausfallzeiten t1 , ..., tn : L(λ ,t1 , ...,tn ) = f (λ ,t1 ) f (λ ,t2 ) ... f (λ ,tn ) = λ e−λt1 λ e−λt2 ...λ e−λtn n

n −λ (t1 +t2 +...+tn )

=λ e

=λ e n

−λ ∑ ti i=1

Aufgrund der Monotonie der Logarithmusfunktion besitzen L und ln L identische Maxima. n

ln L(λ ,t1 , ...,tn ) = n ln λ − λ ∑ ti i=1

Zur Bestimmung des Werts λˆ , der die Likelihood-Funktion maximiert, wird die Ableitung nach λ gebildet: n d(ln L(λ ,t1 , ...,tn )) n = − ∑ ti dλ λ i=1

466

14 Prüfen von eingebetteter Software

Der gesuchte Wert λˆ ist die Nullstelle. Bei der Exponentialverteilung liefert das Maximum-Likelihood-Verfahren für λˆ den Kehrwert des arithmetischen Mittelwerts der Ausfallzeitpunkte. n n n ! − ∑ ti = 0 ⇔ λˆ = n ˆλ i=1 ∑ ti i=1

14.5.4.2

Modellauswahl

Man könnte erwarten, dass die Modellauswahl vor der Kalibrierung stattfinden muss. Das ist aber nur eingeschränkt korrekt, weil dann das Modell auf Basis von Annahmen gewählt werden müsste. Ein alternativer Ansatz ist, alle in Frage kommenden Modelle zunächst einmal anhand von Ausfalldaten optimal – z. B. mit einem der beschriebenen Verfahren – zu kalibrieren und anschließend die Eignung der kalibrierten Modelle anhand der Ausfalldaten zu bewerten. Für die Bewertung der Modelleignung – also letztlich für die Modellauswahl – können unterschiedliche Verfahren eingesetzt werden. Das U-Plot-Verfahren ist ein graphisches Verfahren für die Überprüfung, ob eine betrachtete Verteilungsfunktion in bezug auf eine vorliegende Beobachtung akzeptiert werden kann. Der Vorteil ist die einfache Anwendbarkeit; der Nachteil die eventuell fehlende formale Begründung für die Wahl eines bestimmten Modells. Das Prequential-Likelihood-Verfahren ist geeignet, zwei betrachtete Verteilungsfunktionen in Bezug auf gegebene Ausfallbeobachtungen miteinander zu vergleichen. Es bewertet daher anders als das U-Plot-Verfahren die Eignung nicht absolut, sondern im Vergleich mit einem anderen Modell. Vorteilhaft ist die strenge Systematik des Verfahrens. Nachteilig ist der hohe Aufwand, den seine Durchführung erfordert. Ohne Werkzeugunterstützung ist das Prequential-Likelihood-Verfahren nicht anwendbar. Als weitere Alternative kann die Holdout-Bewertung verwendet werden. Sie verwendet nur einen Teil der Ausfalldaten zur Kalibrierung des Modells. Die verbleibenden Daten werden verwendet, um das so kalibrierte Modell zu bewerten. Man könnte z. B. die erste Hälfte der Daten für die Kalibrierung verwenden und die zweite Hälfte für die Bewertung. Man prüft einfach, wie gut das Modell auf Basis der ersten Hälfte der Daten die zweite Hälfte prognostiziert hätte. Der Vorteil dieses Verfahrens ist seine Einfachheit. Der Nachteil ist, dass man bei der Modellauswahl auf einen Teil der Ausfalldaten verzichtet. Die zur Bewertung nötigen Daten werden nicht zur Kalibrierung genutzt. Dies verkleinert die statistische Basis. Die drei Verfahren zur Auswahl von Modellen werden im Folgenden vertiefend erläutert. Das U-Plot-Verfahren nutzt die folgende Gesetzmäßigkeit: Falls eine Zufallsvariable T die Verteilung F(t) besitzt, so sind die U = F(ti ) der Realisierungen ti der Zufallsvariable über dem Intervall [0,1] gleichverteilt.

14.5 Stochastische Software-Zuverlässigkeitsanalyse

Verfahren zur Modellbewertung

U-Plot-Verfahren

467

Möchte man also beurteilen, ob eine Verteilungsfunktion zur Beschreibung von beobachteten Ausfallzeiten ti geeignet ist, so kann man die entsprechenden Werte Ui entsprechend der angegebenen Regel bestimmen und prüfen, ob sie hinreichend gleichverteilt über dem Intervall [0,1] sind. Dies geschieht beim U-Plot-Verfahren graphisch. Die n Werte Ui werden in einem Koordinatensystem folgendermaßen eingetragen. Die nach Größe sortierten Werte Ui werden als y-Werte so aufgetragen, dass der Wert Ui mit der Position j dem x-Wert j/n zugeordnet ist. Sind die Werte Ui in etwa gleichverteilt, so befinden sich die aufgetragenen Punkte in der Nähe der Funktion y = x, für 0 ≤ x ≤ 1.

BEISPIEL

Die in Tab. 14.1 dargestellten Werte für F(t) sind die Ui nach der oben angegebenen Definition. Ihre Darstellung im U-Plot ergibt das Diagramm in Abb. 14.12.

Abbildung 14.12 U-Plot der Daten aus Tab. 14.1

Die Daten scheinen recht zufriedenstellend in der Nähe der Funktion y = x zu liegen. Man wird die Exponentialverteilung mit Maximum-Likelihood-Anpassung, die für die Berechnung der dem U-Plot zugrunde liegenden Werte F(t) aus Tab. 14.1 verwendet wurde, als geeignete Verteilung akzeptieren. Dies ist eine Einschätzung, die allein aus der Betrachtung des U-Plots abgeleitet worden ist. Man kann die intuitive Bewertung durch eine systematischere Vorgehensweise ersetzen. So kann z. B. der Hypothesentest nach Kolmogoroff-Smirnov zum Testen der Hypothese verwendet werden, ob die im U-Plot aufgetragenen Ui durch die Funktion y = x geeignet beschrieben werden können. Das Maximum D der betragsmäßigen Abweichungen ΔUi der Ui von der Funktion y = x wird bestimmt. Bezeichnet man mit Ui ( j) den der x-Position j/n zugeordneten Wert Ui , so ist: D = maxi ΔUi = maxi |Ui ( j) − j/n|

468

14 Prüfen von eingebetteter Software

Abbildung 14.13 Das Prequential-Likelihood-Verfahren

Falls dieser Wert größer ist, als der den entsprechenden Kolmogoroff-Smirnov-Tabellen für das betrachtete Signifikanzniveau entnommene Wert, so wird die Hypothese abgelehnt. Die Verteilungsfunktion wird als ungeeignet betrachtet. Anderenfalls wird die Hypothese akzeptiert. Das Prequential-Likelihood-Verfahren ist geeignet, zwei betrachtete Verteilungsfunktionen in bezug auf gegebene Ausfallbeobachtungen zu bewerten. Es basiert auf dem folgenden Ansatz:

Prequential-Likelihood-Verfahren

Das Ausfallintervall t j ist eine Realisierung einer Zufallsvariable mit der Verteilung Fj (t) und der Dichte f j (t) (s. Abb. 14.13). Fj (t) und f j (t) sind unbekannt. Für jede der betrachteten Verteilungsfunktionen A und B kann die Dichte fˆjA (t) bzw. fˆjB (t) durch Anpassung der Verteilung auf Basis der Ausfallintervalle t1 ,... , t j−1 bestimmt werden. Falls – wie in Abb. 14.13 dargestellt – die Verteilung A besser geeignet ist als die Verteilung B, so ist zu erwarten, dass der Wert fˆjA (t j ) größer ist als der Wert fˆjB (t j ). Der Quotient fˆjA (t j ) fˆB (t j ) j

wird größer als 1 sein. Führt man diese Analyse nun für jedes beobachtete Ausfallzeitintervall t j ab dem Ausfallzeitintervall ts durch, so erhält man die so genannte Prequential-Likelihood-Ratio bezüglich der Verteilungen A und B: j=i

PLRAB i =∏

j=s

fˆjA (t j ) fˆB (t j ) j

Falls A eine geeignetere Verteilung als B in Bezug auf die vorliegenden Ausfalldaten ist, so weist die PLR eine ansteigende Tendenz auf. Dies kann graphisch durch Auftragen der PLR oder mit Hilfe geeigneter Trendtests geprüft werden.

14.5 Stochastische Software-Zuverlässigkeitsanalyse

469

Für die Zwischenankunftszeiten der Daten aus Tab. 14.1 wird ein Vergleich zwischen der Exponentialverteilung und der Normalverteilung mit Hilfe des Prequential-Likelihood-Verfahrens durchgeführt. Die Parameter der Verteilungen werden durch eine Maximum-Likelihood-Anpassung ermittelt. Für die Exponentialverteilung gilt: j−1 λˆ j = j−1 ∑ tk k=1

Für die Normalverteilung gilt: f (τ, σ 2 ,t) =

1 (2πσ 2 )

e

−(t−τ)2 2 σ 2

Die Parameter entsprechend der Maximum-Likelihood-Anpassung sind: j−1

τˆ j =

∑ tk

k=1

j−1

; σˆ 2j =

1 j−1 ∑ (tk − τ)2 j − 1 k=1

Tab. 14.2 gibt für die Daten aus Tab. 14.1 jeweils den Wert der Dichte der Exponentialverteilung und der Normalverteilung für die Zwischenankunftszeiten ti an, die aus den Ausfallzeitpunkten T1 bis Ti−1 berechnet worden sind. Um eine ausreichende Grundgesamtheit für die Parameterbestimmung sicherzustellen, werden die Werte erst ab dem vierten Ausfallzeitpunkt angegeben. Ferner ist der Logarithmus des Quotienten der Dichten und der Logarithmus der PLRi nach der angegebenen Definition aufgeführt. Der Anstieg der PLR (s. Abb. 14.14) weist darauf hin, dass die Annahme exponentialverteilter Zwischenankunftszeiten für die vorliegenden Daten sinnvoller ist, als die Annahme normalverteilter Zwischenankunftszeiten.

Tabelle 14.2 Prequential-Likelihood-Analyse

Holdout-Verfahren

470

Eine weitere Möglichkeit zur Bewertung der Eignung einer Verteilungsfunktion in bezug auf vorliegende Daten ist das Holdout-Verfahren. Es verwendet nur einen Teil der Ausfalldaten zur Bestimmung der Funktionsparameter. Die verbleibenden Daten werden verwendet, um die Eignung der so kalibrierten Funktion zur Beschreibung der Ausfalldaten zu bewerten. Als Eignungsmaß dient ein Kriterium, das die Abweichung der kalibrierten Verteilungsfunktion von der empirischen Verteilungsfunk-

14 Prüfen von eingebetteter Software

Abbildung 14.14 PLR der Daten aus Tab. 14.1

tion bewertet. Es kann z. B. die Summe der Fehlerquadrate verwendet werden. Passt man sowohl eine Exponentialverteilung als auch eine Weibullverteilung nach dem Verfahren der kleinsten Fehlerquadrate auf die ersten 6 Ausfallzeiten aus Tab. 14.1 an, so erhält man die folgenden Ergebnisse: Exponentialverteilung: −5 t

F(t)exp = 1 − e−3,89292·10

i /h

Weibullverteilung: −

F(t)weibull = 1 − e

0,94750 1 t /h 1,552005·104 i

Die Weibullverteilung besitzt – wie nicht anders zu erwarten – eine bessere Anpassung auf die Ausfallzeitpunkte T1 bis T6 . Die Summe der Fehlerquadrate für die ersten 6 Ausfallzeitpunkte beträgt 0,000459 gegenüber 0,000790 bei der Exponentialverteilung. Die Prognosequalität der Weibullverteilung ist jedoch schlechter als die der Exponentialverteilung. Die Summe der Fehlerquadrate für die prognostizierten Ausfallzeitpunkte T7 bis T10 beträgt bei der Weibullverteilung 0,00446; bei der Exponentialverteilung nur 0,00210. Man wird die Exponentialverteilung für Ausfallprognosen gegenüber der Weibullverteilung hier vorziehen.

14.5.5

Beispiel eines Modells: Musas elementares Ausführungszeiten-Modell

Das hier vorgestellte Zuverlässigkeitsmodell ist von /Musa et al. 87/ zur Modellierung von Software-Zuverlässigkeit vorgeschlagen worden. Ein Software-System fällt aufgrund von Fehlern in der Software zu zufälligen Zeitpunkten T1 , T2 , ... aus. Die Zeit wird in einem Maß erfasst, dass die Intensität der Benutzung der Software berücksichtigt. Man verwendet also nicht Kalenderzeit, sondern Ausführungszeit (z. B. CPU-Sekunden). Ferner geht dieses Modell von den folgenden Voraussetzungen aus:

14.5 Stochastische Software-Zuverlässigkeitsanalyse

Modellannahmen

471

Es wird angenommen, dass die Anzahl der in einem Zeitintervall Dt beobachteten Ausfälle linear proportional zur Anzahl der zu dieser Zeit in der Software vorhandenen Fehler ist. ACHTUNG: μ(t) bitte nicht mit der Rate μ aus Abschnitt 14.4.4 verwechseln.

μ(t) gibt für Zeiten t ≥ 0 die insgesamt bis zu diesem Zeitpunkt beobachtete Anzahl von Ausfällen an. μ(t) ist eine begrenzte, monoton steigende Funktion von t. Zum Zeitpunkt t = 0 sind keine Ausfälle beobachtet worden: μ(0) = 0. Für sehr lange Betriebszeit (t → ∞) ist μ(t) = a. a ist die Anzahl der insgesamt erwarteten Ausfälle. Es gibt andere Modelle, die eine unbegrenzte Ausfallanzahl annehmen. 14.5.5.1

Modellbildung

Die Anzahl der in einem Zeitintervall Δt beobachteten Ausfälle ist proportional zu Δt und zu der Anzahl der noch nicht entdeckten Fehler: μ(t + Δt) − μ(t) = b[a − μ(t)]Δt ⇒

μ(t + Δt) − μ(t) = ba − bμ(t) Δt

Mit Δt → 0 erhält man: dμ(t) = ba − bμ(t) = μ  (t) dt Mit μ(0) = 0 und μ(∞) = a erhält man: μ(t) = a(1 − e−bt ) Die Ausfallrate ist dann: λ (t) = μ  (t) = abe−bt Die Kurve für die akkumulierte Ausfallanzahl μ(t) nähert sich für große t asymptotisch der erwarteten Ausfallzahl a (Abb. 14.15). Die Kurve für die Ausfallrate λ (t) beginnt für t = 0 mit der Initial-Ausfallrate λ0 = ab und nähert sich asymptotisch dem Wert 0 (Abb. 14.14). Die Initial-Ausfallrate ist proportional zur erwarteten Ausfallanzahl a, mit der Proportionalitätskonstanten b. Die Ausfallrate λ kann als Funktion der bisher aufgetretenen Ausfälle μ dargestellt werden (Abb. 14.16): λ0

μ(t) = a(1 − e−bt ) = a(1 − e− a ) λ (t) = abe−bt = λ0 e−

λ0 a t

μ(t) = a(1 − e−bt ) = a(1 − e−

λ0 a

und λ (t) = abe−bt ⇒ e−bt =

λ (t) ab

Einsetzen ergibt: μ μ λ (t) ) ⇒ λμ = b(a − μ) = ab(1 − ) = λ0 (1 − ) ab a a Diese Gleichung entspricht der ursprünglichen Modellannahme, dass die Ausfallrate proportional zu der Anzahl der noch vorhandenen Fehler ist. Sie sinkt linear mit der Anzahl der beobachteten Ausfälle μ(t). μ(t) = a(1 −

472

14 Prüfen von eingebetteter Software

Abbildung 14.15 Ausfallanzahl und Ausfallrate

Abbildung 14.16 Ausfallrate als Funktion der Ausfälle

Falls λ die derzeitige Ausfallrate ist und für die Ausfallrate ein Ziel λz definiert ist, so müssen bis zur Erreichung dieses Ziels Δμ zusätzliche Ausfälle beobachtet und deren Ursachen behoben worden sein: λz λ λ − λz Δμ = μz − μ = a(1 − ) − a(1 − ) = a( ) λ0 λ0 λ0

Erreichung definierter Ziele

Die zusätzliche Zeit Δt bis zur Erreichung dieses Ziels ist: 

 

 a λz λ a λ λz Δt = tz − t = − ln − ln = ln − ln = λ λ λ λ λ λ 0 0 0 0 0 0

a λ ln λ0 λz Das vorgestellte Modell besitzt zwei Parameter, die für einen spezifischen Anwendungsfall bestimmt werden müssen: >

a: Die Gesamtzahl der beobachteten Ausfälle in unendlicher Zeit

>

λ0 : Die Ausfallrate zu Beginn

Bestimmung der Modellparameter

Der beste Weg zur Bestimmung dieser Modellparameter ist die Anpassung des Modells an eine Ausfallbeobachtung mit Hilfe eines der bereits

14.5 Stochastische Software-Zuverlässigkeitsanalyse

473

dargestellten Verfahren. /Musa et al. 87/ sehen aber auch eine Möglichkeit zur theoretischen Bestimmung der Modellparameter, die im Folgenden kurz dargestellt wird. In der Praxis ist die Gesamtzahl der für ein System erwarteten Ausfälle und Fehlverhalten in der Regel nicht bekannt. Einige hier nicht diskutierte Modellierungsverfahren basieren auf der Annahme, dass die Anzahl der Ausfälle eines Systems nicht begrenzt ist; also dass der gesuchte Wert nicht existiert. Für die Anwendung des vorgestellten elementaren Modells muss die Gesamtzahl der Ausfälle jedoch bestimmt werden. Zusammenhang zwischen Fehlern und Ausfällen

Empirische Daten zeigen ca. 5 % Folgefehler bei Fehlerkorrekturen.

Es ist falsch anzunehmen, dass die Anzahl der in einem System vorhandenen Fehler identisch zur Gesamtzahl der Ausfälle ist. So führt z. B. nicht jeder Ausfall zu einer Fehlerkorrektur. Dies kann aus verschiedenen Gründen der Fall sein: >

Zu teuer

>

Ursache nicht feststellbar

>

Tolerierbares Fehlverhalten

>

Mehrere Ausfälle aufgrund des gleichen Fehlers

>

Beziehungen zwischen Fehlern

Ferner ist davon auszugehen, dass bei einem Teil der Fehlerkorrekturen neue Fehler erzeugt werden. Das Verhältnis der tatsächlich netto korrigierten Fehler fk zu der bei unendlicher langer Ausführungszeit erwarteten Zahl der Ausfälle a ist: fk B= a /Musa et al. 87/ geben auf Basis empirischer Untersuchungen einen Erfahrungswert für B von 0,955 an, der nur die Erzeugung von Folgefehlern bei Fehlerkorrekturen erfasst. In etwa 5 % der Fälle führt eine Fehlerkorrektur demnach zu einem Folgefehler. Geht man davon aus, dass in unendlicher Zeit alle in der Software enthaltenen Fehler Ftotal aufgrund von Ausfällen erkannt und korrigiert werden, so sind bis zu diesem Zeitpunkt Ftotal B Ausfälle aufgetreten.

a=

Empirische Daten zum Fehlergehalt

474

In der Literatur finden sich empirische Daten zum Fehlergehalt von Software, die verwendet werden können, falls eigene Daten fehlen. Die in Tab. 14.3 aufgeführten Daten entstammen /Musa et al. 87/.

14 Prüfen von eingebetteter Software

Tabelle 14.3 Empirische Daten zum Fehlergehalt

Die Bestimmung der Ausfallrate zu Beginn ist einfacher als die Schätzung der Gesamtausfälle, da sie im Prinzip gemessen werden kann. Eine Schätzung kann nach /Musa et al. 87/ folgendermaßen durchgeführt werden: λ0 = f K Ftotal f=

Ausführungsgeschwindigkeit(Objektcode - Anweisung pro Zeiteinheit) Softwareumfang(Objektcode - Instruktionen)

Der Parameter K erfasst die folgenden Faktoren: >

Nicht jede (fehlerhafte) Anweisung wird bei jeder Programmausführung durchlaufen.

>

Nicht jede Ausführung einer fehlerhaften Anweisung führt zu einem Fehlverhalten, da die Fehlerwirkung z. B. an bestimmte Datenwerte gebunden ist.

K kann mit Hilfe der oben angegebenen Gleichung aus Erfahrungswerten mit ähnlichen Programmen bestimmt werden. /Musa et al. 87/ geben für K empirisch ermittelte Werte zwischen 1, 4 · 10−7 und 10, 6 · 10−7 an. 14.5.5.2

Beispiele für die Modellierung

Für das Programm mit einer insgesamt erwarteten Anzahl von 300 Ausfällen und einer initialen Ausfallrate von 0,01/CPU-Sekunde sind Modelle zu bilden. >

Anzahl des Ausfälle in Abhängigkeit der Ausführungszeit Mit welcher Anzahl von Ausfällen kann in Abhängigkeit der Ausführungszeit gerechnet werden. Einsetzen der Daten in die Formel für μ(t) auf Seite 472 ergibt die Kurve in Abb. 14.17.

>

Ausfallrate in Abhängigkeit der Ausführungszeit Wie wird sich die Ausfallrate in Abhängigkeit der Ausführungszeit

14.5 Stochastische Software-Zuverlässigkeitsanalyse

475

Abbildung 14.17 Ausfälle als Funktion der Zeit

Abbildung 14.18 Ausfallrate als Funktion der Zeit

entwickeln? Einsetzen der Daten in die Formel für λ (t) auf Seite 472 ergibt die Kurve in Abb. 14.18.

14.5.6 Eine Zuverlässigkeitsanalyse ohne geeignetes Werkzeug ist sinnlos.

476

Bewertung der stochastischen Software-Zuverlässigkeitsanalyse

Die Erfahrung zeigt, dass der kritische Aspekt der Software-Zuverlässigkeitsanalyse die Anwendung der Theorie ist. Es ist wichtig, dass Zuverlässigkeit leicht gemessen und prognostiziert werden kann, ohne dass der

14 Prüfen von eingebetteter Software

Anwender den theoretischen Hintergrund vollständig verstehen muss. Fast die gesamte hier dargestellte Theorie kann in einem Werkzeug so gekapselt werden, dass die Verfahren unabhängig von der Beherrschung ihrer theoretischen Grundlagen angewendet werden können. Die im Folgenden geschilderten Erfahrungen basieren auf Industrieprojekten für die das Werkzeug RAT (Reliability Assessment Tool) eingesetzt wurde /Liggesmeyer, Ackermann 98/. Dieses Werkzeug unterstützt mehrere Zuverlässigkeitsmodelle, um eine gewisse Breite von Situationen abzudecken. Die Erfahrung zeigt, dass es manchmal nicht sinnvoll ist, die Auswahl des zu verwendenden Modells allein dem Werkzeug zu überlassen. Eine Vorauswahl der in Frage kommenden Modelle ist in einigen Situationen günstig. Die Auswahl bestimmter Modellklassen produziert oft bessere Ergebnisse. In einigen Fällen ist es z. B. möglich, a priori zu entscheiden, ob ein Modell mit einer begrenzten Ausfallanzahl angemessen ist oder ob ein Modell mit einer unendlichen Ausfallanzahl verwendet werden sollte. Die Qualität der Ausfalldaten ist der wichtigste Einflussfaktor für die Verlässlichkeit der Zuverlässigkeitsanalysen. Häufig sind die Daten verrauscht oder enthalten systematische Störungen. Dennoch ist es oft möglich, diese Daten als Basis für Zuverlässigkeitsanalysen zu verwenden. Dies erfordert eine Analyse und Korrektur der Ausfalldaten. Das umfasst die Entfernung von Instabilitäten, die oft zu Beginn eines Datensatzes auftreten. Obwohl Modelle existieren, die Einschwingverhalten beschreiben können, ist deren Verwendung nicht in jedem Fall angebracht. Wenn Einschwingvorgänge zu Beginn von Datensätzen klar erkennbar sind, ist es sinnvoll, diese Daten zu entfernen. Wenn der Testaufwand oder die Installationszahlen variieren, muss auch dies korrigiert werden.

Eine Modellvorauswahl ist gegebenenfalls sinnvoll.

Datenkorrektur ist wichtig

Die Verwendung von Ausfallprioritäten hat sich besonders in großen Entwicklungen bewährt. Dort ist der Test oft durch die verfügbaren Ressourcen limitiert. Daher konzentrieren sich die Tester zu Testbeginn oft auf Ausfälle mit hoher Priorität. Wenn das System in bezug auf solche Ausfälle stabiler wird, werden Ressourcen frei, um auch Ausfälle mit niedrigerer Priorität zu bearbeiten. Es kommt vor, dass bei nahezu unveränderter Ausfallhäufigkeit des Systems die Häufigkeit der Ausfälle mit hoher Priorität abnimmt, was durch eine Häufigkeitszunahme der Ausfälle mit niedriger Priorität kompensiert wird. Die Gesamtausfälle sind in einem derartigen Fall für Zuverlässigkeitsanalysen ungeeignet, da die Häufigkeit der Ausfälle mit niedriger Priorität nicht durch die Zuverlässigkeit des Systems bestimmt wird. Sie wird von den verfügbaren Testressourcen festgelegt. Entscheidend ist jedoch die Zuverlässigkeit in bezug auf Ausfälle mit hoher Priorität. Da deren Häufigkeit durch Veränderungen der Systemzuverlässigkeit bestimmt ist, können diese Ausfälle mit Hilfe von Zuverlässigkeitsmodellen prognostiziert werden. Voraussetzung ist, dass die Prioritäteneinteilung verlässlich ist.

Oft ermöglicht erst die Unterscheidung von Ausfallprioritäten sinnvolle Aussagen.

Ausfalldaten werden in der Regel auf Basis von Kalenderzeit erfasst. Dies ist nachteilig für die Zuverlässigkeitsanalyse, falls die Beziehung zwi-

Die Kalenderzeit ist meistens keine geeignete Bezugsgröße.

14.5 Stochastische Software-Zuverlässigkeitsanalyse

477

schen Kalenderzeit und Ausführungszeit nicht linear ist. Wenn der nichtlineare Zusammenhang einfach ist, können die Daten entsprechend korrigiert werden. Ein Beispiel für eine derartige einfache Nichtlinearität sind Muster in den Ausfalldaten die durch den Wechsel von Arbeitstagen und Wochenenden zustande kommen. Falls an den Wochenenden keine Tests durchgeführt werden, so sollten die Wochenenden aus dem Datensatz entfernt werden. Aber dies muss mit Vorsicht durchgeführt werden, weil insbesondere am Ende des Systemtests in Folge von Zeitdruck möglicherweise Tests auch am Wochenende durchgeführt werden. Ein anderes Beispiel für Zeiten ohne Tests können Feiertage sein. Veränderte Testintensitäten sind nicht immer einfach erkennbar. Normalerweise wird die Ausführungszeit nicht erfasst. Bei der Verwendung von Ausfalldaten aus dem Feld zur Zuverlässigkeitsmodellierung ist die Korrektur veränderlicher Installationszahlen wichtig. Diese sind normalerweise verfügbar. Die hier beschriebenen stochastischen Zuverlässigkeitsanalysetechniken bieten die Möglichkeit zur quantitativen Ermittlung und Prognose von Zuverlässigkeitskennwerten (z. B. Ausfallanzahl, Ausfallrate) auf Basis beobachteter Ausfälle. Darüber hinaus gestattet die Verwendung automatisierter stochastischer Verfahren zur Modellbewertung und -kalibrierung dem Praktiker die unkomplizierte Anwendung der recht anspruchsvollen Theorie, ohne zuvor ein vollständiges Verständnis der theoretischen Hintergründe erwerben zu müssen. Die Nutzung des Ansatzes im Systemtest ermöglicht z. B. eine Kostenreduktion durch frühzeitige Ermittlung des erforderlichen Prüfaufwands zur Erreichung der gewünschten Zuverlässigkeit zum Freigabetermin. Es ist möglich, die Ressourcen so zu planen, dass das System exakt zum geplanten Termin die erforderliche Qualität besitzt. Darüber hinaus steht ein statistisch abgesichertes Kriterium für die Freigabeentscheidung zur Verfügung. Das vermeidet zu hohe Prüfkosten durch eine zu umfassende Prüfung und zu hohe Wartungskosten durch eine zu geringe Qualität. Darüber hinaus ist eine optimale Ressourcenplanung für die Wartung möglich sowie ein statistisch abgesicherter Qualitätsnachweis gegenüber Kunden.

14.6 Dynamisches Testen ist auch für eingebettete Software wichtig.

478

Bewertung des Prüfens von eingebetteter Software

Dynamisches Testen spielt auch für die Prüfung eingebetteter Software eine Hauptrolle. Für den Test können die konventionellen funktions- und strukturorientierten Techniken verwendet werden. Ergänzend können die dargestellten speziellen Testtechniken für diesen Anwendungsbereich genutzt werden, z. B. der Back to Back-Test. Formale Techniken besitzen eine gewisse Verbreitung, sind aber nicht flächendeckend im Einsatz.

14 Prüfen von eingebetteter Software

Ein formaler Korrektheitsbeweis wird für ein größeres Software-System nur in Ausnahmefällen möglich und sinnvoll sein. In der Praxis trennt man häufig unkritische und kritische Software-Komponenten. Die unkritischen Komponenten werden getestet. Die kritischen Software-Module werden getestet und formal verifiziert. Ein geeigneter Test kann durch eine statistische Auswertung der beim Test gemachten Beobachtungen – der Ausfallzeitpunkte – dazu dienen, statistisch abgesicherte Zuverlässigkeitsaussagen zu gewinnen. Systematische Risikoanalysen mit einer FMECA und modellierende Sicherheitsanalysen mit Fehlerbäumen oder Markov-Modellen sind bei der Prüfung technischer Systeme und sicherheitskritischer eingebetteter Software unverzichtbar.

>

Prüfen Sie, ob es Standards für Ihren Anwendungsbereich gibt, die Ihnen die Nutzung bestimmter Techniken vorschreiben.

>

Sie sollten die FMECA mindestens für Ihr System und die bei der System-FMECA erkannten kritischen Komponenten durchführen.

>

Falls Sie sicherheitskritische Software entwickeln, so sollen Sie die Durchführung von Fehlerbaumanalysen oder die MarkovModellierung erwägen.

>

Wenn sie verlässliche Aussagen zur Zuverlässigkeit von Software benötigen, so sind stochastische Zuverlässigkeitsanalysen ein geeignetes Hilfsmittel, diese zu erzeugen.

>

Verwenden Sie unterstützende Werkzeuge für die genannten Techniken.

14.6 Bewertung des Prüfens von eingebetteter Software

Modellbasierte Ansätze sind Stand der Technik.

CHECKLISTE

479

“This page left intentionally blank.”

15 Ein Praxisleitfaden Die Vielzahl der organisatorischen und technischen Ansätze für die SoftwarePrüfung erfordert die zielgerichtete Identifikation einer praxisgeeigneten Lösung, die anschließend eingeführt werden muss. Im Folgenden werden wichtige Hinweise aus den Kapiteln dieses Buches zusammenfassend dargestellt. Darüber hinaus wird eine einfache praxisgeeignete Prüfstrategie vorgeschlagen. Sie erfüllt alle notwendigen Forderungen in Bezug auf die Prüfung „gewöhnlicher“ Software; also von Software, die keine ungewöhnlich hohen Sicherheits- oder Zuverlässigkeitsanforderungen erfüllen muss, und für die Standards keine speziellen Prüfungen vorschreiben. Ihre praktische Nutzung sollte durch die Sammlung von Informationen ergänzt werden, die zur Optimierung der Prüfstrategie in einem zweiten Schritt dienen können. Die zu beachtenden Einflussfaktoren werden dargestellt und diskutiert.

Übersicht 15.1

Organisatorische Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

15.2

Technische Hinweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

15.3

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 Checkliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490

481

15.1 Eine geeignete Organisation vereint in der Regel Prinzipien des TQM und der klassischen Qualitätssicherung.

Ein ISO 9001-Zertifikat wird als notwendig, aber nicht als hinreichend betrachtet.

Die Betrachtung von Standards ist wichtig.

482

Organisatorische Hinweise

Methoden, Techniken und Werkzeuge benötigen einen organisatorischen Rahmen, in den sie eingebettet sind. Ein geeigneter organisatorischer Prüfrahmen erfordert Techniken, die es gestatten, ihn mit praktischen Tätigkeiten zu füllen. Für die übergeordnete Organisation des Qualitätsmanagements bzw. der Qualitätssicherung sollte ein geeigneter Kompromiss aus der Verteilung der Verantwortung (TQM) und der zentralen Qualitätsverantwortung (klassische Qualitätssicherung) erzielt werden. Eine Qualitätskontrolle im Sinne der klassischen Qualitätssicherung wird insbesondere in kritischen Software-Anwendungsbereichen unverzichtbar sein. Eine auf Qualität fokussierte Entwicklung im Sinne von TQM ist ebenfalls unverzichtbar. Entscheidend für das Funktionieren dieses Konzepts ist die Schaffung organisatorischer und technischer Rahmenbedingungen, die es den Mitarbeitern gestatten, die vorgesehenen Tätigkeiten durchzuführen. Für die Entwicklungs- und Prüfprozesse in der Software-Entwicklung ist eine Zertifizierung nach DIN EN ISO 9001 als Stand der Technik und im Wesentlichen auch als Stand der Praxis zu betrachten. In anspruchsvollen Entwicklungen besitzt dieses Zertifikat den Charakter einer Notwendigkeit. Als hinreichend wird es in der Regel nicht gesehen. Viele Unternehmen verwenden Software-Prozess-Assessments als Mittel zur gezielten Prozessverbesserung. Die empirischen Daten zeigen, dass die erzielten Verbesserungen den Aufwand für die Verbesserungsmaßnahmen rechtfertigen. In einigen Anwendungsbereichen existieren explizite Standards für die einzuhaltenden Prozesse. Hier ist insbesondere die Verpflichtung zur Nutzung des Vorgehensmodells der Bundesverwaltung für Software-Entwicklungen des Bundes zu nennen. Für einige Anwendungsbereiche existieren Erweiterungen allgemeinerer Standards. So sind einige Erweiterungen der ISO 9000-Reihe für spezielle Anwendungsbereiche zu finden. Die so genannten AQAP-Century-Standards sind eine solche Erweiterung für militärische Software-Entwicklungen in der NATO. Standards sind wichtig, um verbindliche oder allgemein akzeptierte Forderungen zu identifizieren. Neben prozessorientierten Standards existieren anwendungsbereichspezifische und anwendungsbereichunabhängige technische Standards. Es ist wichtig, die in den jeweiligen Anwendungsbereich einsetzbaren Standards zu kennen und zu berücksichtigen. Software-Entwicklung und -Prüfung findet heute im Allgemeinen stark arbeitsteilig statt. Viele Prozessmodelle sehen explizite Phasen innerhalb der Software-Entwicklung vor. Dies gilt sowohl für die Software-Entwicklung wie auch für die Software-Qualitätssicherung. Für die Durchführung der Software-Prüfung in Phasen ist eine modulare Struktur der Software eine wichtige Voraussetzung. Es ist daher in der Entwicklung sicherzustellen, dass die Software modular mit präzis definierten Schnittstellen entwickelt wird, und die entsprechenden Entwicklungsdokumente als Prüfreferenz für die Überprüfung der Software zur Verfügung stehen.

15 Ein Praxisleitfaden

15.2

Technische Hinweise

In der Software-Prüfung besitzen informale Techniken die weiteste Verbreitung. Typische Stellvertreter dieser Kategorie sind dynamische Testtechniken sowie Inspektions- und Reviewtechniken. Formale und stochastische, analytische Prüftechniken sind in der Software-Entwicklung nicht weit verbreitet. Abb. 15.1 zeigt eine Einordnung der Techniken nach wichtigen Eigenschaften. umfangreich Systematischer dynamischer Test

Stochastische Zuverlässigkeitsanalyse stochastisch

Symbolic Model Checking

informal formal Inspektion Korrektheitsbeweis klein einfach universell unvollständig

kompliziert speziell vollständig

Abbildung 15.1 Einordnung von Prüftechniken

Wesentliche Vorteile der informalen Qualitätssicherungstechniken sind ihre Einfachheit und universelle Anwendbarkeit. Mit systematischen, dynamischen Tests können außerdem umfangreiche Softwaresysteme geprüft werden, während Inspektionstechniken nur bei kleineren bis mittleren Umfängen anwendbar sind. Der Hauptnachteil informaler Qualitätssicherungstechniken ist die Unvollständigkeit der erzeugten Ergebnisse. Auch systematische, dynamische Tests schließen Restfehler in der Software nicht aus. Das Gleiche gilt für Inspektionstechniken. Die Ergebnisse sind weder vollständig, noch ist das durch die Restfehler erzeugte Risiko bekannt. Dies ist insbesondere in sicherheitskritischen Software-Anwendungsbereichen oft nicht akzeptabel.

Informale Prüftechniken sind einfach und universell einsetzbar, liefern aber keine vollständigen Ergebnisse.

Formale Techniken liefern vollständige Ergebnisse. Nachteilig ist, dass formale Techniken kompliziert sind und nur in speziellen Anwendungsbereichen eingesetzt werden können. Die Anwendung formaler Qualitätssicherungstechniken auf alle Teile eines umfangreichen Software-Systems ist kaum möglich.

Formale Prüftechniken liefern vollständige Ergebnisse, sind aber kompliziert und speziell.

Einen interessanten Kompromiss zwischen den Eigenschaften informaler und formaler Techniken bilden die so genannten stochastischen Qualitätssicherungstechniken. Sie liefern quantifizierte Ergebnisse, die z. B. zur Bestimmung des Restrisikos dienen können. Stochastische Tech-

Stochastische Techniken liefern quantifizierte Ergebnisse und sind auf umfangreiche Software anwendbar.

15.2 Technische Hinweise

483

niken werten Beobachtungen (z. B. Ausfälle) mit statistischen Verfahren aus. Daher profitieren sie von großen Software-Umfängen, bei denen zahlreiche auswertbare Beobachtungen vorliegen. Zur Zeit besitzen stochastische Qualitätssicherungstechniken keine weite Verbreitung in der Praxis der Software-Entwicklung. Stand der Praxis

Systematische, dynamische Tests und bestimmte statische Analysen müssen als weitgehender Stand der Praxis gesehen werden. Insbesondere für kritische Software-Entwicklungen ist eine Kombination von Techniken aus beiden Bereichen unerlässlich. Formale Techniken und symbolische Ausführung sind in der praktischen Anwendbarkeit auf Sonderfälle beschränkt. Sie können nicht als Stand der Praxis gelten. So erfordert der Einsatz formaler Techniken einen dementsprechenden Spezifikations- und Programmierprozess und eine starke Einschränkung der verwendeten Konstrukte bei modernen Programmiersprachen. Formale Techniken sind daher keine wirkliche Alternative zu dynamischen Tests. Sie sind darüber hinaus nicht in der Lage, Aussagen über das Zeitverhalten zu liefern sowie Probleme in der Interaktion zwischen der betrachteten Software und der Umgebung zu erkennen. Das gleiche gilt in modifizierter Form für die symbolische Ausführung.

Minimalanforderungen

Als absolut notwendig wird konsistent von allen maßgeblichen Standards eine funktionsorientierte Vorgehensweise beim dynamischen Test gefordert. Dies gilt für alle Testphasen. Es gibt keine verbindliche Vorgabe für die einzusetzende funktionsorientierte Technik. Im Regelfall wird man eine funktionale Äquivalentsklassenbildung oder einen zustandsbasierten Test wählen. Obwohl einige Standards diese Vorgehensweise als ausreichend bewerten, wird sie in der Fachwelt oft als unzureichend gesehen. Ein funktionsorientierter Test garantiert keine vollständige Abdeckung des Programmcodes durch Testfälle. Es gibt einen weitgehenden Konsens, dass daher ergänzend zum funktionsorientierten Test eine strukturorientierte Abdeckung erzielt werden muss. Als minimal notwendige, strukturierte Testtechnik gilt der so genannte Zweigüberdeckungstest. In kritischen Anwendungsbereichen – z. B. der Avionik – werden darüber hinaus durch Standards explizit gründlichere strukturorientierte Tests gefordert. Der im Bereich der Avionik anzuwendende Standard RTCA/DO-178B fordert z. B. für Software der höchsten Kritikalitätsklasse die Durchführung eines bestimmten Bedingungsüberdeckungstests (Modified Condition Decision Coverage). In Anwendungsbereichen, in denen Standards keine expliziten Forderungen an strukturorientiertes Testen stellen, sollte der Zweigüberdeckungstest als allgemein akzeptiertes Minimalkriterium verwendet werden. Ein sinnvoller strukturorientierter Test wird stets werkzeugunterstützt durchgeführt. Strukturorientierte Tests eignen sich zur Definition eines firmeninternen Vollständigkeitskriteriums für den Test. Strukturorientierte, dynamische Tests werden in der Regel einmalig durchgeführt und zwar möglichst in der ersten Testphase nach Fertig-

484

15 Ein Praxisleitfaden

stellung des Codes (Modultest). Funktionsorientierte, dynamische Tests werden in jeder Testphase unter Beachtung jeweils geänderter Aspekte durchgeführt. Die Reproduzierbarkeit von Testergebnissen wird von diversen Standards gefordert. In der Regel müssen Testfälle nach Software-Modifikationen und -Erweiterungen wiederholt werden. In diesem Zusammenhang sind automatische Regressionstests als Stand der Technik einzustufen. Für viele Unternehmen sind sie bereits Stand der Praxis. Ebenfalls als Stand der Praxis sind so genannte Leistungs- und Stresstests zu sehen. Beide werden durch einschlägige Standards insbesondere im technischen Bereich gefordert. Ihre Durchführung setzt im Regelfall die Verwendung entsprechender Werkzeuge voraus.

Regressionstests

Im Bereich der statischen Analyse muss insbesondere die Nutzung von Reviewtechniken als Stand der Praxis betrachtet werden. Dies gilt besonders für die informalen Reviews. Formale Inspektionen sind noch nicht flächendeckender Stand der Praxis. Sie werden aber zunehmend von reifen Unternehmen genutzt.

Reviewtechniken

Die Nutzung von Zusicherungstechniken ist unkompliziert möglich und besitzt – nicht nur für die Testdurchführung – zahlreiche Vorteile. Zusicherungen sind Sprachbestandteil in einigen modernen Programmiersprachen. Ihre Nutzung ist daher oft mit wenig Aufwand möglich.

Zusicherungen

Insbesondere für Programmiersprachen der C-Familie sollten Programmierkonventionen genutzt werden. Einige Standards schreiben das insbesondere für sicherheitskritische Software-Entwicklungen verbindlich vor. Es gibt Werkzeuge, die die Einhaltung von Programmierkonventionen prüfen.

Programmierkonventionen

Schließlich sollte die Datenflussanomalieanalyse genutzt werden. Sie spürt bestimmte Fehler mit sehr wenig Aufwand sicher auf. Einige der durch diese Fehler hervorgerufenen Fehlverhalten sind nicht einwandfrei reproduzierbar. Der dynamische Test besitzt daher eine geringere Eignung zu ihrer Erkennung als die statische Datenflussanomalieanalyse.

Datenflussanomalieanalyse

Für Analysen im Bereich eingebetteter Software sind Fehlerbaumtechniken und die FMECA als Stand der Technik zu betrachten.

Fehlerbäume und FMECA

15.2.1

Eine einfache praxisgeeignete Prüfstrategie

Im Folgenden wird eine einfache praxisgeeignete Prüfstrategie vorgeschlagen, die die Minimalkriterien der Software-Prüfung in einem „gewöhnlichen“ Kontext befriedigt. Sie kann als einfacher, ausbaufähiger Einstieg in den Bereich des systematischen Software-Tests empfohlen werden. Sie sieht eine funktionsorientierte Testdurchführung in allen Testphasen vor. Ergänzend tritt ein Zweigüberdeckungstest in der Phase

15.2 Technische Hinweise

Ein einfacher Einstieg in die systematische Prüfung

485

Modultest hinzu. Darüber hinaus ist sie durch Infrastrukturmaßnahmen zu ergänzen. Eine Kombination aus funktions- und strukturorientiertem Test im Modultest

Für den Modultest wird die folgende Vorgehensweise empfohlen: Es ist eine funktionsorientierte Testplanung unter Verwendung einer geeigneten systematischen funktionsorientierten Testtechnik durchzuführen. Vor der Durchführung der funktionsorientierten Testfälle ist das zu testende Modul unter die Kontrolle eines Zweigüberdeckungstest-Werkzeugs zu bringen. Dieses Werkzeug kann bei der Durchführung von Testfällen die erreichte Zweigüberdeckungsrate aufzeichnen. Die funktionsorientiert geplanten Testfälle werden nun vollständig durchgeführt. Anschließend kann die auf diese Weise erreichte Zweigüberdeckung mit dem Zweigüberdeckungstest-Werkzeug kontrolliert werden. In der klassischen funktional dekomponierenden Software-Entwicklung kann erfahrungsgemäß eine Zweigüberdeckung von circa 70 % bis 80 % erwartet werden. Anschließend werden die Ursachen der nicht ausgeführten Zweige ermittelt. Falls die Ursache eine ungeeignete funktionsorientierte Testplanung ist, so kann diese nachgebessert werden. Sonst werden für die noch nicht ausgeführten Zweige Testdaten erzeugt, durchgeführt und anschließend die erreichte Überdeckung kontrolliert. Diese Vorgehensweise für den Modultest gewährleistet eine funktionsorientierte Testplanung und die Erreichung der minimal akzeptierten Zweigüberdeckung. Die funktionsorientierten Testläufe werden zur Steigerung der Zweigüberdeckungsrate verwendet. Strukturorientiert werden nur jene Testfälle durchgeführt, die nicht funktionsorientiert bereits erreicht wurden. Daher ist diese Herangehensweise frei von Redundanzen. Das für die Testdurchführung erforderliche Zweigüberdeckungstest-Werkzeug ist leicht zu beschaffen. Aufgrund der zahlreich angebotenen Werkzeuge sind keine unangemessen hohen Beschaffungskosten zu erwarten.

Funktionsorientiertes Testen im Integrations- und Systemtest

Für den Integrations- und Systemtest reicht eine rein funktionsorientierte Testplanung und Testdurchführung aus. Eine erneute Messung strukturorientierter Abdeckungen ist nicht zwingend erforderlich.

Fehleraufzeichnung

Die einfache praxisgeeignete Prüfstrategie ist durch einige Infrastrukturmaßnahmen zu ergänzen. Es ist besonders wichtig, eine geeignete Fehleraufzeichnung einzuführen. Hinweise zu ihren Inhalten sind in Kapitel 11 enthalten. Diese Fehleraufzeichnung dient insbesondere zur Kontrolle des Funktionierens der Prüfstrategie und zu ihrer Nachbesserung. Fehlerhäufungen können erkannt und gezielt behoben werden.

Automatisierte Regressionstests

Darüber hinaus ist die Automatisierung von Regressionstests eine wichtige Maßnahme, die unabhängig von der Prüfstrategie umgesetzt werden kann. Die Automatisierung von Regressionstests erfordert insbesondere die Identifikation, Beschaffung und Nutzung eines geeigneten Werkzeugs.

486

15 Ein Praxisleitfaden

Als weitere Maßnahmen sind die Nutzung von Zusicherungen, die Durchführung von Datenflussanomalieanalysen und die Einführung von Programmierkonventionen zu nennen. Diese Maßnahmen sind ebenfalls unabhängig von der eingesetzten Prüfstrategie und können daher getrennt eingeführt werden. Im Regelfall ist die geschilderte einfache praxisgeeignete Prüfstrategie ein geeigneter Weg von unsystematischen Prüfungen hin zu systematischen Testtechniken. Sie erfüllt alle notwendigen Anforderungen. In Anwendungsbereichen, in denen spezifische, zusätzliche Anforderungen existieren, kann eine entsprechende Ergänzung vorgenommen werden. Für die Nutzung spezifischer, leistungsfähigerer Prüftechniken sind weitergehende Informationen erforderlich, die in einer Organisation, die bislang unsystematisch geprüft hat, oft nicht verfügbar sind. Diese zusätzlichen Informationen werden z. B. in Form der Fehlerdokumentation parallel zur Nutzung der hier beschriebenen einfachen Technik erhoben. Anschließend kann die einfache Technik ergänzt werden. Dies kann auf Basis der dann vorhandenen Information zielgerichtet geschehen. Die Migrationstrategie vom unsystematischen Test zum spezifisch für die Prüfsituation geeigneten, leistungsfähigen, systematischen Test sieht als Zwischenschritt einen universell geeigneten systematischen Test vor, der die notwendigen Anforderungen erfüllt. Es ist zu erwarten, dass diese „Politik der kleinen Schritte“ erfolgversprechender sein wird als der Versuch, die spezifisch geeignete Prüfstrategie in einem Schritt einzuführen.

15.2.2

Zusätzliche Maßnahmen

Beachtung spezieller Anforderungen

Die Bildung einer spezifisch für eine Organisation geeigneten Prüfstrategie in der Praxis erfordert die Berücksichtigung zahlreicher Einflussfaktoren. Neben der Erfüllung von Minimalkriterien ist die Orientierung der Prüfung an den spezifischen Merkmalen der Prüfsituation zu beachten. Die Merkmale der Prüfsituation werden durch die Art der Software, die angestrebten Ziele, spezifische Merkmale des Codes, die zu erreichenden Qualitätsziele und weitere Rahmenbedingungen definiert. Darüber hinaus ist die Verfügbarkeit geeigneter Werkzeuge unter Beachtung der Hardwareplattform, der verwendeten Programmiersprache sowie des Betriebssystems und weiterer Systemsoftware zu berücksichtigen. Schließlich ist die Wirtschaftlichkeit der Prüfung ein wesentliches Kriterium. Weitere Einflussfaktoren sind die Expertise der Qualitätssicherer und die vorgesehene Zielgruppe, die die Prüfung durchführen soll.

Eine geeignete Prüfstrategie muss zahlreiche Einflussfaktoren beachten.

Die Ausrichtung der Prüfung auf die spezifischen Merkmale der Prüfsituation erfordert eine genaue Kenntnis der Eigenschaften der Prüftechniken und der Rahmenbedingungen der Prüfsituation. Insbesondere die Rahmenbedingungen der Prüfsituation werden in einer bislang eher unsystematisch arbeitenden Organisation nicht vollständig bekannt sein. Daher wird auch hier noch einmal empfohlen, zunächst eine einfache Lö-

Technische Rahmenbedingungen

15.2 Technische Hinweise

487

sung einzuführen und parallel dazu die erforderlichen Informationen für eine Nachbesserung zu beschaffen. Die Art der Software beeinflusst die Eignung von Prüftechniken nachhaltig. So werden z. B. an die Prüfung sicherheitskritischer Steuerungssoftware in der Regel strengere Forderungen gestellt als an die Prüfung kaufmännischer Software. Für die spezifische Auswahl bestimmter Prüftechniken sind Fehlerprognosen hilfreich. Viele Prüftechniken erkennen Fehler bestimmter Fehlertypen verstärkt und andere nur unzuverlässig. Eine sinnvolle Auswahl von Prüfverfahren setzt daher eine Fehlerprognose voraus. Diese Fehlerprognose kann geeignet auf Basis von Fehleraufzeichnungen erstellt werden. In der Regel wird man eine Kombination von Prüfverfahren wählen. Hier ist insbesondere die Kombination dynamischer Testtechniken mit statischen Analysen oder die Kombination dynamischer Testtechniken mit formalen Beweisverfahren sinnvoll. Aufgrund der existierenden Rahmenbedingungen wird man in vielen Fällen der erstgenannten Kombination den Vorzug geben. Details zur Verfügbarkeit geeigneter Werkzeuge sind in Kapitel 12 enthalten. Zu einigen Techniken sind zahlreiche Werkzeuge verfügbar, während für andere Techniken kaum Werkzeugunterstützung geboten wird. Im Bereich der strukturorientierten Testwerkzeuge wird insbesondere sehr viel Werkzeugunterstützung für den Zweigüberdeckungstest angeboten. Datenflussorientierte Testtechniken werden kaum unterstützt. Insgesamt ist die Abdeckung mit Testwerkzeugen zufriedenstellend. Die Tendenz zur Durchführung des Modultests auf Standardrechnern begünstigt die Identifikation eines geeigneten Testwerkzeugs. Der Integrations- und Systemtest werden in der Regel funktionsorientiert durchgeführt. Daher sind hier keine strukturorientierten Testwerkzeuge erforderlich. Die insbesondere für den Systemtest erforderlichen Regressionstest-Werkzeuge und Lastgeneratoren sind verfügbar. Sie sind in der Regel sprachunabhängig. Wirtschaftliche Rahmenbedingungen

488

Die Wirtschaftlichkeit der Prüfung entscheidet wesentlich, welche Testtechniken eingesetzt werden können. Eine Prüfung ist umso wirtschaftlicher, je redundanzfreier und damit angepasster sie an die Prüfsituation ist. Es ist wichtig, die Auswirkungen der Einführung neuer Techniken, Methoden und Werkzeuge durch Mitführen entsprechender Maßzahlen zu verdeutlichen. Eine Kosten- und Aufwandsverfolgung existiert im Rahmen des Projekt-Controllings in der Regel bereits. Entscheidend ist die Einführung einer Fehleraufzeichnung, um Auswirkungen neuer Techniken, Methoden und Werkzeuge verdeutlichen zu können. Einsparungen im Bereich der Fehlerkorrekturkosten können den Investitionen in Techniken, Methoden und Werkzeuge gegengerechnet werden. Bei der Beurteilung von Prüfverfahren ist insbesondere zu beachten, dass leistungsfähigere, komplexe Prüfverfahren in der Regel einen deutlich höheren Prüfaufwand verursachen. Es ist besser eine einfache systematische Prüfstrategie einzusetzen als eine vermeintlich leistungsfähigere Prüfstrategie aus Aufwandsgründen nicht durchzuhalten.

15 Ein Praxisleitfaden

Entscheidend für den Erfolg von Prüfungen ist die Expertise der Personen, die die Prüfung durchführen. Viele Aufgaben während der Prüfung erfordern methodische Kenntnisse und Erfahrungswissen. Beispiele sind die Erzeugung sinnvoller Testdaten, die Interpretation der Testergebnisse, die Beurteilung von Messwerten oder das Finden von Schleifeninvarianten bei formalen Verifikationen. Daher ist es wichtig, diesen Personenkreis gezielt weiterzubilden. Der Aufbau der erforderlichen Expertise ist eine der wichtigsten Voraussetzungen für den Erfolg.

Personelle Rahmenbedingungen

Darüber hinaus ist es erforderlich, die Zielgruppe zu berücksichtigen. Falls z. B. die Programmierer in den Modultest involviert sind, so ist dafür Sorge zu tragen, dass die Testinfrastruktur nicht als Belastung empfunden wird. Es sollten Prüftechniken und unterstützende Werkzeuge eingesetzt werden, die unkompliziert genutzt werden können und keine zu komplexe Ergebnisinterpretation erfordern. Geeignete Techniken sind der Zweigüberdeckungstest und die Datenflussanomalieanalyse, die durch passende Werkzeuge unterstützt werden sollten. Ein Zweigüberdeckungstest-Werkzeug gestattet es dem Programmierer einfach nachzuvollziehen, ob die Testfälle den Programmcode wie vorgesehen durchlaufen. Ein Datenflussanomalieanalyse-Werkzeug ermöglicht z. B. die Identifikation uninitialisierter Variablen. Komplexe Verfahren und zusätzliche Werkzeuge gehören in die Hände eines speziell ausgebildeten Qualitätssicherers. Dieser Personenkreis wird insbesondere in den Abschluss des Modultests sowie in die Durchführung des Integrationstests und des Systemtests involviert sein.

15.3

Zusammenfassung

Software wird heute in einer Vielzahl von Anwendungsbereichen mit unterschiedlichen Anforderungen verwendet. Eine einheitliche, universelle und gleichzeitig für jede Software optimal geeignete Entwicklungsstrategie existiert nicht. Universell geeignete Herangehensweisen besitzen stets einen Minimalcharakter. Optimal geeignete Strategien müssen spezifisch konzipiert werden. Es ist wichtig, die Eigenschaften, Anforderungen und Rahmenbedingungen zu kennen und zu beachten. Daher ist zunächst zu entscheiden, ob eine Minimalstrategie ausreicht oder darüber hinaus eine angepasstere Vorgehensweise gefunden werden muss. In der Regel sollte ausgehend von der zu Beginn oft unsystematischen Arbeitsweise, zunächst eine Minimalstrategie realisiert werden, die anschließend an die spezifischen Anforderungen angepasst werden kann (siehe Abschnitt 15.2).

Universallösungen existieren nicht.

Reife Prozesse sind in der Software-Entwicklung notwendig aber nicht hinreichend. Es ist wichtig den Aspekt der Prozessreife zu beachten. Es ist aber ohne Zweifel ein schwerwiegender Fehler, ihn als Ersatz für technische Maßnahmen zu sehen. Kunden erwarten oft von einem Unterneh-

Reife Prozesse reichen allein nicht aus.

15.3 Zusammenfassung

489

men, dass es entsprechend der DIN ISO 9000-Normenreihe zertifiziert ist und einen entsprechend hohen Reifegrad des Entwicklungsprozesses vorweisen kann. Reife Prozesse wirken vertrauensbildend, liefern aber keine direkte Aussage über die Qualität der entwickelten Software. Formale Entwicklungsmethoden besitzen eine steigende Bedeutung in der sicherheitskritischen Software-Entwicklung.

Informale Software-Entwicklungsmethoden sind einfach und universell einsetzbar, liefern aber oft unzureichende Ergebnisse. So ist z. B. die fehlende Strukturierungsmöglichkeit von Prosa-Spezifikationen ein erhebliches Problem für die Nutzung dieser Technik in umfangreichen Entwicklungen. Formale Techniken ermöglichen eindeutige Beschreibungen, sind aber oft zu speziell und in der Regel ebenfalls nicht auf umfangreiche Software-Entwicklungen anwendbar. Formale Techniken scheinen insbesondere für die Entwicklung von sicherheitskritischer Software eine steigende Bedeutung zu erlangen.

Formatierte Entwicklungsmethoden sind Stand der Praxis.

Formatierte Techniken – z. B. UML – gestatten die Darstellung umfangreicher Software und wählen einen Kompromiss aus Einfachheit, universeller Einsetzbarkeit und Formalität. Darüber hinaus bieten Sie explizite Mechanismen zur Beherrschung umfangreicher Software-Entwicklungen. Es ist zu erwarten, dass diese Techniken auch in Zukunft eine wichtige Bedeutung besitzen werden.

Eine „ideale“ Prüftechnik existiert nicht.

Informale Prüftechniken sind unverzichtbar. Ihre bedeutendste Schwäche ist die Unvollständigkeit der erzeugten Ergebnisse. Formale Prüftechniken (Beweisverfahren) liefern vollständige Ergebnisse, scheitern in der Regel aber an fehlenden formalen Spezifikationen und anderen Rahmenbedingungen bei der Entwicklung umfangreicher Software-Systeme. Stochastische Techniken sind vielversprechend. Sie erzeugen Ergebnisse mit einem quantifizierten Vertrauensniveau. Leider erfordern sie mathematische Kenntnisse, über die Praktiker oft nicht verfügen, bzw. unterstützende Werkzeuge, die nicht verfügbar sind.

Gute Lösungen müssen sorgfältig konzipiert werden.

Offensichtlich ist ein „Allheilmittel“ in der Software-Technik nicht verfügbar. Die Vielzahl der verfügbaren Organisationsformen, Prozesse, Methoden, Techniken und Werkzeuge muss als Grundmenge für die Definition einer maßgeschneiderten Lösung dienen. Diese zielgerichtete Auswahl erfordert umfangreiche Kenntnisse. Ich würde mich freuen, mit diesem Buch zu ihrem Erwerb beigetragen zu haben.

CHECKLISTE

490

>

Reife Prozesse sind notwendig, aber nicht hinreichend. Reife Prozesse bilden das Gerüst für geeignete Techniken.

>

Einfache systematische Prüfungen, die eingesetzt werden, sind einer ehrgeizigen Strategie, die nicht durchgehalten wird, vorzuziehen.

>

Stellen Sie sicher, dass Sie die Anforderungen der für Ihren Bereich anwendbaren Standards kennen und z. B. ergänzend zu der vorgeschlagenen minimalen Prüfstrategie beachten. Zu-

15 Ein Praxisleitfaden

sätzliche Forderungen werden insbesondere von Standards für die technische Software-Entwicklung aufgestellt. >

Für die Einführung spezieller Prüfstrategien fehlen in Organisationen, in denen bislang unsystematisch geprüft wurde, oft die notwendigen Informationen. Parallel zur Einführung einer einfachen systematischen Prüfvorgehensweise sollte mit der Erhebung dieser Informationen begonnen werden.

>

Eine sorgfältige Fehleraufzeichnung ist unverzichtbar für die Kosten-Nutzen-Analyse und die Optimierung der Prüfung.

15.3 Zusammenfassung

491

“This page left intentionally blank.”

Literaturverzeichnis /Agrawal 94/ Agrawal, H., On slicing programs with jump statements, Proceedings of the ACM SIGPLAN ’94 Conference on Programming Language Design and Implementation. Orlando, Florida, June 20 – 24, 1994; SIGPLAN Notices, Vol. 29, No. 6, June 1994, pp. 302 – 312 /AQAP-150 97/ AQAP-150, NATO Quality Assurance Requirements for Software Development. NATO Standardization Agency, September 1997 /Automotive SPICE/ Automotive SPICE, http://www.automotivespice.com. Retrieved 12.02.2009 /Baker et al. 07/ Baker, P., Dai, Z.R., Grabowski, J., Haugen, O., Schieferdecker, I., Williams, C., Model-Driven Testing: Using the UMLTesting Profile. Springer Verlag, 2007 /Balzert 98/ Balzert, H., Lehrbuch der Software-Technik, Band 1: Software-Entwicklung (2. Auflage). Heidelberg, Berlin: Spektrum Akademischer Verlag, 1998 /Balzert 00/ Balzert, H., Lehrbuch der Software-Technik, Band 2: Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Heidelberg, Berlin: Spektrum Akademischer Verlag, 2000 /Basili et al. 96/ Basili, V., Briand, L. C., Melo, W. L., A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering, Vol. 22, No. 10, October 1996, pp. 751 – 761 /Basili, Perricone 84/ Basili, V. R., Perricone, B. T., Software Errors and Complexity: An Empirical Investigation. Communications of the ACM, Vol. 27, No. 1, January 1984, pp. 42 - 52 /Basili, Rombach 88/ Basili, V. R., Perricone, B. T., The TAME project: Towards improvement-orientated software environments. IEEE Transactions on Software Engineering, Vol. 14, No. 6, June 1988, pp. 758 - 773 /Basili et al. 94a/ Basili, V., Caldiera, G., Rombach, D., Goal Question Metric Paradigm. Encyclopedia of Software Engineering, Vol. 1, John Wiley and Sons, Inc., 1994 /Basili et al. 94b/ Basili, V., Caldiera, G., Rombach, D., The Experience Factory. Encyclopedia of Software Engineering, Vol. 1, John Wiley and Sons, Inc., 1994 /Basili et al. 07/ Basili, V., Heidrich, J., Lindvall, M., Münch, J., Regardie, M., Rombach, D., Seaman, C., Trendowicz, A., Bridging The Gap Between Business Strategy And Software Development. Proceedings of the International Conference on Information Systems, Montréal, Québec, Canada, 2007 /Beizer 90/ Beizer. B., Software Testing Techniques. New York: Van Nostrand Reinhold, 1990 /Beizer 95/ Beizer, B., Black-Box Testing. New York: John Wiley & Sons, 1995 /Berard 93/ Berard, E., Essays on Object-Oriented Software Engineering. Englewood Cliffs: Prentice Hall, 1993

493

/Bieman, Schultz 89/ Bieman, J. M., Schultz, J. L., Estimating the Number of Test Cases Required to Satisfy the All-du-paths Testing Criterion. Proceedings of the ACM SIGSOFT ’89 Third Symposium on Software Testing, Analysis, and Verification (TAV3), Key West, December 1989, pp. 179 - 186 /Birolini 97/ Birolini, A., Zuverlässigkeit von Geräten und Systemen. Berlin, Heidelberg, New York: Springer, 1997 /Boehm 81/ Boehm, B., Software engineering economics. Englewood Cliffs: Prentice Hall, 1981 /Booch et al. 98/ Booch, G., Rumbaugh, J., Jacobson, I., The Unified Modeling Language User Guide. Reading: Addison-Wesley, 1998 /Braverman 81/ Braverman, J. D., Fundamentals of Statistical Quality Control. Reston: Reston Publishing Co., Prentice Hall, 1981 /Briand, Wüst 01/ Briand, L. C., Wüst, J., Modeling Development Effort in Object-Oriented Systems Using Design Properties. IEEE Transactions on Software Engineering, Vol. 27, No. 11, November 2001, pp. 963 - 986 /Bryant 86/ Bryant, R. E., Graph-Based Algorithms for Boolean Function Manipulation. IEEE Transactions on Computers, Vol. C-35, No. 8, August 1986, pp. 667 - 691 /Brodman, Johnson 95/ Brodman, J. G., Johnson, D. L., Return on Investment (ROI) from Software Process Improvement as Measured by US Industry. Software Process – Improvement and Practice, Vol. 1, No. 1, August 1995, pp. 35-47 /Brooks 86/ Brooks, F. P. Jr., No Silver Bullet – Essence and Accidents of Software Engineering. IFIP Congress 1986: 1069-1076 /Binder 99/ Binder, R. V., Testing object-oriented systems: models, patterns, and tools. Addison-Wesley Longman, Boston, USA, 1999 /Braspenning 08/ Braspenning, N., Model-based integration and testing: Bridging the Gap between Academic Theory and Industrial Practice. VDM Verlag, 2008 /Broy et al. 05/ Broy, M., Jonsson, B., Katoen, J.-P., Leucker, M., Pretschner, A., Model-Based Testing of Reactive Systems: Advanced Lectures, Lecture Notes in Computer Science. Springer-Verlag, 2005 /CACM 90/ Communications of the ACM, Vol. 33, No. 12, December 1990 /Capability Maturity Model Integration/ Capability Maturity Model Integration, http://www.sei.cmu.edu/cmmi/. Retrieved 12.02.2009 /Cartwright, Shepperd 00/ Cartwright, M., Shepperd, M., An Empirical Investigation of an Object-Oriented Software System. IEEE Transactions on Software Engineering, Vol. 26, No. 8, August 2000, pp. 768 - 796 /Chidamber, Kemerer 94/ Chidamber, S. R., Kemerer, C. F., A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, Vol. 20, No. 6, June 1994, pp. 476 - 493 /Chilenski, Miller 94/ Chilenski, J. J., Miller, S. P., Applicability of modified condition/decision coverage to software testing. Software Engineering Journal, September 1994, pp. 193 - 200

494

Literaturverzeichnis

/Chusho 87/ Chusho, T., Data Selection and Quality Estimation Based on the Concept of Essential Branches for Path Testing. IEEE Transactions on Software Engineering, Vol. SE-13, No. 5, May 1987, pp. 509-517 /Clarke et al. 82/ Clarke, L. A., Hassell, J., Richardson, D. J., A Close Look at Domain Testing. IEEE Transactions on Software Engineering, Vol. SE-8, No. 4, July 1982, pp. 380-390 /Clarke et al. 85/ Clarke, L. A., Podgurski, A., Richardson, D. J., Zeil, S. J., A Comparison of Data Flow Path Selection Criteria. Proceedings of the 8th International Conference on Software Engineering, London, August 1985, pp. 244-251 /Clarke et al. 86/ Clarke, L. A., Podgurski, A., Richardson, D. J., Zeil, S. J., An Investigation of Data Flow Path Selection Criteria. Workshop on Software Testing, Banff, July 1986, pp. 23-32 /Clarke et al. 89/ Clarke, L. A., Podgurski, A., Richardson, D. J., Zeil, S. J., A Formal Evaluation of Data Flow Path Selection Criteria. IEEE Transactions on Software Engineering, Vol. 15, No. 11, November 1989, pp. 1318-1332 /Coad, Yourdon 91/ Coad, P., Yourdon, E., Object-Oriented Analysis. Englewood Cliffs: Prentice Hall, 1991 /Coallier, Drouin 92/ Coallier, F., Drouin, J. N., Developing an Assessments Method for Telecom Software System: An Experience Report. Proceedings 3rd European Conference on Software Quality, Madrid 1992 /Coen-Porisini et al. 91/ Coen - Porisini, A., De Paoli, F., Ghezzi, C., Mandrioli, D., Software Spezialization Via Symbolic Execution. IEEE Transactions on Software Engineering, Vol. 17, No. 9, September 1991, pp. 884-899 /Cohen 95/ Cohen, L., Quality Function Deployment: How to Make QFD Work for You. Addison Wesley Longman, 1995 /Craigmyle, Fletcher 93/ Craigmyle, M., Fletcher, I., Improving IT Effectiveness Through Software Process Assessment. Software Quality Journal, Vol. 2, No. 4, 1993, pp. 257-264 /Crosby 79/ Crosby, P. B., Quality is Free. New York: McGraw-Hill, 1979 /DeMarco 85/ DeMarco, T., Structured Analysis and System Specification. Englewood Cliffs: Prentice Hall, 1985 /Deming 86/ Deming, W. E., Out of the Crisis (2nd Edition). Cambridge: MIT Press, 1986 /Denger et al. 08/ Denger, C., Trapp, M., Liggesmeyer, P., SafeSpection – A Systematic Customization Approach for Software Hazard Identification. SAFECOMP 2008: 44-57 /DIN 25424 81/ DIN 25424; DIN 25424-1, Methoden und Bildzeichen. September 1981 /DIN 25424 90/ DIN 25424-2, Fehlerbaumanalyse Handrechenverfahren zur Auswertung eines Fehlerbaumes. April 1990; Berlin: Beuth Verlag /DIN 40041 90/ DIN 40041, Zuverlässigkeit; Begriffe. Berlin: Beuth Verlag, Dezember 1990 /DIN 55350-11 08/ DIN 55350-11, Begriffe zum Qualitätsmanagement – Teil 11. Berlin: Beuth Verlag, 2008

Literaturverzeichnis

495

/DIN EN 50128 01/ DIN EN 50128, Bahnanwendungen – Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme – Software für Eisenbahnsteuerungs- und Überwachungssysteme. Berlin: Beuth Verlag 2001 /DIN EN 60812 06/ DIN EN 60812, Analysetechniken für die Funktionsfähigkeit von Systemen – Verfahren für die Fehlzustandsart- und -auswirkungsanalyse (FMEA). Berlin: Beuth Verlag, 2006 /DIN EN ISO 8402 95/ DIN EN ISO 8402, Qualitätsmanagement – Begriffe. Berlin Beuth Verlag, 1995 (ersetzt durch DIN EN ISO 9000:2005) /DIN EN ISO 9000 05/ DIN EN ISO 9000, Qualitätsmanagementsysteme – Grundlagen und Begriffe. (ISO 9000:2005); Dreisprachige Fassung EN ISO 9000:2005, Berlin: Beuth Verlag, 2005 /DIN EN ISO 9001 08/ DIN EN ISO 9001, Qualitätsmanagementsysteme – Anforderungen. Berlin: Beuth Verlag 2008 /DIN EN ISO 9001 08/ DIN EN ISO 9001, Quality management systems – Requirements. 2008 /DIN EN ISO 9004 00/ DIN EN ISO 9004, Quality management systems – Guidelines for performance improvements. 2000 /DIN EN ISO 19011 02/ DIN EN ISO 19011, Guidelines for quality and/or environmental management systems auditing. 2002 /Dion 93/ Dion, R., improvement and the corporate balance sheet. IEEE Software, Vol. 10, No. 4, July 1993, pp. 28-35 /Doong, Frankl 91/ Doong, R. -K., Frankl, P. G., Case Studies on Testing Object-Oriented Programs. Proceedings of the Testing, Analysis, and Verification Symposium, Association for Computing Machinery, New York, 1991, pp. 165-177 /Doong, Frankl 94/ Doong, R. -K., Frankl, P. G., ASTOOT Approach to Testing Object-Oriented Programs. ACM Transactions on Software Engineering and Methodology, Vol. 3, No. 2, April 1994, pp. 101-130 /Dorling 93/ Dorling, A., Software Process Improvement and Capability dEtermination. Information and Software Technology, Vol. 35, No. 6/7, 1993, pp. 404-406 /Douglass 98/ Douglass, B. P., Real-time UML: Developing Efficient Objects for Embedded Systems. Reading: Addison-Wesley, 1998 /Duran, Ntafos 84/ Duran, J. W., Ntafos, S. C., An Evaluation of Random Testing. IEEE Transactions on Software Engineering, Vol. SE-11, No. 7, July 1985, pp. 438-444 /Ebert 00/ Ebert, C., Improving the Validation Process for a Better Field Quality in a Product Line Architecture. Proceedings Informatik 2000, Berlin, Heidelberg, New York: Springer, 2000, S. 372-388 /Eckhardt, Lee 85/ Eckhardt, J. R., Lee, R. E., A theoretical basis for the analysis of multiversion software subject to coincident errors. IEEE Transactions on Software Engineering, Vol. SE-11, No. 12, December 1985, pp. 1511-1517 /Endres 77/ Endres, A., Analyse und Verifikation von Programmen. München: Oldenbourg, 1977

496

Literaturverzeichnis

/Fagan 76/ Fagan, M. E., Design and code inspections to reduce errors in program development. IBM Systems Journal, No. 3, 1976, pp. 182-211 /Fagan 86/ Fagan, M. E., Advances in Software Inspections. IEEE Transactions of Software Engineering, Vol. SE-12, No. 7, July 1986, pp. 744-751 /Fahrmeir et al. 96/ Fahrmeir, L., Hamerle, A., Tutz, G., Multivariate statistische Verfahren. Berlin, New York: De Gruyter, 1996 /Feigenbaum 83/ Feigenbaum, A. V., Total Quality Control, 3rd Edition. New York: McGraw-Hill, 1983 /Fenton, Pfleeger 98/ Fenton, N. E., Software Metrics – A Rigorous & Practical Approach (2nd ed.). Boston: PWS Publishing Company, 1998 /Fenton, Ohlsson 00/ Fenton, N., Ohlsson, N., Analysis of Faults and Failures in a Complex Software System. IEEE Transactions on Software Engineering, Vol. 26, No. 8, August 2000, pp. 797-814 /Floyd 67/ Floyd, R. W., Assigning meanings to Programs. Proceedings of the American Mathematical Society Symposium in Applied Mathematics, Vol. 19, 1967, pp. 19-32 /Frehr 93/ Frehr, H. -U., Quality Management: Unternehmensweite Qualitätsverbesserung. München: Hanser, 1993 /Gannon 78/ Gannon, C., Results for Static Analysis and Path Testing of Small Programs. General Research Corporation RM-2225, September 1978 /Gannon 79/ Gannon, C., Error Detection Using Path Testing and Static Analysis. Computer, Vol. 12, No. 8, August 1979, pp. 26-31 /Gannon et al. 81/ Gannon, J., McMullin, P., Hamlet, R., Data-Abstraction Implementation, Specification, and Testing. ACM Transactions on Programming Languages and Systems, Vol. 3, No. 3, July 1981, pp. 211-223 /Gilb, Graham 93/ Gilb, T., Graham, D., Software Inspection. Reading: Addison-Wesley, 1993 /Girgis, Woodward 86/ Girgis, M. R., Woodward, M. R., An Experimental Comparison of the Error Exposing Ability of Program Testing Criteria. Proceedings Workshop on Software Testing, Banff, July 1986, pp. 64-73 /Goodenough, Gerhart 75a/ Goodenough, J. B., Gerhart, S. L., Toward a Theory of Test Data Selection. IEEE Transactions on Software Engineering, Vol. SE-1,No. 2, June 1975, pp. 156-173 /Goodenough, Gerhart 75b/ Goodenough, J. B., Gerhart, S. L., Correction to ’Toward a Theory of Test Data Selection’. IEEE Transactions on Software Engineering, Vol. SE-1, No. 2, December 1975, p. 425 /Goodenough, Gerhart 81/ Goodenough, J. B., Gerhart, S. L., Toward a Theory of Test Data Selection. Tutorial: Software Testing and Validation Techniques, New York: IEEE Computer Society Press, 1981, pp. 19-36 /Gourlay 83/ Gourlay, J. S., A Mathematical Framework for the Investigation of Testing. IEEE Transactions on Software Engineering, Vol. SE-9, No. 6, November 1983, pp. 686-709

Literaturverzeichnis

497

/Gutjahr 99/ Gutjahr, W. J., Partition Testing vs. Random Testing: The Influence of Uncertainty. IEEE Transactions on Software Engineering, Vol. 25, No. 5, September/October 1999, pp. 661-674 /Halstead 77/ Halstead, M. H., Elements of Software Science. New York: North-Holland, 1977 /Hamlet, Taylor 90/ Hamlet, D., Taylor, R., Partition Testing Does Not Inspire Confidence. IEEE Transactions on Software Engineering, Vol. 16, No. 12, December 1990, pp. 1402-1411 /Harel 87/ Harel, D., Statecharts: A visual Formalism for Complex Systems. Science of Computer Programming, Vol. 8, No. 3, June 1987, pp. 231-274 /Harrold et al. 92/ Harrold, M. J., McGregor, D. J., Fitzpatrick, K. J., Incremental Testing of Object-Oriented Class Structures. Proceedings 14th International Conference on Software Engineering, Melbourne, May 1992, pp. 68-80 /Hatley, Pirbhai 87/ Hatley, D. J., Pirbhai, I. A., Strategies for real-time system specification. New York: Dorset House Publishing, 1987 /Hedley, Hennell 85/ Hedley, D., Hennell, M. A., The Causes and Effects of Infeasible Paths in Computer Programs. Proceedings of the 8th International Conference on Software Engineering, London, August 1985, pp. 259-266 /Hennell et al. 77/ Hennell, M. A., Hedley, D., Woodward, M. R., Quantifying the test effectiveness of Algol 68 programs. Proceedings of the Strathclyde Algol 68 Conference, ACM Sigplan Notices, Vol.12, No.6, June 1977, pp. 36-41 /Hersleb et al. 94/ Herbsleb, J., Carleton, A., Rozum, J., Siegel, J., Zubrow, D., Benefits of CMM-Based Software Process Improvement: Initial Results. CMU/SEI-94-TR-13, Software Engineering Institute, Carnegie Mellon University, 1994 /Hoare 69/ Hoare, C. A. R., An Axiomatic Basis for Computer Programming. Communications of the ACM, Vol. 12, No. 10, October 1969, pp. 576-583 /Hoare 71/ Hoare, C. A. R., Proof of a Program: FIND. Communications of the ACM, Vol. 14, No. 1, January 1971, pp. 39-45 /Hoare 78/ Hoare, C. A. R., Communicating sequential processes. Prentice-Hall, 1985 /Hoffman, Strooper 95/ Hoffman, D., Strooper. P., The testgraph methodology: Automated testing collection classes. Journal of Object-Oriented Programming, Vol. 8, No. 7, November/December 1995, pp. 35-41 /Hohlfeld 88/ Hohlfeld, B., Zur Verifikation von modular zerlegten Programmen. Dissertation, Fachbereich Informatik, Universität Kaiserslautern, 1988 /Hörcher 99/ Hörcher, H. -M, Testautomation in der Telekommunikation. Softwaretechnik-Trends, Band 19, Heft 1, Februar 1999, S. 13-14 /Howden 75/ Howden, W. E., Methodology for the Generation of Program Test Data. IEEE Transactions on Computers, Vol. C-24, May 1975, pp. 554-560

498

Literaturverzeichnis

/Howden 76/ Howden, W. E., Reliability of the Path Analysis Testing Strategy. IEEE Transactions on Software Engineering, Vol. SE-2, No. 3, September 1976, pp. 208-215 /Howden 77/ Howden, W. E., Symbolic Testing and the DISSECT Symbolic Evaluation System. Transactions on Software Engineering, Vol. SE-3, No. 4, July 1977, pp. 266-278 /Howden 78a/ Howden, W. E., An Evaluation of the Effectiveness of Symbolic Testing. Software – Practice and Expirience, Vol. 8, 1978, pp. 381-397 /Howden 78b/ Howden, W. E., Theoretical and Empirical Studies of Program Testing. IEEE Transactions on Software Engineering, Vol. SE-4, No. 4, July 1978, pp. 293-298 /Howden 78c/ Howden, W. E., Theoretical and Empirical Studies of Program Testing. Proceedings of the 3rd International Conference on Software Engineering, Atlanta, May 1978, pp. 235-243 /Howden 81/ Howden, W. E., A Survey of dynamic Analysis Methods. Tutorial: Software Testing and Validation Techniques, New York: IEEE Computer Society Press, 1981, pp. 209-231 /Howden 82/ Howden, W. E., Weak Mutations Testing and Completeness of Test Sets. IEEE Transactions on Software Engineering, Vol. SE-8, No. 4, July 1982, pp. 371-379 /Hughes, Stotts 96/ Hughes, M., Stotts, D., Daistish: systematic algebraic testing for OO programs in the precence of side effects. Proceedings of the 1996 International Symposium on Software Testing and Analysis (ISSTA), January 8-10, 1996, San Diego, Software Engineering Notes, Vol. 21, No. 3, May 1996, pp. 53-61 /Humphrey et al. 89/ Humphrey, W. S., Kitson, D. H., Kasse, T. C., The State of Software Engineering Practice: A Preliminary Report. CMU/SEI-89-TR-1, Software Engineering Institute, Carnegie Mellon University, 1989 /Humphrey 90/ Humphrey, W. S., Managing the software process. Reading: Addison-Wesley, 1990 /Humphrey et al. 91/ Humphrey, W. S., Snyder, T. R., Willis, R. R., Software process improvement at Hughes Aircraft. IEEE Software, Vol. 8, No. 4, July 1991, pp. 11-23 /Humphrey 08/ Humphrey, W. S., PSP: A Self-Improvement Process for Software Engineers. SEI Series in Software Engineering, Addison-Wesley Longman, 2005 /Hunt 96/ Hunt, N., Testing Object-Oriented Code: Unit testing. Journal of Object-Oriented Programming, Vol. 8, No. 9, February 1996, pp. 18-23 /Hüskes 95/ Hüskes, R., Intels Tauschaktion, Umtauschrecht für fehlerhafte Pentium-Prozessoren. c’t magazin für computertechnik, Heft 2, Februar 1995, S. 17 /IEC 60812 06/ IEC 60812, Analysis Techniques for System Reliability – Procedure for Failure Mode and Effects Analysis (FMEA). International Electrotechnical Commission, 2006 /IEC 61025 06/ IEC 61025, Fault tree analysis (FTA). International Electrotechnical Commission, 2006

Literaturverzeichnis

499

/IEC 61078 06/ IEC 61078, Analysis techniques for dependability – Reliability block diagram and Boolean method. International Electrotechnical Commission, 2006 /IEC 61165 06/ IEC 61165, Application of Markov techniques. International Electrotechnical Commission, 2006 /IEC 61508 98/ IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems: Parts 1-7. International Electrotechnical Commission, 1998 /Infotech Vol.1 79/ Software Testing. Infotech State of the Art Report, Vol. 1, Maidenhead, 1979 /ISACA 07/ ISACA, Control Objectives for Information and related Technology (CoBIT®). www.isaca.org, Retrieved 04.12.2007 /ISO/IEC 9126 04/ ISO/IEC 9126, Software engineering – Product quality. Teile 1 bis 4, 2001-2004 /ISO/IEC 12207 95/ ISO/IEC 12207, Information technology – Software life cycle processes. 1995 /ISO/IEC 12207 08/ ISO/IEC 12207, Systems and software engineering – Software life cycle processes. 2008 /ISO/IEC 15504 08/ ISO/IEC 15504, Information technology – Process assessment. 2008 /ISO/IEC 15288 08/ ISO/IEC 15288, Systems and software engineering – System life cycle processes. 2008 /ISO/IEC 90003 04/ ISO/IEC 90003, Software engineering – Guidelines for the application of ISO 9001:2000 to computer software. 2004 /Jacky et al. 08/ Jacky, J., Veanes M., Campbell C., Schulte W., Model-Based Software Testing and Analysis with C#. Cambridge University Press, 2008 /Jacobson et al. 92/ Jacobson, I., Christerson, M., Jonson, P., Ävergaard, G., Object-Oriented Software Engineering – A Use Case Driven Approach. Bonn: Addison-Wesley, 1992 /Jalote, Caballero 88/ Jalote, P., Caballero, M. G., Automated Testcase Generation for Data Abstraction. Proceedings of the 12th Annual International Computer & Applications Conference (COMPSAC 88), Oktober 1988, pp. 205-210 /Jelinski, Moranda 72/ Jelinski, Z., Moranda, P. B., Software reliability research, in: Freiberger W. (Ed.), Statistical Computer Performance Evaluation. New York: Academic Press, 1972, pp. 465-484 /Jeng, Weyuker 89/ Jeng, B., Weyuker, E. J., . Some Observations on Partition Testing, Proceedings of the ACM SIGSOFT ’89 Third Symposium on Software Testing, Analysis, and Verification (TAV3), Key West, December 1989, pp. 38-47 /Johnson, Wichern 82/ Johnson, R. A., Wichern, D. W., . Some Observations on Partition Testing, Proceedings of the ACM SIGSOFT ’89 Third Symposium on Software Testing, Analysis, and Verification (TAV3), Key West, December 1989, pp. 38-47 /Jones 91/ Jones, C., Applied software measurement. New York: McGraw-Hill, 1991

500

Literaturverzeichnis

/Jorgenson, Erickson 94/ Jorgenson, P. C., Erickson, C., Object-Oriented Integration Testing. Communications of the ACM, Vol. 37, No. 9, September 1994, pp. 30-38 /Juran 64/ Juran, J. M., Managerial Breakthrough. New York: McGraw-Hill, 1964 /Jüttner et al. 95/ Jüttner, P., Zimmerer, P., Naumann, U., Kolb, S., Integration Testing of Object-Oriented Software. Proceedings of the 18th International Software Quality Week, San Francisco, May 1995 /Kaiser et al. 03/ Kaiser, B., Liggesmeyer, P., Mäckel, O., A New Component Concept for Fault Trees. SCS 2003, pp. 37-46 /Kaminske, Brauer 93/ Kaminske, G. F., Brauer, J. -P., Qualitätsmanagement von A bis Z. München: Hanser, 1993 /Kauffels 99/ Kauffels, F. -J., Lokale Netze. Bonn: NITP-Verlag, 1999 /King 76/ King, J. C., Symbolic execution and program testing. Communications of the ACM, Vol. 19, No. 7, July 1976, pp. 385-394 /Knight, Leveson 86/ Knight, J., Leveson, N., An Experimental Evaluation of the Assumption of Independence in Multi-Version Programming. IEEE Transactions on Software Engineering, Vol. SE-12, No. 1, January 1986, pp. 96-109 /Koch 93/ Koch, G. R., Process Assessment: the ’BOOTSTRAP’ Approach. Information and Software Technology, Vol. 35, No. 6/7, June/July 1993, pp. 387-403 /Korel 87/ Korel, B., The Program Dependence Graph in Static Program Testing. Information Processing Letters, Vol. 24, No. 2, January 1987, pp. 103-108 /Korel, Laski 88/ Korel, B., Laski, J., Dynamic Program Slicing. Information Processing Letters, Vol. 29, No. 3, October 1988, pp. 155-163 /Kosman, Restivo 92/ Kosman, R. J., Restivo., T. J., Incorporating the Inspection Process into a Software Maintenance Organization. Proceedings Conference Software Maintenance, Oktober 1992, pp. 335-347 /Kung et al. 95/ Kung, D. C., Gao, J., Hsia, P., Chen, C., Kim, Y. -S., Toyoshima, Y., Developing an Object-Oriented Software Testing and Maintenance Environment. Communications of the ACM, Vol. 38, No. 10, October /Laski 82/ Laski, J., On Data Flow Guided Program Testing. ACM Sigplan Notices, Vol. 17, No. 9, Sept. 1982, pp 62-71 /Laski, Korel 83/ Laski, J. W., Korel, B., A Data Flow Oriented Program Testing Strategy. IEEE Transactions on Software Engineering, Vol. SE-9, No. 3, May 1983, pp. 347-354 /Lees 83/ Lees, F. P, Loss Prevention in the Process Industries (Vol. 1 and Vol.2). London, Boston: Butterworths, 1983 /Leveson 95/ Leveson, N. G., Safeware: System safety and computers. New York: Addison-Wesley, 1995 /Leveson, Shimeall 91/ Leveson, N. G., Shimeall, T. J., Safety Verifcation of ADA Programs using Software Fault Trees. IEEE Software, Vol. 8, No. 4, July 1991, pp. 48-59

Literaturverzeichnis

501

/Leveson, Turner 93/ Leveson, N. G., Turner, C. L, An Investigation of the Therac-25 Accidents. IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41 /Lewerentz, Lindner 95/ Lewerentz, C., Lindner, T., Formal Development of Reactive Systems: Case Study Production Cell. Lecture Notes in Computer Science, Vol. 891, Berlin: Springer 1995 /Liggesmeyer 90/ Liggesmeyer, P., Modultest und Modulverifikation – State of the Art. Mannheim, Wien, Zürich: BI Wissenschaftsverlag, 1990 /Liggesmeyer 95/ Liggesmeyer, P., A set of complexity metrics for guiding the software test process. Software Quality Journal, Vol. 4, No. 4, 1995, pp. 257-273 /Liggesmeyer 96/ Liggesmeyer, P., Die Bewertung und Verbesserung von Software-Entwicklungsprozessen mit Assessments. in: Müllerburg M., Spillner A., Liggesmeyer P. (Hrsg.): Test, Analyse und Verifikation von Software, Oldenbourg: München, 1996, S. 155-168S /Liggesmeyer 00/ Liggesmeyer, P., Qualitätssicherung softwareintensiver technischer Systeme. Heidelberg: Spektrum Akademischer Verlag, 2000 /Liggesmeyer 07/ Liggesmeyer, P., Formal Techniques in Software Engineering: Correct Software and Safe Systems. TPHOLs, 2007, pp. 3-4 /Liggesmeyer, Ackermann 98/ Liggesmeyer, P., Ackermann, T., Applying Reliability Engineering: Empirical Results, Lessons Learned, and Further Improvements. Proceedings ISSRE ’98, The Ninth International Symposium on Software Reliability Engineering, Paderborn, November 1998, pp. 263-271 /Liggesmeyer, Rombach 05/ Liggesmeyer, P., Rombach, D., Software-Engineering eingebetteter Systeme: Grundlagen-Methodik-Anwendungen . Heidelberg, Spektrum Akademischer Verlag, 2005 /Liggesmeyer, Rothfelder 98/ Liggesmeyer, P., Rothfelder, M., System Safety Improvement by Automated Software Robustness Evaluation. Proceedings 15th International Conference on Testing Computer Software, Washington, D.C., June 1998, pp. 71-77 /Lions 96/ Lions, J.L., ARIANE 5 Flight 501 Failure, Report by the Inquiry Board. Paris, July 1996 /Littlewood, Verall 73/ Littlewood, B., Verall, J. L., A Bayesian reliability growth model for computer software. Applied Statistics, Vol. 22, No. 3, 1973, pp. 332-346 /Lyu 95/ Lyu, M. R., Handbook of Software Reliability Engineering. New York: McGraw-Hill, 1995 /Mackie, Rigby 93/ Mackie, C. A., Rigby, P. G, Practical Experience in Assessing the Health of the Software Process. Software Quality Journal, Band 2, Nr. 4, 1993, S. 265-276 /McCabe 76/ McCabe, T. J., A Complexity Measure. IEEE Transactions on Software Engineering, Vol. SE-2, No. 4, December 1976, pp. 308-320 /McGregor, Korson 94/ McGregor, J., Korson, T. D., Integrated Object-Oriented Testing and Development Process. Communications of the ACM, Vol. 37, No. 9, September 1994, pp. 59-77

502

Literaturverzeichnis

/Mäckel 01/ Mäckel, O., Software-FMEA: Chancen und Nutzen der FMEA im Entwicklungsprozess. QZ Qualität und Zuverlässigkeit, Januar 2001, pp. 65-68 /Meyer 88/ Meyer, B., Object-Oriented Software Construction. Englewood Cliffs: Prentice Hall, 1988 /Möller 96/ Möller, K. -H., Ausgangsdaten für Qualitätsmetriken – Eine Fundgrube für Analysen in: Ebert C., Dumke R. (Hrsg.), Software-Metriken in der Praxis, Berlin, Heidelberg: Springer, 1996, S. 105-116 /Möller, Paulish 93/ Möller, K. -H, Paulish D. J., Spftware-Metriken in der Praxis München: Oldenbourg, 1993 /Mü 8004 99/ Mü 8004, Technische Grundsätze für die Zulassung von Sicherungsanlagen. München: Eisenbahn-Bundesamt, Januar 1999 /Musa et al. 87/ Musa, J. D., Iannino, A., Okumoto, K., Software Reliability: Measurement, Prediction, Application. New York: McGraw-Hill, 1987 /Myers 76/ Myers, G. J., Software Reliability. New York: John Wiley & Sons, 1976 /Myers 79/ Myers, G. J., The Art of Software-Testing. New York: John Wiley & Sons, 1979 /Nassi, Shneiderman 73/ Nassi, I., Shneiderman, B., Flowchart Techniques for Structured Programming. ACM Sigplan Notices, August 1973, pp. 12-26 /Ntafos 81/ Ntafos, S. C., On Testing with Required Elements. Proceedings of compsac 81, The IEEE Computer Society’s 5th International Computer Software & Applications Conference, Chicago, November 1981, pp. 132-139 /Ntafos 84/ Ntafos, S. C., On Required Element Testing. IEEE Transactions on Software Engineering, Vol. SE-10, No. 6, November 1984, pp. 795-803 /Ntafos 88/ Ntafos, S. C., A Comparison of Some Structural Testing Strategies. IEEE Transactions on Software Engineering, Vol. 14, No. 6, June 1988, pp. 868-874 /O’Donnell 82/ O’Donnell, M. J., A Critique of the Foundations of Hoare Style Programming Logics. Communications of the ACM, Vol. 25, No. 12, December 1982, pp. 927-935 /Offutt 89/ Offutt, A. J., The Coupling Effect: Fact or Fiction?. Proceedings of the ACM SIGSOFT ’89 Third Symposium on Software Testing, Analysis, and Verification (TAV3), Key West, December 1989, pp. 131-140 /OGC 08/ Office of Government Commerce (OGC), Service Strategy. The Stationery Office, 2008 /OGC 07a/ Office of Government Commerce (OGC), Service Design. The Stationery Office, 2007 /OGC 07b/ Office of Government Commerce (OGC), Service Transition. The Stationery Office, 2007 /OGC 07c/ Office of Government Commerce (OGC), Service Operation. The Stationery Office, 2007

Literaturverzeichnis

503

/OGC 07d/ Office of Government Commerce (OGC), Continual Service Improvement. The Stationery Office, 2007 /Overbeck 94/ Overbeck, J., Integration Testing for Object-Oriented Software. Dissertation Technische Universität Wien, 1994 /Overbeck 95/ Overbeck, J., Testing Object-Oriented Software and Reusability. Proceedings 8th International Quality Week, San Francisco 1995 /Pagel, Six 94/ Pagel, B. -U., Six, H. -W., Software Engineering (Band 1: Die Phasen der Softwareentwicklung). Bonn: Addison-Wesley, 1994 /Paulk 95/ Paulk, M. C., The Evolution of the SEI’s Capability Maturity Model for Software. Software Process – Improvement and Practice, Vol. 1, No. 1, August 1995, pp. 3-15 /Paulk et al. 93/ Paulk, M. C., Weber, C. V., Garcia, S. M., Chrissis, M. B., Bush, M., Key Practices of the Capability Maturity Model, Version 1.1. CMU / SEI-93-TR-25, Software Engineering Institute, Carnegie Mellon University, 1993 /Peleska, Zahlten 99/ Peleska, J., Zahlten, C., Test Automation for Avionic Systems and Space Technology (Extended Abstract). Softwaretechnik-Trends, Band 19, Heft 1, Februar 1999, S. 34-35 /Perry, Kaiser 90/ Perry, E., Kaiser, G. E., Adequate Testing and Object-Oriented Programming. Journal of Object-Oriented Programming, Vol. 2, No. 5, January/February 1990, pp. 13-19 /Poston 94/ Poston, R. M., Automated Testing from Object Models. Communications of the ACM, Vol. 37, No. 9, September 1994, pp. 48-58 /Prowell et al. 99/ Prowell, S. J., Trammell, C. J., Linger, R. C., Poore, J. H.„ Cleanroom Software Engineering: Technology and Process. Addison-Wesley, 1999 /Pyzdek 03/ Pyzdek, T., The Six Sigma Handbook: A Complete Guide for Green Belts, Black Belts and Managers at All Levels. New York, NY: McGraw-Hill Professional, 2003 /Ramamoorthy et al. 76/ Ramamoorthy, C. V., Ho, S. -B. F., Chen, W. T., On the Automated Generation of Program Test Data. IEEE Transactions on Software Engineering, Vol. SE-2, No. 4, December 1976, pp. 293-300 /Rapps, Weyuker 82/ Rapps, S., Weyuker, E. J., Data Flow Analysis Techniques for Test Data Selection. Proceedings of the 6th International Conference on Software Engineering, Tokyo, September 1982, pp. 272-277 /Rapps, Weyuker 85/ Rapps, S., Weyuker, E. J., Selecting Software Test Data Using Data Flow Information. IEEE Transactions on Software Engineering, Vol. SE-11, No. 4, April 1985, pp. 367-375 /Rausch, Broy 08/ Rausch, A., Broy, M., Das V-Modell XT: Grundlagen, Erfahrungen und Werkzeuge. dpunkt-Verlag, 2008 /Richardson, Clarke 81/ Richardson, D. J., Clarke, L. A., A Partition Analysis Method to increase Program Reliability. Proceedings of the 5th International Conference on Software Engineering, San Diego, March 1981, pp. 244-253

504

Literaturverzeichnis

/Richardson, Clarke 85/ Richardson, D. J., Clarke, L. A., Partition Analysis: A Method Combining Testing and Verification. IEEE Transactions on Software Engineering, Vol. SE-11, No. 2, December 1985, pp. 1477-1490 /Riedemann 97/ Riedemann, E. H., Testmethoden für sequentielle und nebenläufige Software-Systeme. Stuttgart: Teubner, 1997 /Robillard et al. 91/ Robillard, P. N., Coupal, D., Coallier, F., Profiling Software Throught the Use of Metrics. Software – Practice and Experience, Vol. 21, No. 5, May 1991, pp. 507-518 /Robinson-Mallett, Liggesmeyer 06/ Robinson-Mallett, C., Liggesmeyer, P., State Identification and Verification using a Model Checker . Software Engineering 2006, pp. 131-142 /Robinson-Mallett et al. 05/ Robinson-Mallett, C., Liggesmeyer, P., Mücke, T., Goltz, U., Generating optimal distinguishing sequences with a model checker. ACM SIGSOFT Software Engineering Notes, Vol. 30, No.4, 2005, pp. 1-7 /Robinson-Mallett et al. 06a/ Robinson-Mallett, C., Hierons, R. M., Liggesmeyer, P., Achieving communication coverage in testing. ACM SIGSOFT Software Engineering Notes, Vol. 31, No. 6, 2006, pp. 1-10 /Robinson-Mallett et al. 06b/ Robinson-Mallett, C., Liggesmeyer, P., Mücke, T., Goltz, U., Extended state identification and verification using a model checker. Information & Software Technology, Vol. 48, No.10, 2006, pp. 981-992 /Robinson-Mallett et al. 08/ Robinson-Mallett, C., Hierons, R. M., Poore, J. H., Liggesmeyer, P., Using communication coverage criteria and partial model generation to assist software integration testing. Software Quality Journal, Vol. 16, No. 2, 2008, pp. 185-211 /Roetzel 90/ Roetzel, A., Rechnergestützte, statistische Qualitätssicherung. Berlin: VDE-Verlag, 1990 /Rombach et al. 08/ Rombach, D., Münch, J., Ocampo, A., Humphrey, W. S., Burton, D., Teaching Disciplined Software Development. International Journal of Systems and Software, Vol. 81, Issues 5, pp. 747-763, May 2008 /Rothfelder 02/ Rothfelder, M., Sicherheit und Zuverlässigkeit eingebetteter Systeme: Realisierung, Prüfung, Nachweis (Teil II). Seminarunterlage, Bonn: Deutsche Informatik Akademie, 2002 /RTCA DO-178B 92/ RTCA/ DO -178B, Software Considerations in Airborne Systems and Equipment Certification. RTCA, Inc., 1992 /Rumbaugh et al. 91/ Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., Object-Oriented Modeling and Design. Englewood Cliffs: Prentice Hall, 1991 /Rumbaugh et al. 04/ Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language Reference Manual. Amsterdam: Addison-Wesley, 2004 /Rupp et al. 07/ Rupp, C., Queins, S., Zengler, B., UML 2 glasklar. Praxiswissen für die UML-Modellierung. Hanser, 2007 /Russell 91/ Russel, G. W., Experience with Inspection in Ultralarge-Scale Developments. IEEE Software, Vol. 8. No. 1, January/February 1991, pp. 25-31

Literaturverzeichnis

505

/Sarbanes-Oxley 02/ Sarbanes-Oxley Act of 2002. Public Law No. 107-204, 116 Stat. 745, Codified in sections of 11, 15, 18, 28, and 29 in United States Code, 30.7.2002 /Schaefer et al. 98/ Schaefer, M., Gnedina, A., Bömer, T., Büllesbach, K. -H., Grigulewitsch, W., Reuß, G., Reinert, D., Programmierregeln für die Erstellung von Software für Steuerungen mit Sicherheitsaufgaben. Dortmund, Bundesanstalt für Arbeitsschutz und Arbeitsmedizin, 1998 /Schieferdecker et al. 08/ Schieferdecker, I., Grabowski, J., Vassiliou-Gioles, T., Din, G., Methods and Testing, 2008, pp. 292-319

The Test Technology TTCN-3. Formal

/Schnurrer 88/ Schnurrer, K. E., Programminspektionen: Erfahrungen und Probleme. Informatik-Spektrum, Band 11, 1988, S. 312-322 /Sneed, Winter 01/ Sneed, H. M., Winter, M., Testen objektorientierter Software. München: Hanser, 2001 /Sorkowitz 79/ Sorkowitz, A. R., Certification Testing: A Procedure to Improve the Quality of Software Testing Computer, Vol. 12, No. 8, August 1979, pp. 20-24. /SPICE 94/ Proceedings of the 1st International SPICE Symposium, Ottawa, June 1994 /Spillner, Liggesmeyer 94/ Spillner, A., Liggesmeyer, P., Software-Qualitätssicherung in der Praxis – Ergebnisse einer Umfrage. Informatik-Spektrum, Band 17, Heft 6, Dezember 1994, S. 368-372 /Stiller 95a/ Stiller, A., Prozessorgeflüster, Der Bug von Intels Flaggschiff. c’t magazin für computertechnik, Heft 1, Januar 1995, S. 20-21 /Stiller 95b/ Stiller, A., Waschzettel, Der Pentium und seine Fehler. c’t magazin für computertechnik, Heft 7, Juli 1995, S. 186-190 /Tai 80/ Tai, K. C., Program Testing Complexity and Test Criteria. IEEE Transactions on Software Engineering, Vol. SE-6, No. 6, November 1980, pp. 531-538 /Taylor, Osterweil 80/ Taylor, R. N., Osterweil, L. J., Anomaly Detection in Concurrent Software by Static Data Flow Analysis. IEEE Transactions on Software Engineering, Vol. SE-6, No. 3, May 1980, pp. 265-278 /Thaler, Utesch 96/ Thaler, M., Utesch, M., Effektivität und Effizienz von Softwareinspektionen. in: Müllerburg et al. (Hrsg.), Test, Analyse und Verifikation von Software, GMD-Bericht Nr. 260, München, Wien: Oldenbourg, 1996, S. 183-196 /Tobias, Trindade 95/ Tobias, P. A., Trindade, D. C., Applied Reliability. New York: Van Nostrand Reinhold, 1995 /Turner, Robson 93/ Turner, C., Robson, D. J, Guidance for the Testing of Object-Oriented Programs. Technical Report TR-2/93, Computer Science Division, School of Engineering and Computer Science (SECS), University of Durham, Durham, 1993 /Utting, Legeard 06/ Utting, M., Legeard, B., Practical Model-Based Testing: A Tools Approach. Morgan-Kaufmann 2006

506

Literaturverzeichnis

/van Meegen, Schless 92/ van Meegen, M., Schless, P., Programmierkonventionen für C++. Softwaretechnik-Trends, Band 12, Heft 3, August 1992, S. 29-47 /Walsh 83/ Walsh, T. J., A Software Reliability Study Using a Complexity Measure, in: McCabe T.J., Structured Testing. New York: IEEE Computer Society Press, 1983, pp. 90-97 /Watkins 82/ Watkins, M. L., A Technique for Testing Command and Control Software. Communications of the ACM, Vol. 25, No. 4, April 1982, pp. 228-232 /Weyuker, Jeng 91/ Weyuker, E. J., Jeng, B., Analyzing Partition Testing Strategies. IEEE Transactions on Software Engineering, Vol. 17, No. 7, July 1991, pp. 703-711 /Weyuker, Ostrand 80/ Weyuker, E. J., Ostrand, T. J., Theories of Program Testing and the Application of Revealing Subdomains. IEEE Transactions on Software Engineering, Vol. SE-6, No. 3, May 1980, pp. 236-246 /Weyuker, Ostrand 81/ Weyuker, E. J., Jeng, B., Theories of Program Testing and the Application of Revealing Subdomains, in: Tutorial: Software Testing and Validation Techniques. New York: IEEE Computer Society Press, 1981, pp. 56-66 /Wheeler, Chambers 92/ Wheeler, D. J., Chambers, D. S., Understanding Statistical Process Control. Knoxville: SPC Press, 1992 /White, Cohen 80/ White, L. J., Cohen, E. I., A Domain Strategie for Computer Program Testing. IEEE Transactions on Software Engineering, Vol. SE-6, No.3, May 1980, pp. 247-257 /Wilson, Osterweil 85/ Wilson, C., Osterweil, L., Omega – A Data Flow Analysis Tool for the C Programming Language. IEEE Transactions on Software Engineering, Vol. SE-11, No. 9, September 1985, pp. 832-838 /Winter 00/ Winter, M., Ein interaktionsbasiertes Modell für den objektorientierten Integrations- und Regressionstest. Informatik – Forschung und Entwicklung, Band 15, Heft 3, 2000, S. 121-132 /Wohlwend, Rosenbaum 94/ Wohlwend, H., Rosenbaum, S., Schlumberger’s software improvement program. IEEE Transactions on Software Engineering, Vol. 20, No. 11, November 1994, pp. 833-839 /Woodward et al. 80/ Woodward, M. R., Hedley, D., Hennell, M. A., Experience with Path Analysis and Testing of Programs. IEEE Transactions on Software Engineering, Vol. SE-6, No. 3, May 1980, pp. 278-286 /Yourdon 89/ Yourdon, E., Structured Walkthroughs (4th ed.). Englewood Cliffs: Prentice Hall, 1989 /Yourdon 00/ Yourdon, E., Modern Structured Analysis. Englewood Cliffs: Prentice Hall, 2000 /Yourdon, Constantine 79/ Yourdon, E. N., Constantine, L. L., Structured Design. Englewood Cliffs: Prentice Hall, 1979 /Zeil 83/ Zeil, S. J., Testing for Perturbations of Program Statements. IEEE Transactions on Software Engineering, Vol. SE-9, No. 3, May 1983, pp. 335-346 /Zeil 89/ Zeil, S. J., Perturbations Techniques for Detecting Domain Errors. IEEE Transactions on Software Engineering, Vol. 15, No. 6, June 1989, pp. 737-746

Literaturverzeichnis

507

/Zelkowitz 90/ Zelkowitz, M. V., A Functional Correctness Model of Program Verification. Computer, Vol. 23, No. 11, November 1990, pp. 30-39 /Zuse 91/ Zuse, H., Software Complexity – Measures and Methods. Berlin, New York: De Gruyter, 1991

508

Literaturverzeichnis

Glossar Abnahmetest Test mit dem Ziel festzustellen, ob eine Software akzeptiert werden kann. Absolutskala Eine Skala, die die einzige Möglichkeit zur Messung eines Sachverhaltes darstellt. Ad hoc-Test → Dynamischer Test ohne konkrete zugrundegelegte Strategie. Anweisungsüberdeckungstest Der Anweisungsüberdeckungstest (statement coverage test) ist eine → kontrollflussorientierte, → dynamische Testtechnik. Er fordert die mindestens einmalige Ausführung aller Anweisungen der zu testenden Software. Äquivalenzklasse Eine Äquivalenzklasse ist eine Menge von Betriebssituationen. Diese verursachen gleichartige Wirkungen. Funktionsorientierte Äquivalenzklassen werden durch die → funktionale Äquivalenzklassenbildung aus der → Spezifikation abgeleitet. Es werden gültige und ungültige Äquivalenzklassen unterschieden. Strukturorientierte Äquivalenzklassen werden aus der Software-Struktur abgeleitet. Äquivalenzklassenanalyse → Funktionale Äquivalenzklassenbildung. Assertion → Zusicherung. Assessment → Prozess-Assessment. Ausfall → Fehlverhalten. Ausfallkombination Eine Ausfallkombination ist das gleichzeitige Vorliegen von Funktionselementausfällen, die zu dem → unerwünschten Ereignis eines Fehlerbaums führen. Die kleinste Ausfallkombination sind Kombinationen von Ausfällen, die genau so viele Ausfälle enthalten, wie zur Erzeugung des unerwünschten Ereignisses mindestens notwendig sind (Minimal-Cut-Set) /DIN 25424 90/. Back to Back-Test Der Back to Back-Test ist eine diversifizierende Testtechnik, die mehrere Versionen einer Software gegeneinander testet. Der Back to Back-Test arbeitet mit Versionen, die basierend auf identischen → Spezifikationen von unabhängigen Entwicklerteams realisiert worden sind. Bedingungsüberdeckungstest Der Bedingungsüberdeckungstest (condition coverage test) gehört zu den → kontrollflussorientierten, → dynamischen Testtechniken. Es gibt mehrere Bedingungsüberdeckungstesttechniken, die unterschiedliche Forderungen für den Test der Bedingungen einer zusammengesetzten Entscheidung stellen. Bedingungs-/Entscheidungsüberdeckungstest Der Bedingungs-/Entscheidungsüberdeckungstest (condition/decision coverage test) ist eine → dynamische, → strukturorientierte Testtechnik, die den Test aller atomaren Teilentscheidungen von zusammengesetzten Entscheidungen gegen beide Wahrheitswerte fordert. Zusätzlich wird ein vollständiger → Zweigüberdeckungstest verlangt. Bereichstest Gruppe → dynamischer Testtechniken, deren Vertreter unterschiedliche Formen der Bildung von Teilbereichen der Eingabedaten wählen. Dies kann auf Basis der Software-Struktur (z. B. → Pfadbereichstest) oder anhand einer Kombination von struktur- und funktionsorientierten Kriterien (z. B. → Test fehleroffenbarender Unterbereiche) durchgeführt werden. Beta-Test Test eines Software-Systems mit realistischen Testfällen in der Regel durch den Kunden und in den Räumlichkeiten des Kunden und stets unabhängig von der Entwicklung. Big Bang-Test Nicht-inkrementeller → Integrationstest. Zusammenfügen aller Module zum Software-System in einem Schritt.

509

Black Box-Test Black Box-Tests benötigen keine Information über die Struktur der zu testenden Software. Die → funktionale Äquivalenzklassenbildung und der → Zufallstest sind Black Box-Tests. Bottom-Up-Test → Integrationstestverfahren. Integration von Komponenten beginnend mit tiefen Diensten in Richtung höherer Dienste. Boundary interior-Pfadtest Der boundary interior-Pfadtest ist eine → kontrollflussorientierte, → dynamische Testtechnik. Er sieht eine eingeschränkte Form des → Pfadüberdeckungstests vor. Der boundary interior-Pfadtest sieht wie der → strukturierte Pfadtest Beschränkungen für den Test von Pfaden vor, die eine höhere Anzahl von Schleifenwiederholungen verursachen. Branch coverage test → Zweigüberdeckungstest. c-use Lesender Zugriff auf eine Variable in einer Berechnung. Die Variablen auf der rechten Seite einer Zuweisung werden berechnend benutzt. C0 -Test Kurzform für den → Anweisungsüberdeckungstest. C1 -Test Kurzform für den → Zweigüberdeckungstest. Code-Inspektion Manuelle Überprüfung von Software-Quellcode. Coding convention → Programmierkonvention. Condition coverage test → Bedingungsüberdeckungstest. Condition/decision coverage test → Bedingungs-/Entscheidungsüberdeckungstest. Cyclomatic number → zyklomatische Zahl. Datenflussanomalieanalyse Die Datenflussanomalieanalyse ist ein → statisches Analyseverfahren zur Entdeckung von Datenflussanomalien. Eine Datenflussanomalie ist eine fehlerhafte Zugriffssequenz auf eine Variable. Ein Beispiel ist der lesende Zugriff auf eine uninitialisierte Variable (eine so genannte ur-Anomalie). Datenflussorientierter Test → Dynamische Testtechniken sind datenflussorientiert, falls sie die Vollständigkeit des Tests anhand der Abdeckung des Datenflusses beurteilen. Die Zugriffe auf die Variablen bilden den Datenfluss. Datenkontext-Überdeckung Die Datenkontext-Überdeckung ist eine → dynamische, → datenflussorientierte Testtechnik. Die einfache Datenkontext-Überdeckung verlangt, dass alle existierenden Möglichkeiten den Variablen Werte zuzuweisen, mindestens einmal geprüft werden. Kann der Wert, den eine Variable an einer bestimmten Stelle der Software besitzt, an unterschiedlichen Stellen zugewiesen worden sein, so müssen alle diese unterschiedlichen Wertzuweisungen getestet werden. Die geordnete DatenkontextÜberdeckung verlangt zusätzlich zur Prüfung aller Möglichkeiten der Wertzuweisungen die Beachtung der Zuweisungsreihenfolgen. Decision coverage test → Zweigüberdeckungstest. Defect → Fehler. Definierender Zugriff (def) Schreibender Zugriff auf eine Variable. Die Variable auf der linken Seite einer Zuweisung wird definiert. Defs/Uses-Kriterien Die Defs/Uses-Kriterien sind eine Gruppe von → dynamischen, → datenflussorientierten Testtechniken. Die Variablenzugriffe werden in → definierende (def), prädikativ benutzende → (p-use) und berechnend benutzende → (c-use) Zugriffe unterteilt. Auf Basis dieser Datenflussattribute werden

510

Glossar

Regeln für die Beurteilung der Testvollständigkeit definiert. Diversifizierender Test → Dynamische Testtechniken sind diversifizierend, falls sie mehrere Versionen der zu testenden Software gegeneinander testen. Der → Back to Back-Test und der → Regressionstest sind Beispiele für diversifizierende Testtechniken Domain Testing → Bereichstest. Dummy Dummies werden im → Modultest und → Integrationstest benötigt, um unterlagerte Dienste zu simulieren. Soll ein Modul allein, außerhalb des Modulsystems getestet werden, so müssen aufgerufene Dienste durch Dummies ersetzt werden. Dynamischer Test Test eines Software-Systems in der echten oder einer simulierten Betriebsumgebung mit Testfällen auf einem Computer. Einfacher Bedingungsüberdeckungstest Der einfache Bedingungsüberdeckungstest ((simple) condition coverage) ist eine → dynamische, → strukturorientierte Testtechnik, die den Test aller atomaren Teilentscheidungen von zusammengesetzten Entscheidungen gegen beide Wahrheitswerte fordert. Empirische Verteilungsfunktion der Lebensdauer Trägt man den Anteil der bei einem Lebensdauerexperiment zum Zeitpunkt t ausgefallenen → Einheiten über t auf, so erhält man die empirische Verteilungsfunktion der → Lebensdauer. Error guessing Auswahl von Testfällen auf Basis von Erfahrung und Intuition; als alleinige Testtechnik unzureichend. Erschöpfender Test → Dynamischer Test aller möglichen Betriebssituationen. Der erschöpfende Test ist meistens undurchführbar und stets unpraktikabel. Fagan Inspection Formale Inspektionstechnik, die einem festen Ablauf folgt und bei der mit verteilten Rollen inspiziert wird. Failure → Fehlverhalten. Failure Mode, Effects and Criticality Analysis Vorbeugende Methode zur Identifikation von Problemen, deren Risiken und Auswirkungen /DIN EN 60812 06/, /IEC 60812 06/. Fault → Fehler. Fehler Ein Fehler ist bei Software die statisch im Programmtext vorhandene Ursache eines → Fehlverhaltens oder → Ausfalls. Fehlerbaum Der Fehlerbaum ist eine graphische Darstellung der logischen Zusammenhänge zwischen den Fehlerbaumeingängen (Ursachen) und einem vorgegebenen → unerwünschten Ereignis /DIN 25424 90/. Fehlerbaumanalyse Erstellen eines → Fehlerbaums zu einem vorgegebenen → unerwünschten Ereignis /DIN 25424 90/. Fehlerkategorie Fehlerkategorien dienen zur Klassifikation von → Fehlern nach Fehlertypen. Fehler werden einer oder mehreren Fehlerkategorien zugeordnet. Fehlermöglichkeits-, -einfluss- und -kritikalitätsanalyse → Failure Mode, Effects and Criticality Analysis Fehlerorientierter Test Eine → dynamische Testtechnik ist fehlerorientiert, falls sie auf einer konkreten Fehlererwartungshaltung basiert. Die → Grenzwertanalyse ist ein Beispiel für eine fehlerorientierte Testtechnik. Sie basiert auf der Annahme, dass Fehler an Bereichsgrenzen wahrscheinlich sind.

Glossar

511

Fehlverhalten Ein Fehlverhalten zeigt sich dynamisch bei der Benutzung eines Produkts. Beim → dynamischen Test erkennt man keine Fehler sondern → Fehlverhalten bzw. → Ausfälle. Fishbone Chart → Ishikawa-Diagramm. Formale Verifikation Die formale Verifikation demonstriert mit mathematischen Mitteln die Konsistenz zwischen → Spezifikation und Realisierung (Programmcode). FMECA → Failure Mode, Effects and Criticality Analysis. Funktionselement Ein Funktionselement ist die elementare Betrachtungseinheit eines Funktionssystems. Es darf nur eine elementare Funktion beschreiben, z. B. schalten, drehen, sperren, öffnen, mit Energie versorgen /DIN 25424 90/. Funktionale Äquivalenzklassenbildung Die funktionale Äquivalenzklassenbildung ist eine → dynamische, → funktionsorientierte Testtechnik. Sie leitet durch Bildung von → Äquivalenzklassen Testfälle aus der → Spezifikation ab. Funktionale Qualitätseigenschaften Qualitätseigenschaften, die die korrekte Funktion bestimmen (z. B. Vollständigkeit und Korrektheit). Funktionsorientierter Test → Dynamischer Test, der die → Testfälle aus der → Spezifikation ableitet und die Testvollständigkeit anhand der Abdeckung der Spezifikation mit Testfällen bewertet. Die → funktionale Äquivalenzklassenbildung ist eine funktionsorientierte Testtechnik. Grenzwertanalyse Die Grenzwertanalyse ist eine → fehlerorientierte Testtechnik. Sie verlangt die Wahl von Testfällen, die an Bereichsgrenzen liegen. Halstead-Maße Gruppe von Software-Maßen, die von M. Halstead vorgeschlagen worden ist Hardware-Software-Integrationstest Test der korrekten Interaktion zwischen Hardware und Software. Hardware-in-the-Loop-Testen Beim Hardware-in-the-Loop-Testen wird die vom Prüfling verwendete Umgebung weitgehend simuliert. Neben dem zu prüfenden System wird mindestens ein weiterer Computer verwendet, der als Testsystem arbeitet. Die Simulation der Umgebung des zu testenden Systems bietet insbesondere die Möglichkeiten, Beobachtungspunkte zu nutzen, die in der realen Umgebung nicht zugänglich sind. Darüber hinaus wird durch die Testablaufsteuerung sichergestellt, dass die Simulationen in einem festen Zeittakt ausgeführt werden. Dies ist eine wichtige Voraussetzung zur Validierung der Echtzeitfunktionen. Hoare-Kalkül Der Hoare-Kalkül enthält einen Satz von Axiomen, die im Rahmen der → formalen Verifikation zum Beweis der → Korrektheit dienen. Hybridmaß → Maß, das Eigenschaften von → Produkt- und → Prozessmaßen besitzt (z. B. die Function Points-Methode zur Aufwandsschätzung). Instrumentierung Modifikation einer zu testenden Software zur Aufzeichnung von Informationen während des → dynamischen Tests. Integrationstest Testaktivität, die begleitend zur Zusammenfassung von Komponenten zum SoftwareSystem geleistet wird. Intervallskala Eine Skala für → Maße, die auch dann noch gültig ist, falls Transformationen g(x) = ax + b, mit a > 0 auf sie angewendet werden. Irrtum Ursache eines → Fehlers. Ein Irrtum kann z. B. ein falsches Verständnis der Wirkung eines bestimmten Konstrukts der verwendeten Programmiersprache sein.

512

Glossar

Ishikawa-Diagramm Graphische Technik zur Analyse von Problemen. Kante, gerichtete Gerichtete Kanten sind Grundelemente des → Kontrollflussgraphen. Gerichtete Kanten verbinden stets zwei → Knoten. Kiviat-Diagramm Graphisches Hilfsmittel zur Darstellung von Messwerten. Knoten Knoten sind Grundelemente des → Kontrollflussgraphen. Sie repräsentieren Anweisungen einer Software. Komponente Eine Komponente ist die elementare Betrachtungseinheit eines → technischen Systems. Jeder Komponente sind ein oder mehrere Funktionselemente zugeordnet /DIN 25424 90/. Korrelationsdiagramm Korrelationsdiagramme sind ein einfaches Instrument zur Analyse der Abhängigkeit zwischen zwei Merkmalen auf Basis einer Menge von Merkmalspaaren. Die statistische Basis bildet der Korrelationskoeffizient. Kontrollflussgraph Ein Kontrollflussgraph ist ein gerichteter Graph G = ( N, E, nstart , n f inal ). N ist die endliche Menge der → Knoten. E ⊆ N × N ist die Menge der → gerichteten Kanten. nstart ∈ N ist der Startknoten. n f inal ∈ N ist der Endeknoten. Kontrollflussgraphen dienen zur Darstellung der Kontrollstruktur. Sie können um Datenflussattribute (z. B. → def, → c-use, → p-use) erweitert werden. Kontrollflussorientierter Test → Dynamische Testtechniken sind kontrollflussorientiert, falls sie die Vollständigkeit des Tests anhand der Abdeckung von Elementen der Kontrollstruktur beurteilen. Die kontrollflussorientierten Test stützen sich auf den → Kontrollflussgraphen. Der → Zweigüberdeckungstest ist ein Beispiel für eine kontrollflussorientierte Testtechnik. Korrektheit Konsistenz einer Realisierung und ihrer Spezifikation. Abwesenheit von → Fehlern. LCSAJ → Linear Code Sequence and Jump. LCSAJ-Test Der LCSAJ-Test ist eine → dynamische, → strukturorientierte Testtechnik auf Basis von → LCSAJs. In seiner ursprünglichen Form ist er sinnvoll einsetzbar für den Test von Software, deren Programmiersprache umfassenden Gebrauch von Sprüngen macht. Lebensdauer Zeitspanne von der Inbetriebnahme bis zum → Ausfall einer Betrachtungseinheit. Linear Code Sequence and Jump Eine LCSAJ (Linear Code Sequence and Jump) ist eine Folge von Anweisungen, die sequentiell ausgeführt wird und durch einen Sprung auf eine andere Anweisung als die folgende beendet wird. Markov-Modell Markov-Modelle basieren auf einer Beschreibung des Verhaltens mit Zustandsautomaten, die mit Übergangsraten versehen sind. Maß Größe zur Messung einer bestimmten Eigenschaft. Maße werden – etwas unsauber – auch als → Metriken bezeichnet. Mehrfach-Bedingungsüberdeckungstest Der Mehrfach-Bedingungsüberdeckungstest (multiple condition coverage test) ist eine → dynamische, → strukturorientierte Testtechnik. Er fordert den Test aller Wahrheitswertekombinationen der atomaren Teilentscheidungen der zusammengesetzten Entscheidungen. Mean Time between Failure Erwartungswert für die Zeitspanne zwischen zwei aufeinander folgenden → Ausfällen einer Betrachtungseinheit. Mean Time to Failure Erwartungswert für die Zeitspanne bis zum → Ausfall einer Betrachtungseinheit. Metrik Wird oft als Synonym für → Maß verwendet.

Glossar

513

Minimal multiple condition coverage test → Minimaler Mehrfach-Bedingungsüberdeckungstest. Minimaler Mehrfach-Bedingungsüberdeckungstest Der minimale Mehrfach-Bedingungsüberdeckungstest (minimal multiple condition coverage test) ist eine → dynamische, → strukturorientierte Testtechnik, die verlangt, dass neben den atomaren Teilentscheidungen und den Gesamtentscheidungen auch alle zusammengesetzten Teilentscheidungen gegen beide Wahrheitswerte getestet werden. Modified condition/decision coverage test → Modifizierter Bedingungs-/Entscheidungsüberdeckungstest. Modifizierter Bedingungs-/Entscheidungsüberdeckungstest Der modifizierte Bedingungs-/Entscheidungsüberdeckungstest (modified condition/decision coverage test) ist eine → dynamische, → strukturorientierte Testtechnik. Er verlangt Testfälle, die demonstrieren, dass jede atomare Teilentscheidung den Wahrheitswert der Gesamtentscheidung unabhängig von den anderen Teilentscheidungen beeinflussen kann. Die Anwendung dieser Technik wird vom Standard RTCA DO-178 B für flugkritische Software (Level A) in der Avionik gefordert. Modultest Test eines Moduls unabhängig und getrennt von anderen Modulen. MTBF → Mean Time between Failure. MTTF → Mean Time to Failure. Multiple condition coverage test → Mehrfach-Bedingungsüberdeckungstest. Mutationen-Test Der Mutationen-Test ist eine → dynamische, → diversifizierende Testtechnik. Die vergleichend getesteten Module werden aus einem Modul durch künstlich eingefügte Fehler abgeleitet. Nassi-Shneiderman-Diagramm Diagramm zur Darstellung von linearen Kontrollstrukturen; vermeidet Sprünge. Nichtfunktionale Qualitätseigenschaft Qualitätseigenschaft, die nicht direkt die korrekte Funktion eines → Systems bestimmt (z. B. Wartbarkeit oder Portierbarkeit ). Nominalskala Freie Bezeichnung bestimmter Eigenschaften mit Werten. Eine Reihenfolge der Bezeichnungen impliziert keine Reihung von Eigenschaften der bezeichneten Objekte. Ordinalskala Ordinalskalen bilden einen geordneten Aspekt einer Eigenschaft auf eine geordnete Menge von Messwerten ab und zwar so, dass die Ordnung erhalten bleibt. p-use Lesender Zugriff auf eine Variable in einer Entscheidung. Partielle Korrektheit Partielle Korrektheit herrscht, wenn die Reaktionen einer Software korrekt in Bezug auf ihre → Spezifikation sind. Partielle Korrektheit impliziert nicht, dass für alle Eingaben Ergebnisse erzeugt werden. Das erfordert zusätzlich einen → Terminationsbeweis. Der Beweis der partiellen Korrektheit und der Terminationsbeweis zeigen gemeinsam die → totale Korrektheit. Partition-Analyse Die Partition-Analyse ist eine Testtechnik aus der Gruppe der → Bereichstests. Sie wählt – wie der → Test fehleroffenbarender Unterbereiche – eine Kombination einer strukturorientierten und einer funktionsorientierten Äquivalenzklassenbildung. Path coverage test → Pfadüberdeckungstest. Perturbationen-Test Der Perturbationen-Test ist eine Variante des → Mutationen-Tests. Er sieht eine Modifikation von Anweisungen durch bestimmte Klassen von Fehlerfunktionen vor. Pfad Eine alternierende Sequenz von → Knoten und → gerichteten Kanten eines → Kontrollflussgraphen.

514

Glossar

Ein vollständiger Pfad beginnt mit dem Knoten nstart und endet mit dem Knoten n f inal des Kontrollflussgraphen. Pfadbereichstest → Dynamische Testtechnik, die durch eine gezielte Wahl von Testdaten an Pfadbereichsgrenzen fehlerhafte Pfadbereichsgrenzen aufspüren kann. Pfadüberdeckungstest Der Pfadüberdeckungstest ist eine → dynamische, → kontrollflussorientierte Testtechnik. Er fordert die Ausführung aller unterschiedlichen vollständigen → Pfade der zu testenden Software. Er ist im Allgemeinen unpraktikabel. Produktmaß → Maß, das Eigenschaften eines Produkts erfasst (z. B. Lines of Code (LOC) als Umfangsmaß). Program Slice Ein Program Slice beschreibt, welche Anweisungen auf welche Weise einen betrachteten Wert an einer bestimmten Stelle einer Software beeinflussen bzw. von ihm beeinflusst werden. Ein Slice wird also stets in Bezug auf einen betrachteten Wert an einer betrachteten Stelle der Software angegeben. Programmablaufplan Der Programmablaufplan ist eine dem → Kontrollflussgraphen ähnliche Form zur Darstellung der Kontrollstruktur eines Software-Moduls. Programmierkonvention Regel, die bei der Programmierung zu beachten ist (z. B. Beschränkung der erlaubten Programmkonstrukte). Prozess-Assessment Verfahren zur Bewertung des Reifegrads eines Entwicklungsprozesses. Prozessmaß → Maß, das Eigenschaften eines Prozesses erfasst (z. B. LOC/Mitarbeitertag als Produktivitätsmaß). Qualität Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse zu erfüllen (DIN 55350-11 95). Qualitätsanforderung Gesamtheit der Einzelanforderungen an eine Einheit, die die Beschaffenheit dieser Einheit betreffen. Qualitätseigenschaft → Qualitätsmerkmal. Qualitätsmaß → Maß, das einen Rückschluss auf die Ausprägung eines → Qualitätsmerkmals gestattet. Als Qualitätsmaß für das Qualitätsmerkmal → Zuverlässigkeit kann z. B. die → MTTF (Mean Time to Failure) verwendet werden. Qualitätsmerkmal Eigenschaft einer Funktionseinheit, anhand derer ihre → Qualität beschrieben und beurteilt wird, die jedoch keine Aussage über den Grad der Ausprägung enthält. Ein Qualitätsmerkmal kann über mehrere Stufen in Teilmerkmale verfeinert werden. Qualitätsregelkarte Statistisches Hilfsmittel im Rahmen der → statistischen Prozesskontrolle. Qualitätszielbestimmung Definition der für ein Produkt zu erreichenden → Qualität durch Festlegung der angestrebten Ausprägungen der → Qualitätseigenschaften. Die Qualitätszielbestimmung wird zu Beginn der Entwicklung durchgeführt. Qualitätszirkel Kleine Gruppe von Mitarbeitern, die sich regelmäßig mit dem Ziel treffen, in ihrem Arbeitsbereich auftretende Qualitätsprobleme zu lösen und aktiv Verbesserungen einzuführen. Random Test → Zufallstest. Rationalskala Eine Skala auf der Messwerte zueinander in Relation gesetzt werden können. Prozentuale Aussagen über Messwerte sind sinnvoll. Es darf dividiert werden.

Glossar

515

Referenzierender Zugriff Lesender Zugriff auf eine Variable. Vereinigungsmenge aus → p-uses und → c-uses. Regressionstest Wiederholung bereits durchgeführter Tests nach Änderungen. Der Regressionstest dient zur Überprüfung der korrekten Funktion nach Modifikationen, wie z. B. Fehlerkorrekturen oder Funktionserweiterungen. Required k-Tuples-Test Der Required k-Tuples-Test ist → dynamisch und → datenflussorientiert. Er fordert die Überdeckung von alternierenden Sequenzen aus Variablendefinitionen (→ defs) und Variablenbenutzungen (→ referenzierende Zugriffe). Durch Variation der Länge dieser Sequenzen entstehen mehrere Testtechniken. Review Manuelle Prüfung, die entweder in Sitzungstechnik oder in Kommentartechnik durchgeführt werden kann. Reviews in Sitzungstechnik werden in der Gruppe zu einer Zeit an einem Ort durchgeführt. Reviews in Kommentartechnik werden im Umlaufverfahren durchgeführt. Risikoprioritätszahl Die Risikoprioritätszahl dient bei der → FMECA als Gewicht potentieller Fehlverhaltensmechanismen. Hohe Risikoprioritätszahlen erfordern eine vorrangige Betrachtung bei der Findung von Gegenmaßnahmen. Robustheit Eigenschaft, auch in ungewöhnlichen Situationen definiert zu arbeiten und sinnvolle Reaktionen durchzuführen (z. B. Fähigkeit einer Software, Hardwareausfälle zu erkennen). SA → Strukturierte Analyse. SD-Diagramm Diagramm zur Darstellung einer funktional dekomponierten Software-Architektur. Segment Ein Segment eines → Kontrollflussgraphen ist eine Folge von → Knoten und → Kanten mit maximaler Länge, die die folgenden Eigenschaften besitzt: Sie kann ausschließlich über den ersten Knoten des Segments betreten werden. Falls der erste Knoten des Segments durchlaufen wird, so werden alle Knoten des Segments in der vorgegebenen Reihenfolge genau einmal durchlaufen. Sicherheit Abwesenheit unakzeptabler Risiken /IEC 61508 98/. /Birolini 97/ definiert Sicherheit als Maß für die Fähigkeit einer Betrachtungseinheit, weder Menschen, Sachen noch die Umwelt zu gefährden. Man unterscheidet die Sicherheit eines ausfallfreien Systems (Unfallverhütung) von der → technischen Sicherheit des ausfallbehafteten → Systems. Simple condition coverage test → Einfacher Bedingungsüberdeckungstest. SPC → Statistical Process Control (→ Statistische Prozesskontrolle). Special Values Testing → Error guessing. Spezifikation Die Spezifikation beschreibt das geforderte Verhalten. Sie dient im → funktionsorientierten Test u. a. zur Herleitung von Testfällen. Statement coverage test → Anweisungsüberdeckungstest. Statische Analyse Überprüfung unter Verzicht auf die Durchführung von → dynamischen Tests. Statistical Process Control → Statistische Prozesskontrolle. Statistische Prozesskontrolle Statistische Prozesskontrolle gestattet die Unterscheidung zwischen zufälligen Streuungen von Prozess-Kennzahlen eines stabilen Prozesses und systematischen Veränderungen des Prozesses mit Mitteln der Statistik (→ Qualitätsregelkarte).

516

Glossar

Stichprobe Die → dynamischen Testtechniken sind Stichprobenverfahren. Da in der Regel ein vollständiger Test aller Eingaben eines Programms nicht möglich ist, wird eine Stichprobe der Eingaben gewählt. Stochastischer Test → Zufallstest. Structured Analysis → Strukturierte Analyse. Structured Design Funktional dekomponierende Entwurfstechnik. Structured Walkthrough Konventionelles → Review in Sitzungstechnik; weniger formal als eine → Fagan Inspection. Strukturierte Analyse Funktional dekomponierende Analysetechnik. Strukturierter Pfadtest Der strukturierte Pfadtest ist eine → kontrollflussorientierte, → dynamische Testtechnik. Er sieht eine eingeschränkte Form des → Pfadüberdeckungstests vor. Abstriche werden beim Test von Schleifen vorgenommen. Strukturdiagramm → SD-Diagramm. Strukturorientierter Test Der strukturorientierte Test beurteilt die Testvollständigkeit anhand der Abdeckung von Elementen der Software-Struktur durch Tests. Alle strukturorientierten Tests sind → White Box-Tests. Symbolic Model Checking Formale Nachweistechnik für Eigenschaften zustandsendlich beschriebener Systeme. Symbolischer Test Test mit allgemeinen symbolischen Eingabewerten. Syntaxtest → Funktionsorientierte, → dynamische Testtechnik auf Basis von Syntaxgraphen oder Syntaxbeschreibungen in Backus-Naur-Form. System Zusammenfassung technischer und organisatorischer Mittel zur autonomen Erfüllung eines Aufgabenkomplexes /Birolini 97/. Ein System kann im allgemeinen aus Hardware, Software, Menschen (Bedienungs- und Instandhaltungspersonal) und logistischer Unterstützung bestehen. Technische Sicherheit Maß für die Fähigkeit einer ausfallbehafteten Betrachtungseinheit, weder Menschen, Sachen noch die Umwelt zu gefährden. Man unterscheidet die → Sicherheit eines ausfallfreien Systems (Unfallverhütung) von der technischen Sicherheit des ausfallbehafteten Systems. Technisches System → System, bei dem Einflüsse durch Menschen und Logistik vernachlässigt werden. Terminationsbeweis Beweis, dass ein Algorithmus stets terminiert, also für alle Eingaben ein Ergebnis liefert. Testdatengenerator Werkzeug, das Unterstützung bei der Erzeugung von Testdaten bietet. Testfall → Betriebssituation, die für die Testdurchführung benutzt wird. Test fehleroffenbarender Unterbereiche Der Test fehleroffenbarender Unterbereiche gehört zur Gruppe der → Bereichstests. Er bildet Äquivalenzklassen anhand der Software-Struktur und der Spezifikation. Testpfad Durch einen Testfall ausgeführter → Pfad einer Software. Testrahmengenerator Werkzeug, das automatisch → Testtreiber und → Dummies erzeugt. Testtreiber Testtreiber bieten die für den → Modultest bzw. → Integrationstest notwendige Möglichkeit zum interaktiven Aufruf der zu testenden Dienste.

Glossar

517

Testvollständigkeit Beurteilung der Vollständigkeit einer durchgeführten → Stichprobe im Rahmen des → dynamischen Tests. Top Down-Test → Integrationstestverfahren. Integration von Modulen beginnend mit hohen Diensten in Richtung tieferer Dienste. Total Quality Management Auf der Mitwirkung aller ihrer Mitglieder basierende Führungsmethode einer Organisation, die → Qualität in den Mittelpunkt stellt und durch Zufriedenheit der Kunden auf langfristigen Geschäftserfolg sowie auf Nutzen für die Mitglieder der Organisation und für die Gesellschaft zielt /DIN EN ISO 9000 05/. Totale Korrektheit Totale Korrektheit herrscht, wenn zusätzlich zur → partiellen Korrektheit die Termination bewiesen ist. Dann ist gezeigt, dass stets ein Ergebnis erzeugt wird und dass dieses Ergebnis stets korrekt ist. Transaktionsflussbasierter Test → funktionsorientierte, → dynamische Testtechnik auf Basis von Transaktionsflussdiagrammen. Überdeckungsgrad → Maß für den Grad der Vollständigkeit eines Tests bezogen auf eine bestimmte Testtechnik. Der Überdeckungsgrad des → Zweigüberdeckungstests kann als Quotient der bereits mit Testfällen durchlaufenen → Zweige und der Gesamtzahl der Zweige definiert werden. Überlebenswahrscheinlichkeit Wahrscheinlichkeit, ein → System, das zum Zeitpunkt 0 in Betrieb genommen wurde, zum Zeitpunkt t noch intakt anzutreffen. UML → Unified Modeling Language. Unerwünschtes Ereignis Das unerwünschte Ereignis (Fehlerbaumausgang, TOP) ist bei einer → Fehlerbaumanalyse der Ausfall des untersuchten Funktionssystems. Dies kann durch verschiedene → Ausfallkombinationen verursacht werden /DIN 25424 90/. Unified Modeling Language Objektorientierte Entwicklungsmethode. Ursache-Wirkungs-Analyse → Funktionsorientierte, → dynamische Testtechnik, die die → Spezifikation in eine graphische Form – den → Ursache-Wirkungs-Graph – umsetzt, aus dem über Zwischenschritte Testfälle abgeleitet werden. Ursache-Wirkungs-Graph Graphische Darstellung der Zusammenhänge zwischen Ursachen und Wirkungen im Rahmen der → Ursache-Wirkungs-Analyse. Der Ursache-Wirkungs-Graph wird in eine Entscheidungstabelle transformiert, die als Basis für die Erzeugung von Testfällen dient. Validation Überprüfung, ob ein Software-Produkt die Anforderungen und Bedürfnisse des Benutzers befriedigt. Verfügbarkeit Maß für die Fähigkeit einer Betrachtungseinheit, zu einem gegebenen Zeitpunkt funktionstüchtig zu sein. Verifikation (allgemein) Überprüfung, ob die Ergebnisse einer Entwicklungsphase die Anforderungen zu Beginn der Phase erfüllen. Achtung: Dieser Begriff darf nicht mit der formalen Verifikation verwechselt werden. Verifikation (formal) → Formale Verifikation. Verteilungsfunktion der Lebensdauer Geht die Anzahl der Betrachtungseinheiten bei einem Lebensdauerexperiment gegen unendlich, so approximiert die → empirische Verteilungsfunktion der Lebensdauer die Verteilungsfunktion der Lebensdauer F(t). Hier ist die → Lebensdauer eine Zufallsvariable und es gilt: F(t) = P{T ≤ t}. F(t) ist die Wahrscheinlichkeit, dass die Lebensdauer T kleiner oder gleich t ist, also eine

518

Glossar

Betrachtungseinheit spätestens zum Zeitpunkt t ausgefallen ist. Vollständigkeit Eine → Software ist funktional vollständig, wenn alle in der → Spezifikation geforderten Funktionen implementiert sind. Das betrifft sowohl die Behandlung von Normalfällen als auch das Abfangen von Fehlersituationen. Wahrscheinlichkeitsdichte der Lebensdauer Lebensdauer.

Erste zeitliche Ableitung der → Verteilungsfunktion der

White Box-Test White Box-Tests nutzen Informationen über die Struktur der Software. Die → kontrollflussorientierten und die → datenflussorientierten Tests sind Beispiele für White Box-Tests. Zufallstest Der Zufallstest ist eine → dynamische → Black Box-Testtechnik, die Testfälle nach statistischen Kriterien wählt. Zusicherung Zusicherungen (assertions) sind logische Formeln, die im Programmcode verwendet werden, um Aussagen formal zu notieren. Zustandsbasierter Test → funktionsorientierte, → dynamische Testtechnik auf Basis von → Zustandsautomaten oder Zustandsübergangstabellen. Zustandsautomat Darstellungsmittel für das Verhalten zustandslastiger → Systeme. Zustandsautomaten bilden die Basis für den → zustandsbasierten Test. Zustandsübergangstabelle

Alternative Darstellungsform für → Zustandsautomaten.

Zuverlässigkeit Teil der → Qualität im Hinblick auf das Verhalten der Einheit während oder nach vorgegebenen Zeitspannen bei vorgegebenen Anwendungsbedingungen /DIN 40041 90/. Sammelbegriff zur Beschreibung der → Verfügbarkeit und ihrer Einflussfaktoren Funktionsfähigkeit, Instandhaltbarkeit und Instandhaltung /DIN EN ISO 9000 05/. → Maß für die Fähigkeit einer Betrachtungseinheit, funktionstüchtig zu bleiben, ausgedrückt durch die Wahrscheinlichkeit, dass die geforderte Funktion unter vorgegebenen Arbeitsbedingungen während einer festgelegten Zeitdauer ausfallfrei ausgeführt wird. Zuverlässigkeitsblockdiagramm Zusammenschaltung sämtlicher Komponenten einer Betrachtungseinheit, die an der Erfüllung der geforderten Funktion beteiligt sind, in Form eines Flussdiagramms. Darin erscheinen die für die Funktionserfüllung notwendigen Komponenten in Serie und die Redundanten parallel /Birolini 97/. Zweig Ein Zweig entspricht einer → gerichteten Kante des → Kontrollflussgraphen. Der → Zweigüberdeckungstest fordert die Ausführung aller Zweige. Zweigüberdeckungstest Der Zweigüberdeckungstest ist eine → dynamische, → kontrollflussorientierte Testtechnik für Software. Er fordert die Überdeckung aller → Kanten des → Kontrollflussgraphen. Zyklomatische Zahl Die zyklomatische Zahl ist ein → Maß für die Verzweigungskomplexität von → Kontrollflussgraphen. Sie gibt die Anzahl der linear unabhängigen Pfade eines Kontrollflussgraphen an und ist für Software stets um eins größer als die Anzahl der Entscheidungen.

Glossar

519

“This page left intentionally blank.”

Index A Abnahmetest, 509 Absolutskala, 239, 509 Ad hoc-Test, 509 Algebraische Spezifikation, 351, 422 all c-uses/some p-uses-Kriterium, 147 all c-uses-Kriterium, 147 all defs-Kriterium, 147 all du-paths-Kriterium, 148 all p-uses-Kriterium, 147 all uses-Kriterium, 148 Alpha-Test, 377 Analyse funktional dekomponierende, 368 objektorientierte, 368 statische, 43, 516 Analysewerkzeug, 397 Anomalie, 292 Anweisungsüberdeckungsgrad, 85 Anweisungsüberdeckungstest, 85, 509 Appraisal, 12 AQAP-Century-Standards, 383 Äquivalenz, 207 Äquivalenzklasse, 51, 509 gültige, 52 ungültige, 52 Äquivalenzklassenanalyse, 509 Äquivalenzklassenbildung funktionale, 414 strukturorientierte, 196 Assertion, 211, 271, 274, 337, 346, 386, 509 Assessment, 12, 509 Aufrufdiagramm, 276 Ausführungsbaum, 329 Ausfall, 6, 7, 509 Ausfallkombination, 509 Ausfallrate, 37, 457 Aussagenlogik, 212, 222 B Back to Back-Test, 40, 444, 509 Backus-Naur-Form, 42, 366 Badewannenkurve, 460 Basisklasse, 428 Bedingungs-/Entscheidungsüberdeckungstest, 99, 509 modifizierter, 106 Bedingungsüberdeckungstest, 93, 509 einfacher, 95, 511 mehrfacher, 111, 513

minimal mehrfacher, 101, 514 Berechnungsfehler, 136, 196 Bereichsfehler, 196 Bereichstest, 195, 509 Beta-Test, 377, 437, 509 Big Bang-Test, 510 Black Box-Test, 40, 51, 510 Block, 277 BOOTSTRAP, 11, 26 Bottom-up-Integrationstest, 372, 510 Boundary interior-Pfadtest, 118, 301, 510 modifizierter, 124 Branch coverage test, 88, 510 C c-use, 142, 144, 421, 510 C0 -Test, 85, 510 C1 -Test, 88, 510 Capability Maturity Model, 20, 232 Capability Maturity Model Integration, 20 CIP, 15 CMM, 20 CMMI, 20 Code-Inspektion, 272, 510 Codeanalyse, 270 Coding convention, 510 Company-Wide Quality Control, 16 computational-use, 142 Condition coverage, 93 minimal multiple, 93 multiple, 93, 111 simple, 93 Condition/decision coverage, 99 modified, 106 Condition coverage test, 510 Condition/decision coverage test, 510 Context coverage, 171 Continuous Improvement Process, 15 Continuous Representation, 22 Coupling effect, 185 Cyclomatic number, 510 D Datenabstraktion, 351, 369, 409 Datenflussanomalieanalyse, 292, 398, 485, 510 Datenflussanomalieanalyse-Werkzeug, 398 Datenflussattribut, 142, 513 Datenflussorientierter Test, 142, 510 Datenkontext, 171 elementarer, 171

521

Datenkontext-Überdeckung, 171, 510 einfache, 172 erweiterte, 173 geordnete, 171 dcu(x, ni ), 146 dd-Anomalie, 296 Deadlock, 377 Decision coverage test, 510 def, 144 Defs/Uses-Kriterium, 511 def(ni ), 147 Defect, 7, 510 Defekt, 7 Definition, 142, 293 Definitionenkontext, 171 Defs/Uses-Kriterium, 144 Defs/Uses-Test, 144 Deming-Zyklus, 16 Dependability, 8, 441, 442 DIN EN 50128, 378, 387 Diskriminanzanalyse, 253 Diversifizierender Test, 40, 511 Diversitäres Programm, 180 Domain Testing, 196, 511 dpu(x, ni ), 146 Driver, 371 du-Anomalie, 296 Dummy, 371, 511 Dynamischer Test, 511 E Echtzeitfähigkeit, 369, 443 harte, 443 weiche, 443 Einfacher Bedingungsüberdeckungstest, 95, 511 Elementare Modifikation, 242 Elementarer Datenkontext, 171 Empirische Relation, 239 Empirische Verteilungsfunktion der Lebensdauer, 455, 511 Entscheidungsbaum, 79 Entscheidungstabelle, 79 Entwicklung evolutionäre, 363 prototyporientierte, 363 inkrementelle, 364 Entwurf funktional dekomponierender, 369 objektorientierter, 369 Error, 7 Error guessing, 210 Error guessing, 511 Evolutionärer Prototyp, 363

522

Exponentialverteilung, 458, 471 Exportknoten, 143 Extreme Programming, 364 F Fagan Inspection, 306, 511 Failure, 6, 511 Failure Mode and Effects Analysis, 33 Failure Mode, Effects and Criticality Analysis, 33 Fault, 7 Fault, 511 Fehler, 7, 511 Fehleraufzeichnung, 486 Fehlerbaum, 36, 446, 511 Fehlerbaumanalyse, 33, 447, 511 Fehlerbaumanalyse-Werkzeug, 399 Fehlerkategorie, 511 Fehleroffenbarender Unterbereich, 203 Fehlerorientierter Test, 512 Fehlverhalten, 6, 512 Fischers Verfahren, 253 Fishbone Chart, 16, 28, 512 Floyd’sches Verifikationsverfahren, 335 Flussdiagramm, 281 FMEA, 33 FMECA, 33, 445 für Software, 446 FMECA-Werkzeug, 400 Formale Technik, 44, 366, 483 Formale Verifikation, 512 Function Point-Maß, 235, 397, 512 Function Point-Methode, 247 Funktionale Äquivalenzklassenbildung, 42, 512 Funktionselement, 512 Funktionsorientierter Test, 512 Funktionstest, 377, 435 G Gesetz, 382 Goal-Question-Metric, 14 GQM, 14 Grafik, 276 Grafikwerkzeug, 398 Grenzwertanalyse, 512 H Haftungsausschluss, 382 Halstead-Maß, 260, 512 Hardware-in-the-Loop-Test, 445, 512 Hardware-Qualitätssicherung, 4, 30, 32 Hardware-Software-Integrationstest, 512 Hoare-Kalkül, 344, 512

Index

Holdout-Verfahren, 470 Hybridmaß, 512 I IEC 61508, 384 Implementierung, 370 Importknoten, 143 Induktionsbeweis, 340 Inferenzregel, 346 Inspektion, 306 formale, 308 Inspektionsphasen, 309 Inspektionsrate, 312 Instrumentierung, 114, 395, 512 Integration, 370 Integrationsprüfung, 370 Integrationstest, 46, 370, 489, 512 Bottom-up-, 372 objektorientierter, 428 Outside-In-, 375 Top-down-, 374 Intensiv-Inspektion, 308 Interaktionen-Subpfad, 164 Intervallskala, 239, 512 Irrtum, 7, 513 Ishikawa-Diagramm, 16, 28, 513 ISO 9000, 19 Isomorphismus, 207 K k-dr-Interaktion, 163 Kaizen, 15 Kante gerichtete, 277, 513 Kiviat-Diagramm, 248, 513 Klassentest, 411 Klassifikationsschema, 37 Knoten, 294, 513 Kommentartechnik, 318 Kommutativgesetz der Programmausführung, 333 Kompatibilität, 207 Komponente, 513 Kompositionsregel, 348 Kontrollflussgraph, 85, 171, 236, 276, 286, 513 Kontrollflussorientierter Test, 41, 419, 513 Kopplungseffekt, 187 Korrektheit, 7, 513 partielle, 342, 349, 514 totale, 349, 518 Korrektheitsbeweis, 45, 335 Korrelationsdiagramm, 29, 513 Kritikalitätslevel, 387 Kritikalitätsstufe, 378, 484

Index

L LCSAJ, 132, 513 LCSAJ-Test, 132, 513 Least Squares, 463 Lebensdauer, 2, 33, 263, 449, 513 Lebensdauerversuch, 34 Leistungstest, 377 Leistungstestwerkzeug, 396 Line of Code, 252, 267 Linear Code Sequence And Jump, 132, 513 Live Variables, 267 Logarithmische Normalverteilung, 460 M Maß, 234, 513 Forderungen, 236 Maßskala, 238 Maßtyp, 234 Markov-Analyse, 33, 445 Markov-Modell, 36, 446, 513 Markov-Werkzeug, 400 Maturity Model, 11 Maturity Level, 22 Maximum Maximum-Likelihood, 463 Mean Time between Failure, 9, 513 Mean Time to Failure, 9, 513 Mean Time to Repair, 9 Mehrfach-Bedingungsüberdeckungstest, 93 Messwerkzeug, 397 Metrik, 233, 514 Minimal multiple condition coverage, 93 Minimaler Mehrfach-Bedingungsüberdeckungstest, 101 Modified condition/decision coverage, 93 Modulprüfung, 371 Modultest, 31, 57, 370, 485, 514 objektorientierter, 411 MTBF, 9, 457, 514 MTTF, 9, 457, 514 MTTR, 9 Mutant, 185 Mutation, 185 Mutationen-Test, 185, 514 schwacher, 188 starker, 187 Mutations-Transformation, 186 N N-Versionen-Programmierung, 180 Nachbedingung, 219, 337 Nassi-Shneiderman-Diagramm, 282, 514 Nominalskala, 238, 514 Norm, 382 Normung, 382

523

Null-Fehler-Programm, 15 O OBDD, 399 Ordered Binary Decision Diagram, 399 Ordinalskala, 238, 445, 514 Outside-In-Integrationstest, 375 P p-use, 144, 280, 421, 514 PAP, 281 Parametrisierte Klasse, 426 Pareto-Analyse, 28 partition testing, 208 Partition-Analyse, 206, 514 path coverage, 136 Path coverage test, 514 PCA, 253 Peer Review, 306 Perturbationen-Test, 514 Pfad, 145, 515 Pfadüberdeckungstest, 41, 136, 515 Pfadbereich, 207 Pfadbereichstest, 196, 515 Pfadtest, 138 boundary interior, 117 strukturierter, 117 Phasenmodell, 363 Prädikatenlogik, 212, 222 Prüforganisation, 46 Prüfplan, 34 Prüfplangenerierung, 34 Prüfstrategie, 485 Prüfung, 37, 370, 392, 428 predicate-use, 142 Prequential-Likelihood-Verfahren, 467 Principal Component Analysis, 253 Prinzip der integrierten Qualitätssicherung, 2 Produkthaftungsgesetz, 382 Produktmaß, 234, 515 Program Slice, 515 Programmablaufplan, 108, 281, 515 Programmierkonvention, 370, 485, 515 für C, 273 semantische, 272 syntaktische, 272 Programmierregel, 271 Prozess, 489 Prozess-Assessment, 23, 482, 515 Prozessmaß, 234, 515

524

Q QFD, 30 Qualität, 5, 515 Qualitätsanforderung, 5, 515 Qualitätseigenschaft, 515 funktionale, 440 nicht-funktionale, 440, 514 Qualitätseigenschaften, 6 Qualitätsmaß, 6, 515 Qualitätsmanagement, 10 Qualitätsmerkmal, 5, 515 Qualitätsregelkarte, 515 Qualitätsverantwortung, 47, 378, 482 Qualitätszielbestimmung, 515 Qualitätszirkel, 16, 28, 515 Quality Function Deployment, 30 R Random Test, 208, 515 Rapid prototyping, 363 Rationalskala, 238, 239, 516 Redundanz heterogene, 181 homogene, 181 Referenz, 286 Referenzierender Zugriff, 516 Regressionsanalyse, 253 Regressionstest, 42, 378, 436, 444, 486, 516 Regressionstestwerkzeug, 402 Reifegrad, 22 Reliability, 9, 441 Repeated Event, 450 Required k-Tuples-Test, 163, 516 Required Elements Test, 163 Review, 237, 436, 485, 516 Kommentartechnik, 318 Sitzungstechnik, 317 Reviewtechniken, 485 Richtlinie, 382 Risikoprioritätszahl, 238, 400, 447, 516 Robustheit, 10, 516 RTCA/DO 178B, 388 S SA, 2, 365, 516 SA/RT, 367 SADT, 366 Safety, 8, 441 Safety Integrity Level, 387 Schadensersatzanspruch, 382 Schlussfolgerungsregeln, 346 Schwache Ordnung, 239 Schwacher Mutationen-Test, 188 SD, 2, 365

Index

SD-Diagramm, 516 Security, 441 Segment, 171, 277, 516 Semantik, 272, 366 Sequence Chart, 76, 276, 435 Sequenzdiagramm, 76, 81 Sicherheit, 5, 8, 440, 441, 445, 516 technische, 8, 441, 517 SIL, 387 simple condition coverage, 93 Simple condition coverage test, 516 Six Sigma, 16 Skalentyp, 238 Slice, 515 Slicing, 44, 285 backward, 285 forward, 285 dynamisches, 286 statisches, 286 Slicing-Werkzeug, 398 Software Inspection, 308 Software-Entwicklungsprozess, 2, 10, 362 Software-FMECA, 446 Software-Level, 388 Software-Messung, 232 Software-Qualitätssicherung, 4, 30, 276, 378 Software-Zuverlässigkeitsanalyse, 400, 453 SPC, 516 Special Values Testing, 210, 516 Spezifikation, 380, 516 SPICE, 22, 383, 385 Staged Representation, 23 Standard, 382 prozessorientierter, 383 technischer, 384 Starker Mutationen-Test, 187 Statement coverage test, 85, 516 Statische Analyse, 43, 516 Statistical Process Control, 516 Statistische Prozesskontrolle, 517 Stellvertreter, 371 Stichprobe, 517 Stilanalysator, 398 Stilanalyse, 271 Stochastischer Test, 517 Stresstest, 377, 437 Stresstestwerkzeug, 396 Strong mutation test, 187 Structure Chart, 282 Structured Walkthrough, 306 Structured Analysis, 2, 365, 517 Structured Analysis/Real Time Analysis, 367 Structured Design, 2, 365, 517 Structured Walkthrough, 517

Index

Strukturdiagramm, 394, 517 Strukturierte Analyse, 365, 517 Strukturierter Entwurf, 365 Strukturierter Pfadtest, 117, 517 Strukturorientierter Test, 517 Subpfad, 146, 171 Symbolic Model Checking, 399 Symbolic Model Checking, 45, 354, 517 Symbolische Modellprüfung, 354 Symbolischer Test, 325, 517 Syntax, 365 Syntaxtest, 73, 517 System, 517 technisches, 517 Systemprüfung, 376 Systemtest, 46, 75, 371, 489 objektorientierter, 435 T Tabelle, 284, 398 Technik algebraische, 45 automatenbasierte, 45 formale, 483 formatierte, 365 informale, 364 semiformale, 366 Technische Sicherheit, 441, 517 Technisches System, 517 Terminationsbeweis, 517 Terminationsfunktion, 350 Test Ad hoc, 39, 509 datenflussorientierter, 142, 510 diversifizierender, 40, 511 dynamischer, 39, 511 erschöpfender, 511 fehlerorientierter, 512 funktionsorientierter, 40, 512 kontrollflussorientierter, 41, 419, 513 parametrisierter Klassen, 426 strukturorientierter, 40, 517 symbolischer, 325 transaktionsflussbasierter, 518 zustandsbasierter, 519 Test fehleroffenbarender Unterbereiche, 203, 517 Test spezieller Werte, 208, 210 Testbett, 371 Testdatengenerator, 324, 517 Testfall, 517 Testmaß, 85, 112 Testpfad, 517 Testrahmen, 371

525

Testrahmengenerator, 517 Testreferenz, 40 Testtreiber, 371, 518 Testvollständigkeit, 518 Testwerkzeug, 376 dynamisches, 393 funktionsorientiertes, 395 strukturorientiertes, 396 Top Down-Test, 518 Top-down-Integrationstest, 374 Total Quality Management, 379, 518 Totales Qualitätsmanagement, 15, 378 TQM, 15 Transaktionsflussbasierter Test, 518 Treiber, 371 U U-Plot-Verfahren, 467 Überdeckungsgrad, 518 Überlebenswahrscheinlichkeit, 9, 456, 518 UML, 2, 58, 222, 368, 518 Undefinition, 293 Unerwünschtes Ereignis, 518 Unfallverhütung, 8, 441 Unified Modeling Language, 2, 354, 367, 410, 518 ur-Anomalie, 296 Ursache-Wirkungs-Analyse, 42, 66, 518 Ursache-Wirkungs-Diagramm, 28 Ursache-Wirkungs-Graph, 66, 79, 518 Use Case, 435

Werkzeug, 391 Informationen über, 403 Verfügbarkeit, 401 White Box-Test, 40, 519 Wirtschaftlichkeit, 488 Z Zero Defects Concept, 15 Zertifizierung, 482 Zufallstest, 208, 519 Zusicherung, 211, 274, 337, 412, 485, 519 Zustandsübergangstabelle, 61, 519 Zustandsautomat, 58, 354, 519 Zuverlässigkeit, 8, 442, 519 Zuverlässigkeitsblockdiagramm, 33, 36, 446, 519 Zweig, 277, 519 Zweigüberdeckungsgrad, 92 Zweigüberdeckungstest, 88, 519 Zyklomatische Zahl, 236, 243, 256, 519

V Validation, 518 Variablen-Cross-Reference-Tabelle, 284 Variablenspanne, 263 Vererbung, 430 Verfügbarkeit, 9, 442, 518 Verfahren der kleinsten Fehlerquadrate, 463 Verifikation, 518 Verifikationswerkzeug, 398 Verlässlichkeit, 9, 442 Verordnung, 382 Verteilungsfunktion der Lebensdauer, 456, 519 Vollständigkeit, 8, 519 Vorbedingung, 219, 337, 348 W Wahrscheinlichkeitsdichte der Lebensdauer, 457, 519 Wasserfallmodell, 363 Weak mutation test, 188 Wechselwirkungen, 6 Wegwerfprototyp, 363

526

Index