Qualitätssicherung

Statische Analyse leistet mehr als nur die Auflistung von Defekten

08.02.13 | Autor / Redakteur: Chris Adlard* / Franz Graser

Tools zur statischen Codeanalyse helfen dabei, potenzielle Fehler aufzuspüren. Im Embedded-Umfeld müssen sie aber noch mehr leisten.
Tools zur statischen Codeanalyse helfen dabei, potenzielle Fehler aufzuspüren. Im Embedded-Umfeld müssen sie aber noch mehr leisten. (Bild: Clipdealer)

Immer mehr Programmierer identifizieren mit statischen Analyse-Tools potenzielle Schwachstellen schon in der frühen Entwicklungsphase. Die eigentliche Innovation ist aber, dass statische Analyse die Fehler nicht nur findet, sondern sie auch in einen verständlichen Kontext einordnet.

Die Qualität von Programmcode lässt sich durch viele verschiedene Test- und Verifizierungsmethoden steigern. Immer mehr Programmierer setzen auf die statische Analyse, um Schwachstellen schon in der frühen Entwicklungsphase zu identifizieren.

Verschiedene Untersuchungen des Marktforschungsinstituts VDC Research, so etwa der 2012 veröffentlichte Report „Software & System Lifecycle Management Tools Market Intelligence Service on Automated Test & Verification Tools", belegen: Die moderne statische Analyse setzt sich in den Unternehmen als Testautomatisierungs-Tool immer mehr durch. Sie gilt als das vermutlich kosteneffizienteste automatisierte und wiederholbare Verfahren, um die Qualität komplexer Software sicherzustellen.

Ein wesentlicher Grund dafür: Die Technik zur Identifizierung kritischer Defekte wie Pufferüberlaufschwachstellen (Buffer Overflow), Ressourcenleaks (Memory Leaks), Nullpointer-Dereferenzierung oder ungültige Speicherzugriffe, ist mittlerweile weit gereift. Auch große Mengen schwer aufzuspürender Fehler, die gleich mehrere Funktionen und Dateien betreffen, werden sehr verlässlich aufgefunden. Das führt zu einer sehr geringen Anzahl von False Positives. Die eigentliche Innovation ist jedoch, dass die statische Analyse Fehler nicht nur aufzeigt, sondern sie in den entsprechenden Kontext einordnet. Der Entwickler erfährt, was die Ursache für den Defekt ist, welche Auswirkungen dieser hat und wo er beseitigt werden muss.

Die Antwort auf die Frage nach dem Wo geht weit über den Dateinamen und Angabe der Codezeile hinaus. Das ist notwendig, denn durch den komplexen Entwicklungsprozess findet sich ein Defekt häufig in verschiedenen Versionen und Produkten wieder: Die verschiedenen Bestandteile des Programmcodes greifen ineinander, werden miteinander verschmolzen und für verschiedene Anwendungen wiederverwendet.

Man stelle sich ein Entwicklerteam vor, das an unterschiedlichen Programmsträngen für verschiedene Produktversionen arbeitet. Ein Bug in einem dieser Programmstränge kann sich durch Codereplikation auch in anderen Programmabschnitten wiederfinden. Ein anderes Beispiel: Ein Team entwickelt ein Framework für die Nutzung von Apps auf Smartphones. Das Framework soll auf verschiedenen Betriebssystemen wie Windows, Android oder iPhone laufen, weshalb jeweils eigene Versionen entwickelt werden. Wird bei der statischen Analyse nun ein Fehler entdeckt, ist es entscheidend, zu wissen, ob dieser nur in einer oder in mehreren Versionen zu finden ist.

Ebenfalls ein Entwickler-Albtraum: Besteht eine Software aus zusammengefügten Code-Abschnitten unterschiedlicher Herkunft, führt eine Schwachstelle schnell zu einem Dominoeffekt. Denn ist nur einer der zusammengefügten Abschnitte fehlerhaft, sind alle Software-Lösungen betroffen, die diesen enthalten.

Beispiel: Mehrere Entwicklungszweige für diverse Versionen eines Betriebssystems

Folgender Anwendungsfall veranschaulicht dies: Ein Software-Entwicklungsteam erstellt ein neues Betriebssystem für Smartphones. Da unterschiedliche Smartphone-Hersteller unterstützt werden sollen, gibt es im Source Control Management System (SCM) für jeden Anbieter einen eigenen Entwicklungszweig. Darüber hinaus verfügt jeder Hersteller über verschiedene Abteilungen für die unterschiedlichen Modelle und Produktgenerationen, für die ebenfalls eigene Versionen entwickelt werden müssen. Es wird also sehr schnell kompliziert und unübersichtlich.

Gefahr bei Forks: Aufgrund von Verzweigungen und Zusammenführungen von Software-Entwicklungssträngen können sich Defekte vervielfältigen. Die statische Analyse hilft hier, die Fehler zu identifizieren.
Gefahr bei Forks: Aufgrund von Verzweigungen und Zusammenführungen von Software-Entwicklungssträngen können sich Defekte vervielfältigen. Die statische Analyse hilft hier, die Fehler zu identifizieren. (Grafik: Coverity)

Die statische Analyse liefert eine Liste von Fehlern für jeden Entwicklungszweig. Je nachdem, wann ein Defekt entdeckt wird, kann er nur in einer Untergruppe oder auch in allen Versionen stecken. Die Schwierigkeit für den Entwickler besteht nun darin, dass er die möglichen Auswirkungen eines Fehlers nicht einschätzen kann, solange er nicht weiß, wo er sich überall versteckt.

Findet sich ein Fehler in mehr als einer Version für unterschiedliche Hersteller, sind die möglichen Folgen enorm – die Behebung dieses Fehlers sollte also höchste Priorität haben. Außerdem muss der Entwickler, der den Defekt ausmerzen will, genau wissen, in welchen Programmzweigen der zusätzliche Code über das SCM-System eingepflegt werden muss. Hierfür sind Analyseergebnisse, anhand derer sich ein Defekt exakt lokalisieren lässt, von großem Wert.

Inhalt des Artikels:

»1 »2 nächste Seite

Kommentar zu diesem Artikel abgeben

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

Spamschutz 

Bitte geben Sie das Ergebnis der Rechenaufgabe (Addition) ein:
Kommentar abschicken

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 37695320) | Fotos: Clipdealer, Grafik: Coverity

Heftarchiv
ELEKTRONIKPRAXIS 14/2014

ELEKTRONIKPRAXIS 14/2014

Wenn Optik und Haptik eines Displays entscheiden

Weitere Themen:

Verbesserte SiCLeistungs- MOSFETs
Theorie versus Prozesstoleranzen
Hardware Monitoring

zum ePaper

zum Heftarchiv

ELEKTRONIKPRAXIS 13/2014

ELEKTRONIKPRAXIS 13/2014

Perfekt aufgestellt für jede Gehäuse-Situation

Weitere Themen:

Das M2M-Protokoll OPC UA
Hohe Abtastrate und Bandbreite
Was AC-Quellen können müssen

zum ePaper

zum Heftarchiv

ELEKTRONIKPRAXIS 12/2014

ELEKTRONIKPRAXIS 12/2014

Was Chefs über Software wissen müssen

Weitere Themen:

Automatisches und interaktives Routeb
Hardware mit SCRUM entwickeln
GbE in der Automatisierung

zum ePaper

zum Heftarchiv