Softwaretest Teil 1 Statische Tests: Formale und nicht formale Dokumente richtig nutzen

Auf hohe Softwarequalität zu verzichten kann sich heute kein Unternehmen mehr leisten. Um so erstaunlicher ist es, daß auf ein bewährtes Instrumentarium für die Messung und Sicherstellung von Qualität zu wenig zurückgegriffen wird: die Begutachtung von projektrelevanten Dokumenten in gedruckter und elektronischer Form. Dazu zählen alle Arten von Spezifikationen, Unterlagen zur Projektlenkung sowie der Programmcode selbst.

Anbieter zum Thema

MES Electronic Connect GmbH & Co. KG

Cadlog Group

ALPHA-Numerics GmbH

Mixed Mode GmbH

Es gehört zu den gesicherten Erfahrungen, daß etwa 75% der Fehler in einem Softwareprodukt in den ersten beiden Projektphasen (Definition, Entwicklung) entstehen. Demgegenüber werden 80% der Fehler erst in den letzten beiden Phasen (Endprüfung und Einsatz) entdeckt und behoben. Sinnvoll ist es deshalb, beides möglichst zur Deckung zu bringen.

Alle statischen Testverfahren haben eines gemein: die Software wird nicht ausgeführt. Deswegen werden sie vielfach nicht mit den dynamischen Testverfahren in gedankliche Verbindung gebracht, obwohl sie wie diese das Ziel haben, die Produktqualität zu sichern. In sich zerfallen die statischen Verfahren in zwei Hauptgruppen: solche, die zwingend ein formales Dokument als Prüfgegenstand verlangen und solche, bei denen dies nicht der Fall ist.

Statische Analyse an formalen Dokumenten

Dokumente, die formalen Kriterien genügen, sind Programmcode, streng formalistische Systembeschreibungen wie UML-Diagramme und dergleichen. Sie sind geeignet zur toolgestützten statischen Analyse. Für Code werden naturgemäß am häufigsten Compiler eingesetzt. Sie bieten unterschiedlich penible Stufen zur Codeanalyse, die quasi gleichzeitig mit der Erstellung der ausführbaren Datei durchgeführt wird. Dadurch erhält man Warnhinweise auf problematische Stellen. Deren Beurteilung bleibt dem Bearbeiter überlassen.

Naturgemäß stoßen Compiler bei Fehlerzuständen, die erst zur Laufzeit auftreten können, schnell an ihre Grenzen. Analysatoren wie PC-Lint oder Valgrind leisten hier mehr, da bei ihnen die Analyse des Daten- und Kontrollflusses im Vordergrund steht. Sie simulieren einen Programmlauf, ermitteln die möglichen Zustände von Variablen und Programmabschnitten mit Schleifen, Verzweigungen, etc. Dadurch werden fatale Ereignisse wie Division durch Null, Sackgassen oder nicht ausführbarer Code ermittelt, die durch bestimmte Bedingungen wie unglückliche Variablenbelegungen oder Kombinationen von Einsprungbedingungen erst zur Laufzeit entstehen können. Auch Speicherlecks können so gefunden werden.

Es gibt einige weitere Methoden, die bestimmte Kennzahlen an Code ermitteln wie zum Beispiel die zyklomatische Komplexität nach McCabe. Sie gibt an, wie viele Schleifen und Verzweigungen ein Code enthält. In der Praxis haben solche Zahlen eher relativ wenig Bedeutung, außer, daß sie einen Hinweis auf den erforderlichen Testaufwand geben können. Da sie rein aus dem Code berechnet werden, ohne dass die Komplexität der zugrundeliegenden Aufgabe mit eingeflossen wäre (wie wollte man die auch nachvollziehbar ermitteln), erfordern sie zur Beurteilung auf jeden Fall einen genauen Blick auf den Code selbst durch einen erfahrenen Programmierer.

Um einen schnellen Überblick über komplex aufgebaute Programme zu bekommen, werden häufig Tools eingesetzt, die aus dem Code Übersichtsdiagramme z.B. nach der UML erstellen. Umgekehrt ist es möglich, daraus ein Codegerüst erstellen zu lassen. Solche Diagramme unterstützen die Überprüfung der Systemarchitektur auf Konsistenz und Zweckmäßigkeit verglichen mit der gestellten Aufgabe.

Formale Analysen können jedoch eines nicht: mangelhafte oder nicht zweckmäßige Systemarchitektur aufdecken. Anders gesagt: selbst wenn der Code so gut wie nie in Fehlerzustände gerät, das ganze System aber seine Aufgabe nur mangelhaft löst, dann liegt ein Qualitätsproblem vor. Auch dies liest sich trivial, ist aber aus ganz bestimmten Gründen mit die häufigste Ursache für mangelhafte oder fehlerhafte Softwareprodukte.

Statische Analyse an nicht formalen Dokumenten

Bei der Produktspezifikation wird in der Regel von den positiven Anwendungsfällen ausgegangen. Das heißt, die Frage „Was soll das Produkt in welchem Anwendungsfall, bei welchem Bedienungsschritt machen“ ist der Leitfaden, mit dessen Hilfe die Produktspezifikation erarbeitet wird. Selbstverständlich werden Benutzungsfehler, Fehlbedienungen und ähnliches regelmäßig von vorneherein mit einkalkuliert. Die Zahl der möglichen Fehlbedienungen kann aber je nach Art des Produktes ein Vielfaches der möglichen Gutfälle annehmen, so daß immer die Gefahr besteht, besonders ungute Kombinationen von Fehlbedienungen nicht berücksichtigt zu haben.

Eine weitere Falle tut sich im Schritt von der Produkt- zur Systemspezifikation auf. Das bedeutet, die von dem zukünftigen Produkt zu lösenden Aufgaben werden so aufgeteilt, daß sie in Softwaremodule unter Berücksichtigung von Qualitätsmerkmalen wie Effizienz, Bedienbarkeit, Wartbarkeit etc. umgesetzt werden können.

Die Produktspezifikation wird nicht immer von erfahrenen Programmdesignern gemacht, letztere möglichst schon. Bei der Umsetzung der Funktionen des Produkts in Software ergeben sich eine Reihe weiterer Fragen, die in der Natur von Software liegen und die vorher überhaupt noch nicht gestellt werden können. Über die scheinbar wiederum triviale Tatsache, daß Software eben nur genau das tut, was in ihren Anweisungen steht, wird dabei mit schöner Regelmäßigkeit gestolpert: Verhaltensweisen, die als selbstverständlich erwartet werden, aber nicht spezifiziert und deshalb auch nicht mitcodiert wurden, gibt es dann einfach nicht. Solchen Mängeln und Fehlern kann frühzeitig begegnet werden, indem entsprechende Dokumente vor der jeweils nächsten Projektphase begutachtet werden. Reviews und Inspektionen sind dazu das kostengünstige und effiziente Mittel der Wahl.

Fortsetzung:

Teil 2 Statische Softwaretests: Fehler vermeiden mit Reviews und Inspektionen

Teil 3 „ 5 Prinzipen des Dynamischen Software-Tests“ erscheint am 18. Juni

(ID:241962)