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:

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

Softwareengineering-Report abonieren

4 mal jährlich: Die kostenlose Pflichtlektüre für Embedded­-Software- und Systems-Entwickler, von Analyse bis Wartung und Betrieb

* Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung und AGB einverstanden.
Spamschutz:
Bitte geben Sie das Ergebnis der Rechenaufgabe (Addition) ein.
Heftarchiv
ELEKTRONIKPRAXIS 18/2014

ELEKTRONIKPRAXIS 18/2014

Chipentwicklung gemeinsam mit dem Kunden

Weitere Themen:

Spannungswandler als LED-Treiber
Ausfallsicherheit bei NAND-Speicher
Sonderteil „Elektronik hilft“

zum ePaper

zum Heftarchiv

ELEKTRONIKPRAXIS 17/2014

ELEKTRONIKPRAXIS 17/2014

Test der Ethernet-Konformität mit dem Oszilloskop

Weitere Themen:

Beschleunigung mit MEMS messen
Vom Touch zur Gestensteuerung
Sieben Vorteile durch Laserlöten

zum ePaper

zum Heftarchiv

ELEKTRONIKPRAXIS 16/2014

ELEKTRONIKPRAXIS 16/2014

Ideen-Board für Spansions FM ARM Cortex-M MCUs

Weitere Themen:

Geld verdienen mit sozialen Medien
Hardware für digitale Hörgeräte
Chips für smarte Stromversorgung

zum ePaper

zum Heftarchiv