66 elektronik industrie 10/2015

Entwicklungssysteme

www.elektronik-industrie.de

FehlerbergVersteckte Mängel in vorhandener Embedded-Software aufspüren

Wer Software entwickelt ohne auf die Qualität zu achten, gefährdet nicht nur das aktuelle Produkt. Je mehr fehler-haften Code er wiederverwendet, desto mehr Mängel häufen sich an. Im Laufe der Zeit wird der Aufwand im-mer höher, um dieser Falle zu entfliehen. Also lautet die Devise: Fehler auch in älteren Code-Teilen aufspüren und beheben. Autor: John Paliotta

Die Softwareindustrie steckt in ihrer ganz eigenen Schuldenkri-se: sie hat über Jahre Mengen an

Software entwickelt ohne korrekte Qua-litätskontrollprozesse einzusetzen und entsprechend viele versteckte Mängel angehäuft. Gartner Research erwartet, dass in diesem Jahr die globalen techni-schen Schulden in IT und Embedded-Software auf eine Billion US-Dollar anwachsen.

Technische Schulden sind dabei eine Metapher für versteckte Mängel, die in der Architektur, im Design oder der Entwick-lung stecken. Den Begriff der technischen Schulden hat Ward Cunningham 1992 geprägt. Er bezieht sich auf die akkumu-lierten Verbindlichkeiten, die entstehen, wenn Unternehmen Design und Tests abkürzen, um kurzfristige Ziele zu errei-chen. Wie die finanziellen Schulden sind auch die technischen Schulden im Wesent-

lichen ein Darlehen mit anfallenden Zin-sen. Wer das Darlehen nicht rechtzeitig zurückzahlt, kann seine Software letzt-endlich nicht mehr am Laufen halten. Je höher die technischen Schulden sind, des-to geringer ist die Möglichkeit für Inno-vationen und dafür, auf dem Markt wett-bewerbsfähig zu bleiben. Ein Großteil der technischen Schulden entsteht durch den Geschäftsdruck, immer neue Produkte auf den Markt zu bringen.

Die vier häufigsten Gründe für techni-sche Schulden sind: schlechte Architek-turauswahl, übermäßig komplexer Code,

So wie sich monetäre Schulden zu einem erdrückenden Berg auftürmen können, sammeln sich auch kleinere und größere Mängel in Embedded-Software an. Statt den vorhandenen Code voll-ständig zu testen und möglichst viele Fehler zu beseitigen, wird er möglichst früh freigegeben und in Produkte eingesetzt. Das rächt sich im Laufe der Zeit. Der Testspezialist Vector Software zeigt hier einen systematischen Weg auf, um diese technischen Schulden sukzessive abzutragen.

Eck-DatEn

Fehlen von Codedokumentation sowie unzureichendes Testen. Mit dem Anstieg der technischen Schulden verbringen die Entwickler immer mehr ihrer Zeit mit der Fehlerbehebung und mühen sich mit fra-gilem Code ab, statt neue Funktionen zu erstellen.

Die Grenzen der RegulierungDa unser tägliches Leben abhängig von eingebetteter Software geworden ist, ist der Bedarf an solidem und unbelastetem Code groß, insbesondere wenn die Sicher-heit der Nutzer oder der Umgebung

elektronik industrie 10/2015 67

Entwicklungssysteme

www.elektronik-industrie.de

Zehntel davon ausmachen: in keinem Fall ist schnelle Abhilfe zu erwarten. Statt nach einer einfachen Lösung zu suchen, müssen Softwareentwickler und Hersteller neue Entwicklungsprozesse aufsetzen, die sicherstellen, dass sie keine neuen Schul-den hinzufügen und vorhandene Schulden sukzessive abtragen. Zwar gibt es ver-schiedene Wege um dies zu realisieren, doch die folgenden Schritte sind immer nötig:

•Das Problem verstehen: Kennzahlen erfassen, etwa Codekomplexität, Kom-mentardichte und API-Komplexität.

•Ergebnisse teilen: die Daten allen Sta-keholdern zur Verfügung stellen.

•Verbesserungen planen: zum Beispiel den Aufwand auf Sonderfälle fokussie-ren, etwa Funktionen höchster Komple-xität aufteilen.

Um mit der Entwicklung der benötigten Menge an Software fortzufahren, müssen die Unternehmen skalierbare Entwick-lungsprozesse erstellen, die zu robusten und wartbaren Codebasen führen, die relativ frei von technischen Schulden sind. Solange moderne Herstellungsmethoden, wie das Minimum Viable Product (MVP), akzeptieren, dass die erste Version niemals fehlerfrei ist und Marktdruck bedeutet, dass es immer eine gewisse Menge an technischen Schulden gibt, sollte das Ziel jedes Entwicklungsteams sein, die tech-nischen Schulden auf einem zu bewälti-genden Level zu halten.

Währung für technische SchuldenUm den aktuellen Stand der technischen Schulden zu erkennen, können Entwick-ler Kennzahlen sammeln und Testergeb-nisse aufzeichnen. Um diese Daten zu ver-stehen, müssen die Unternehmen eine

Bild 1: Nur gemeinsam mit Funktionstests und Unit-Tests ist es möglich, jede einzelne Programmzeile mit mindestens einem Testfall auszuführen.

Reihe von umfassenden und gemeinsamen Kennzahlen und Grenzwerten einführen, die verdeutlichen, was „schuldenfrei“ hier bedeutet. Ebenso müssen sie einen auto-matisierten Weg zur Aufzeichnung und zum Report dieser Kennzahlen einrichten. So schaffen sie eine Ist-Basis. Da Soft-warekomponenten häufig an verschiede-nen Orten und von verschiedenen Teams entwickelt werden, ist es sehr wahrschein-lich, dass die Basiskennzahlen innerhalb einer Codebasis sehr stark variieren.

Obwohl diese statische Analyse einige der Schuldenkennzahlen liefern kann, misst sie nicht die Testvollständigkeit und hilft somit auch nicht die Korrektheit zu bestimmen. Das Messen der Testvollstän-digkeit ist eine Schlüsselkomponente um den gesamten Umfang der technischen Schulden abzubilden. Die Vollständigkeit kann man am einfachsten mit der Code-abdeckungsanalyse messen (Code-Co-verage-Analyse, Bild 1). Sie zeichnet auf, wie viel des vorhandenen Codes ein Test-fall tatsächlich durchlaufen hat. Durch Verzweigungen, Schleifen und Subrou-tinen ist das meist nur ein geringer Wert pro Testfall. Erst die Summe vieler Tests kann komplexe Programme umfassend überprüfen.

Testvollständigkeit erhöhenSobald sie die Codekomplexität und Doku-mentationsmängel reduziert haben, sollten sich Entwickler um die häufigste Ursache für technische Schulden kümmern: unzu-reichendes Testen. Ähnlich wie bei den Kennzahlen und Grenzwerten, ist der ers-te Schritt zu entscheiden, was adäquates Testen für das jeweilige Unternehmen bedeutet. Sinnvoll erscheint, auf Korrekt-heit zu bestehen, also dass die Anwendung

gefährdet ist. Sicherheitskritische Bran-chen wie Luftfahrt, Eisenbahn und Auto-mobil haben Entwicklungsstandards und Vorschriften entwickelt. Die sollen sicher-stellen, dass alle Anwendungen vor dem Einsatz vollständig getestet wurden. Ziel dieser Standards sind robuste, fehlertole-rante Anwendungen.

Während es keinen Zweifel gibt, dass das Einhalten von Vorschriften, wie den Safety Integrity Levels (SILs) oder Deve-lopment Assurance Levels (DALs), hoch qualitative Software als Ergebnis hat und somit die technischen Schulden durch „unzureichendes Testen“ vermeidet, zielen sie kaum auf die anderen drei Hauptgrün-de für technische Schulden ab.

Technische Schulden abtragenWenn die weltweiten technischen Schul-den ein Billionen-Dollar-Problem sind, wie Gartner prophezeit, oder doch nur ein

Bild:

© al

phas

pirit -

fotoli

a.com

68 elektronik industrie 10/2015

Entwicklungssysteme

www.elektronik-industrie.de

autorJohn PaliottaChief Technology Officer von Vector Software in East Green-wich, Rhode Island, USA.

infoDIREKt 709ei1015Bilde

r: Vec

tor S

oftwa

re

Bild 3: Wenn Entwickler nur eine Stelle im Quellcode än-dern (grün), hat das auf die meisten Test-fälle keinerlei Auswirkung. Change-based Testing führt nur die betrof-fenen Tests aus (orange).

wie gewünscht funktioniert, sowie auf Robustheit, also dass der Code auch Bedingungen außerhalb der Norm ver-nünftig handhabt.

Kürzlich gab es viel Aufregung über das Jahr-2038-Problem. Wie beim Y2K, wer-den sich im Jahr 2038 alle Betriebssysteme überschlagen, die einen 32-Bit-Integer-Wert nutzen, um die Anzahl der Sekunden seit dem 1. Januar 1970 nachzuvollziehen. Dieses Problem des 32-Bit-Integer-Über-laufs ist das gleiche Problem, das in den Boeing-787-Softwaresystemen im Som-mer 2015 entdeckt wurde. Wenn das Sys-tem länger als 248 Tage am Stück läuft, wechselt es automatisch in den ausfallsi-cheren Modus und schaltet die Triebwer-ke ab: die Anzahl an Millisekunden in 248 Tagen lässt sich nicht mehr als 32-Bit-Inte-ger darstellen. Solche Situationen lassen sich vermeiden, wenn man Robustheits-tests rigoroser durchführt. Sie müssen die Leistung bei Minimum, Mittelwert und Maximum sowie die Funktionsdatengren-zen der Anwendung überprüfen (Bild 2).

On-Target-Testen ist ein essentielles Element für eingebettete Anwendungen, um sicherzustellen, dass die Software ver-

nünftig funktioniert wenn sie auf den Markt kommt. Dabei sollte die Testumge-bung so nah wie möglich an der Produk-tionsumgebung sein, inklusive der glei-chen Version aller Compiler, Firmware und Hardware. Eine gemeinsame Testplatt-form macht es dennoch einfach, Korrekt-heits- und Robustheitstests zu implemen-tieren. Doch bei den Millionen von unzu-reichend getesteten Anwendungen kann keine Firma die nötigen Tests nachträglich per Hand schreiben.

Testfälle automatisch erzeugenAutomatisierte Testfallgenerierung kann die Testvollständigkeit von Legacy-Anwendungen dennoch erhöhen. Tests lassen sich vom Interface und auch von der Logik der Anwendung aus generieren. Automatisierte Interface-Tests erzeugen eine Kombination von Werten, die für die Grenzarten der Parameter spezifisch sind (zum Beispiel Min- und Max-Integer). Automatisierte Logik-Tests wiederum sol-len jeden Entscheidungspunkt in der Anwendung dazu zu bringen, sowohl True- als auch False-Ergebnisse anzuneh-men. Obwohl automatisierte Tests die Kor-

rektheit nicht beweisen, helfen sie auf ein-fache Weise, obsoleten, ungenutzten oder doppelten Code zu finden, der sich über Jahre durch Verbesserung und Erweite-rung der Software angesammelt hat.

Der Schlüssel zum Reduzieren techni-scher Schulden in Legacy-Anwendungen ist, die Komponenten im Laufe der Zeit zu refaktorieren. Jedoch wird dieser Aufwand nur fruchten, wenn es einen einfachen Weg gibt, die Testumgebung auszuführen, die das korrekte Verhalten der Komponen-te beweist. Automatisierte Testgenerierung kann diese Basis-Testreihe schnell bereit-stellen, um existierendes Verhalten zu erfassen. Damit stellt sie sicher, dass man beim Refactoring keine Rückschritte macht und mehr Fehler einfügt als behebt. Dum-merweise dauert ein Testlauf in komplexen Projekten viele Stunden oder gar Tage: Hier nach jeder Änderung einen komplet-ten Testlauf zu starten ist nicht zielfüh-rend. Automatisierte Workflows können aber herausfinden, welche konkreten Test-fälle von einer Änderung tatsächlich betroffen sind, und nur diese ausführen (Bild 3). Damit sinkt der Testaufwand enorm und Entwickler können auch bei trivialen Änderungen sofort sicherstellen, dass sie damit keinen Test zum Scheitern bringen.

Den Überblick behaltenAbschließend brauchen Entwickler noch ein Berichtswerkzeug, das den allgemei-nen Zustand der Release-Bereitschaft ihrer Codebasis präsentiert, jegliche Testlücken identifiziert und langfristige Qualitäts-trends aufzeigt. Damit können Manager die Ressourcen abschätzen, die sie einset-zen müssen um die technischen Schulden abzutragen. Diese Schulden einfach zu ignorieren wäre gefährlich. Schuldenab-bau wird nur mit einem realistischen Plan möglich, der neue Schulden verhindert und die Schulden im Laufe der Zeit Schritt für Schritt reduziert. (lei)� n

Bild 2: MC/DC-Tests (Modified Condition / Decision Coverage) sollen nicht nur jede Codezeile erfassen, sondern auch jede Bedingung triggern und jede mögliche Entscheidung abdecken.