Statische Codeanalyse

Bugs und Defekte in Multitasking-Software eliminieren

22.01.2009 | Autor / Redakteur: David Kalinsky* / Martina Hafner

*Dr, David Kalinsky ist Leiter für Kundentrainings bei D. Kalinsky Associates Technical Training, USA und ein beliebter Dozent in USA, Europa und Israel. Kontakt: david@kalinskyassociates.com.
*Dr, David Kalinsky ist Leiter für Kundentrainings bei D. Kalinsky Associates Technical Training, USA und ein beliebter Dozent in USA, Europa und Israel. Kontakt: david@kalinskyassociates.com.

Vor- und Nachteile dynamsicher Analysetools

Tools zur Überprüfung der Codequalität lassen sich in dynamische und statische Analysetools unterteilen.

Dynamische Analysetools werden schon seit vielen Jahren eingesetzt. Sie überprüfen ausführbaren Code zur Laufzeit und melden Codefehler, die bei der Ausführung des Programms auftreten. Diese Tools eignen sich hervorragend zum Erkennen von Defekten, wie dynamischen Speicherzugriffsfehlern und Ressourcen-Leaks.

Dynamische Analysetools zeichnen sich durch eine niedrige Falsch-Positiv-Rate aus. Wenn diese Tools also einen Fehler melden, ist es ein tatsächlicher Fehler. Diese Tools irren sich selten, denn sie überprüfen den Code und sehen sämtliche Informationen über die Zustände der Software und deren Eingangswerte, während das Programm ausgeführt wird. Die Analyseergebnisse sind entsprechend relevant – es werden tatsächliche Fehler erkannt, die während der Ausführung der realen Software aufgetreten sind, und nicht nur Fehler, die auftreten könnten, wenn 500 Anwender 500 Jahre lang auf 500 Tastaturen herumtippen.

Doch dynamische Analysetools haben auch Schwachstellen. Fehler werden erst in einer späten Phase des Softwareentwicklungsprozesses gefunden, da diese Tools eine ausführbare Version der Programme benötigen. Subtilere Fehler, d.h. solche, die in integrierten Softwareteilen auftreten, werden erst nach der vollständigen Integration der Software entdeckt. Darüber hinaus deckt die dynamische Analyse nur die Testfälle ab, die tatsächlich ausgeführt wurden. Wurden also Testfälle für eine Line Coverage von nur 95% unter den wachsamen Augen eines dynamischen Analysetools ausgeführt, dann würden diesem Tool wahrscheinlich viele andere Defekte entgehen.

In der Embedded-Softwareentwicklung ist es schwierig, sporadisch auftretende Fehler mit dynamischen Analysetools zu identifizieren. Das gilt auch für Fehler, die durch die Unterbrechung von Tasks in einer präemptiven Multitaskingumgebung verursacht werden, wenn ein Softwareentwickler einen kritischen Abschnitt nicht ausreichend geschützt hat.

Statische Analysetools als ergänzende Werkzeuge

Statische Sourcecode-Analysetools analysieren die Software-Codebasis auf Defekte, ohne die Programme auszuführen, die aus der Software entstehen. Sie können die Ausführungspfade in der Codebasis vollautomatisch abdecken. Statische Analysetools identifizieren Bugs und Defekte in einer frühen Phase des Entwicklungsprozesses, denn sie benötigen keine ausführbare Version des Codes, der untersucht werden soll. Mit statischer Analyse lassen sich im Extremfall sogar Bugs finden, noch bevor der Code erfolgreich kompiliert wurde. Manuell erzeugte Testfälle sind nicht erforderlich, da die Analysealgorithmen selbst die relevanten Pfade durch den zu testenden Code identifizieren, ebenso wie die für eine Analyse geeigneten Datenwerte. Die statische Analyse ist eine verhältnismäßig schnelle Methode. Für eine Codebasis mit mehreren Millionen Zeilen fallen nur wenige Stunden an. Die schnelle Analyse von Code eines Entwicklers direkt an dessen Arbeitsplatz dauert nur ein paar Sekunden.

In der Embedded-Softwareentwicklung können statische Analysetools sporadisch auftretende Fehler entdecken, wie z.B. solche, die durch die Unterbrechung von Tasks in einer präemptiven Multitaskingumgebung verursacht werden, wenn ein Softwareentwickler einen kritischen Abschnitt nicht ausreichend geschützt hat. Die Fehlersuchalgorithmen eines statischen Analysetools können diese Art von Bugs konsistent und wiederholbar auffinden, selbst wenn der Bug nicht konsistent oder wiederholbar zur Programmlaufzeit auftritt.

Die beiden Toolkategorien – dynamische und statische Analysetools – stehen somit also nicht in Konkurrenz zueinander, sondern sie ergänzen sich: Statische Analysetools sind in Bereichen stark, die für dynamische Analysetools problematisch sind, und umgekehrt.

Vielfalt und Komplexität von Softwarefehlern

Mit Tools zur statischen Sourcecode-Analyse lassen sich viele verschiedenartige Fehler und Defekte, die die Softwarequalität und -sicherheit beeinträchtigen, präzise identifizieren. Die nachfolgende Liste zeigt einige der Fehlerarten, die mit den erhältlichen, kommerziellen statischen Sourcecode-Analysatoren identifiziert werden können:

  • Null-Pointer-Zugriffe
  • Benutzung von freigegebenem Speicher
  • Doppelte Freigabe eines Buffers
  • Array-Indexfehler
  • Fehlanpassung von new/delete
  • Stack-Überlauf
  • Heap-Überlauf
  • Rückgabe eines Pointers auf lokale Variablen
  • Logisch inkonsistenter Code
  • Ungesicherte Verwendung von Nutzerdaten
  • Nicht initialisierte Variablen
  • Unerlaubte Verwendung von Negativwerten
  • Übergabe großer Parameter ‚by value’
  • Unterallokation dynamischer Daten
  • Memory Leaks
  • File-Handle Leaks
  • Netzwerkressourcen-Leaks
  • Nicht verwendete Werte
  • Nicht behandelte Return-Codes
  • Verwendung ungültiger Iteratoren

Fehler und Defekte werden auf einem GUI dargestellt, das ähnlich aufgebaut ist wie die Benutzeroberflächen, die Softwareentwickler von Source-Level-Debuggern kennen.

Oft sind die Fehler und Defekte, die mit statischen Analysetools identifiziert wurden, nicht auf eine einzelne Codezeile oder Codefunktion begrenzt. Viele der subtileren Defekte sind „interprozedural“. Das heißt, ein Fehlerszenario kann sich über mehrere Schritte entwickeln, wobei sich einige dieser Schritte in einer Codefunktion befinden und weitere Schritte – oder letztendlich ein Ausfall selbst - in einer anderen Codefunktion.

Manche der entdeckten Fehler sind hochkomplex. Die GUIs statischer Analysetools stellen daher jeden Fehler in einem eigenen Fenster dar. Die an der Entstehung des Defektes beteiligten Codezeilen werden gekennzeichnet und erklärt. Werden mehrere Fehler in wenigen Codezeilen derselben Einzelfunktion gefunden, erhält jeder Fehler ein eigenes Fenster. Bei einem Defekt, der mehrere Softwareprozeduren betrifft, wird jede relevante Prozedur in einem separaten GUI-Fenster dargestellt.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 285126 / Software-Implementierung)