Software-Qualität

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.

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.

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.

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.

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.

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

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

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.

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.

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 einesWerkzeuges, 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.

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.

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.

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.