Autoren: Ralf Gerlich, Dr. Rainer Gerlich, BSSE System and Software Engineering (BSSE), Christian R. Prause, Deutsches Zentrum f\u00fcr Luft- und Raumfahrt e. V. (DLR)<\/p>\n
Mit Softwareverifikationswerkzeugen sollen Fehler in Software gefunden werden. Doch gibt es nur sp\u00e4rliche Information \u00fcber das, was die Werkzeuge wirklich leisten. Meistens liegt nur die Beschreibung des Herstellers vor, an der sich ein Anwender (grob) orientieren kann. So werden Werkzeuge eher nach Bedienerfreundlichkeit oder Verbreitung in der Software-Community ausgew\u00e4hlt als nach ihren tats\u00e4chlichen F\u00e4higkeiten, Fehler zu finden \u2013 die von den Herstellerangaben abweichen k\u00f6nnen.<\/strong><\/p>\n Aber ohne detaillierte Information \u00fcber die F\u00e4higkeiten eines Werkzeuges ist es objektiv gesehen eigentlich nur ein gutes Gef\u00fchl, mehr f\u00fcr die Qualit\u00e4tssicherung getan zu haben, mindestens etwas mehr als vorher. Doch k\u00f6nnte man vielleicht noch mehr tun? Um diese Frage zu kl\u00e4ren, hat das Raumfahrtmanagement des Deutschen Zentrums f\u00fcr Luft- und Raumfahrt (DLR) eine Untersuchung beauftragt an sechs Werkzeugen, angewendet auf repr\u00e4sentative Middleware (Embedded Software) aus der Raumfahrt. Diese Aktivit\u00e4t wird aktuell an weiteren Werkzeugen und weiterer Software fortgef\u00fchrt. Ergebnisse der abgeschlossenen Untersuchung werden in diesem Beitrag vorgestellt.<\/p>\n Die sechs Werkzeuge repr\u00e4sentieren einen Querschnitt bzgl. der statischen und dynamischen Verifikationsverfahren. Wesentlich f\u00fcr die Auswahl war, dass au\u00dfer Werkzeugkonfiguration keine manuellen Eingriffe w\u00e4hrend der Analyse, insbesondere beim dynamischen Verfahren, notwendig sind. Die Werkzeuge verwenden folgende Methoden:<\/p>\n Das Testwerkzeug wendet massive Stimulation auf jede Funktion der Middleware an, beobachtet auftretende Anomalien wie Exceptions oder Index-Out-Of-range, und wertet sie aus. Au\u00dferdem wurde noch ein Compiler (gcc mit\u00a0\u2013Wall<\/span>\u00a0unter mingw) ber\u00fccksichtigt, um einen Anhaltspunkt zu bekommen, in wie weit die F\u00e4higkeiten heutiger Compiler vergleichbar sind mit denen von StaticAnalyzern.<\/p>\n Der Vergleich der Ergebnisse der verschiedenen Werkzeuge war eine gro\u00dfe Herausforderung und konnte nicht wie beabsichtigt automatisch durchgef\u00fchrt werden: teilweise fehlen Zeilennummern f\u00fcr die Zuordnung, Meldungen zum selben Fehler k\u00f6nnen f\u00fcr verschiedene Zeilen gemeldet werden, auch doppelt. Im Folgeprojekt wird nun versucht, den Automatisierungsgrad aufgrund der fr\u00fcheren Erfahrungen zu erh\u00f6hen.<\/p>\n Die folgenden Ratschl\u00e4ge \u2013 auf Basis h\u00e4ufiger Fehlannahmen \u2013 sollen helfen, Fehler bei der Auswahl und dem Einsatz von Verifikationswerkzeugen zu vermeiden:<\/p>\n Die Werkzeuge unterscheiden sich nicht.<\/em><\/p>\n Falsch. Die Werkzeuge implementieren immer eine bestimmte Methode der Fehlererkennung und wenden einen bestimmten Regelsatz an. Daher k\u00f6nnen sich die Ergebnisse hinsichtlich erkannter Fehler signifikant unterscheiden.<\/p>\n Ein Werkzeug findet alle Fehler.<\/em><\/p>\n Falsch. Ein Werkzeug kann nur die Fehler, genauer die Fehlertypen, finden, die sie zugrundeliegende Methode und die Implementierung unterst\u00fctzen. Die Implementierung kann die Bandbreite der Methode noch weiter einschr\u00e4nken.<\/p>\n Einfach das Werkzeug anwenden, das reicht.<\/em><\/p>\n Falsch. F\u00fcr die Anwendung sollte eine Strategie entwickelt werden. Welche Fehler kann ein Werkzeug erkennen, welche sollen erkannt werden, wie hoch darf das Restrisiko sein, welche Werkzeuge sollte man kombinieren?<\/p>\n Eine solche Strategie setzt die Kenntnis der F\u00e4higkeiten voraus.<\/p>\n Alle Werkzeuge haben das Ziel, alle Fehler zu finden.<\/em><\/p>\n Falsch. Werkzeuge k\u00f6nnen bzw. m\u00fcssen wegen begrenzter Ressourcen (Speicher, Zeit, Genauigkeiten) Kompromisse schlie\u00dfen. Manche minimieren die (Warte)Zeit zu Lasten der Genauigkeit und Vollst\u00e4ndigkeit.<\/p>\n Diese schnelle, „oberfl\u00e4chlichere“ Fehlererkennung kann durchaus sinnvoll sein, um viele einfache Fehler zu beseitigen, um die Laufzeiten genauerer\/ vollst\u00e4ndigerer Werkzeuge zu reduzieren, also um den meisten groben M\u00fcll wegzur\u00e4umen, damit anschlie\u00dfend der feinere M\u00fcll besser aufgenommen werden kann, d.h. eine mehrstufige Strategie zur Optimierung.<\/p>\n Die Werkzeuge erzeugen viele unzutreffende Meldungen.<\/em><\/p>\n Falsch. Die aktuelle Untersuchung zeigt, dass nur ein kleiner Anteil der Meldungen unzutreffend ist, im Durchschnitt aller Werkzeuge ca. 25%.<\/p>\n Der \u00fcblicherweise kommunizierte oder angenommene Wert stellt ein Vielfaches dieses beobachteten Wertes dar.<\/p>\n Das Werkzeug wird nur zur Abnahme am Projektende eingesetzt.<\/em><\/p>\n Falsch. Diese Strategie f\u00fchrt erfahrungsgem\u00e4\u00df zu einer hohen Anzahl von Meldungen, wobei ein hoher Anteil davon unzutreffend sein kann – im Sinne von „der Fehler kann nicht auftreten“ – oder nur f\u00fcr wenige Randf\u00e4lle zutrifft – im Sinne von „es ist unwahrscheinlich, dass der Fehler auftritt.“<\/p>\n Jeder gemeldete Fehler kann auch beseitigt werden.<\/em><\/p>\n Falsch. Bei vielen Meldungen, d.h. einer Mischung aus kritischen, weniger kritischen und unkritischen Meldungen, k\u00f6nnen kritische Meldungen \u00fcbersehen werden. Ziel sollte daher sein, durch Vorsorgema\u00dfnahmen wie Anwendung von „Best Practices“ und fr\u00fchzeitigem Werkzeugeinsatz (s.o.) die Anzahl unzutreffender Meldungen zu reduzieren.<\/p>\n Fehler, die von der Implementierung eines Werkzeuges unterst\u00fctzt werden, werden immer gemeldet.<\/em><\/p>\n Falsch. Bestimmte Fehler k\u00f6nnen die Meldungen f\u00fcr anderer Fehler unterdr\u00fccken. Einen vollst\u00e4ndigen \u00dcberblick erh\u00e4lt man erst dann, wenn keine (kritischen) Meldungen mehr erscheinen.<\/p>\n Unzutreffende Meldungen kann man ignorieren.<\/em><\/p>\n Falsch. Ob eine Meldung zutrifft, also einen Fehler anzeigt, der beseitigt werden muss oder nicht, kann erst nach (eingehender) Analyse festgestellt werden. Das erfordert (wahrscheinlich viel) Aufwand.<\/p>\n Ziel sollte also sein, solche Meldungen zu vermeiden durch geeignete Ma\u00dfnahmen wie durch Anwendung von „Best Practices“ und dem fr\u00fchzeitigen Werkzeugeinsatz, damit die Ursachen f\u00fcr unzutreffende Meldungen baldm\u00f6glichst erkannt werden k\u00f6nnen.<\/p>\n Meldungen sind immer verst\u00e4ndlich und nachvollziehbar.<\/em><\/p>\n Falsch. Die Aussage der Meldung ist nicht immer leicht nachvollziehbar. Bei einigen Werkzeugen muss man die zugrundeliegende Methode kennen, um die Meldung verstehen und die Stelle des Fehlers finden zu k\u00f6nnen.<\/p>\n Die Meldungen sind eindeutig hinsichtlich der Identifikation eines tats\u00e4chlichen Fehlers.<\/em><\/p>\n Falsch. Die Meldungen m\u00fcssen meistens interpretiert werden. Ob die Meldungen zutreffen, h\u00e4ngt auch davon ab, welche Sicht das Werkzeug auf die Softwarehat. Je nachdem, ob Kontext ber\u00fccksichtigt wird, also einschr\u00e4nkende Bedingungen bspw. in einem integrierten System, oder nicht, kann die Meldung ein True oder False Positive sein (zutreffend oder nicht, TP oder FP). Bei manchen Werkzeugen kann festgelegt werden, ob Kontext ber\u00fccksichtigt wird oder nicht. Wenn ja, dann ist die Meldung eindeutig bzgl. der Festlegung zum Kontext.<\/p>\n F\u00fcr die Auswertung wurden 20 Fehlertypen identifiziert, auf die alle Meldungen aller Werkzeuge abgebildet werden konnten, und in drei Kategorien unterteilt: kritisch, potenziell kritisch und unkritisch. Als Kennzahlen wurden Sensitivity und Precision bestimmt, \u00fcber alle Fehlertypen, f\u00fcr die 3 Kategorien und pro Fehlertyp. Beide Werte liegen zwischen 0 und 1. Je n\u00e4her bei 1, desto besser.<\/p>\n Die Sensitivity charakterisiert die F\u00e4higkeit, Fehler zu finden und ist der Quotient aus der Anzahl gefundener Fehler zu der Gesamtanzahl der Fehler. Da prinzipiell die Anzahl von Fehlern in der gepr\u00fcften Software nicht bestimmt werden kann, wurde sie durch die Vereinigungsmenge aller mit allen Werkzeugen gefundenen Fehler approximiert, erg\u00e4nzt durch weitere Fehler, die bei der Analyse der Werkzeugmeldungen manuell gefunden wurden.<\/p>\n Die Precision ist ein Ma\u00df f\u00fcr die Treffsicherheit eines Werkzeuges und ist der Quotient aus der Anzahl tats\u00e4chlicher Fehler unter allen Meldungen des Werkzeuges (TP \/ (TP+FP)).<\/p>\n Die von den Werkzeugen benutzten Verfahren werden in Tab. 1 kurz charakterisiert.<\/p>\n\u00dcberblick<\/h2>\n
\n
Ratschl\u00e4ge f\u00fcr die Werkzeugauswahl und -anwendung<\/h2>\n
Kennzahlen<\/h2>\n
Charakterisierung der Werkzeuge<\/h2>\n