Ein bei vielen Softwareherstellern drängendes Thema ist die Erweiterung ihres Angebots um Smartphone-Apps. Auch für die Hersteller von Embedded-Systemen wird das ein immer wichtigeres Thema. Vor allem in Bereichen, in denen sich Geräte an Endkunden richten, sind Apps für eine bessere User Experience eine sinnvolle Ergänzung. Über sie kann sich ein Unternehmen differenzieren.
Ein typisches Szenario dafür ist etwa folgendes: Der Anbieter eines Blutzuckermessgeräts möchte seinen Kunden über eine App zusätzliche Services wie den Überblick über historische Daten ermöglichen. Damit verarbeitet diese App aber sensible Daten. Entsprechend dürfen bei der Sicherheit keine Kompromisse gemacht werden. Und das bedeutet letztlich auch, dass die App ebenso getestet werden sollte, wie die Software auf den Embedded-Geräten. Damit rückt auch die Code Coverage ins Blickfeld, die Messung und Dokumentation der Testabdeckung.
Von den Entwicklern erfordert das ein Umdenken. Denn Smartphone-Apps unterscheiden sich in zwei grundlegenden Punkten von Embedded-Anwendungen. Während in der Embedded-Welt in der Regel Mikrocontroller mit genau spezifizierten Merkmalen zum Einsatz kommen, ist ein aktuelles Smartphone eher mit einem PC vergleichbar: Hohe Performance der Hardware, File System und große Varianzen bei den unterschiedlichen Systemen. Zudem wird statt den im Embedded-Bereich üblichen Sprachen C und C++ bei Android-Apps überwiegend Java eingesetzt.
Unterschiedliche Fehlerquellen
Vor allem in Hinblick auf die Sicherheit und das Testing unterscheidet sich Java jedoch signifikant von C/C++. Das hat nicht zuletzt historische Gründe: Als C in den 70er-Jahren des vergangenen Jahrhunderts erstmals definiert wurde, lag der Fokus auf Geschwindigkeit. Das Internet gab es nicht, Cybersicherheit war kein Thema. Mit C++ wurden die beiden größten, daraus resultierenden Probleme zwar entschärft, aber nicht aus der Welt geschaffen: Type-Sicherheit und ungeprüfte Pointer-Arithmetik. Besonders die Pointer-Arithmetik ist für viele Sicherheitsprobleme verantwortlich, die Wurzel der weit verbreiteten Buffer Overruns.
Die Schwäche von Java
Java ist hier wesentlich moderner, Puffer-Zugriffe werden explizit überprüft. Eine illegale Operation erzeugt eine Exception, die in der Regel vorhersehbare Auswirkungen hat. Die Hauptschwäche von Java liegt vielmehr auf der API-Seite. Falscher Einsatz mancher Standard-APIs – zum Beispiel, wenn bei einer serialisierbaren Klasse keine Serial-VersionUID definiert wird – kann zu Problemen führen. Diese sind jedoch in den meisten Fällen weniger schwerwiegend als bei C/C++, können aber durchaus Sicherheitslücken oder funktionale Fehler der Anwendung nach sich ziehen.
Für das Testing bedeutet der grundlegende Unterschied zwischen Java und C/C++, dass zum Teil andere Testfälle benötigt werden. Und im Gegensatz zur Embedded-Entwicklung wird der Code nicht in einem abgeschlossenen System mit bekanntem Mikrocontroller und klar definierter Plattform getestet, sondern im Falle von Android auf einem grundsätzlich offenen System mit zahlreichen Variablen. Zudem kommt es beim Testing und der Code Coverage darauf an, ob auf der Anwendungs- oder auf der Betriebssystem-Schicht getestet wird.
Instrumentierung des Codes
Bei der Implementierung einer an spezielle Bedürfnisse angepassten Android-Version – etwa bei einem Smartphone-Hersteller oder bei der Entwicklung eines Entertainment-Systems in der Automotive-Branche – ist die Instrumentierung des Codes eine gewisse Herausforderung: Bei der Instrumentierung ergänzt ein Code Coverage Analyser wie Testwell CTC++ den Code vor der Übergabe an den Compiler mit Zählern für die gewünschten Testebenen.
Das Betriebssystem muss also nach der Instrumentierung neu gebaut werden. Das dauert meist sehr lange, jeder Fehler erfordert zudem einen neuen Build. Erschwert wird dieses dadurch, dass der Anteil an fremdem Code dabei sehr hoch ist. Dieses stellt grundsätzlich eine potenzielle Fehlerquelle im Testing dar.
Testing automatisieren
Die Code Coverage auf der Anwendungsschicht hingegen ist deutlich einfacher. Hier liegt normalerweise ein performantes System mit üppigen Hardware-Ressourcen vor. Der zu testende und zu instrumentierende Code ist bekannt. Ein Code Coverage Analyser kann einfach in der Tool-Chain vor den Compiler gesetzt werden: Bei Testwell CTC++ for Java und Android wird etwa der Quellcode zunächst an das Tool Javactc übergeben und instrumentiert. Das Tool ruft dann den gewünschten Compiler auf, der eine neue Executable für das Testing erzeugt.
In beiden Szenarien ist es notwendig, Instrumentierung und Testing soweit als möglich zu automatisieren. Denn es gibt einen weiteren wichtigen Unterschied zwischen Android-Anwendungen und Embedded-Systemen: Der Preis. Bei einer Steuerung für die Luftfahrt oder der Bahn ist der Preis zunächst zweitrangig, Sicherheit und Funktion haben oberste Priorität. Der Markt für Apps ist hingegen sehr preissensitiv.
Allerdings ist die Integration eines Code Coverage Analysers in das Build-System nicht trivial – egal, ob Ant, Gradle oder Ninja zum Einsatz kommen. Hierfür braucht es neben einem flexiblen Tool einen erfahrenen Partner, der die Integration in die Tool-Chain leisten kann. Zudem ist es sinnvoll für Unternehmen, die ihre Embedded-Lösungen um Apps erweitern wollen, ein einheitliches System zur Code Coverage für beide Entwicklungsbereiche zu nutzen.
Der Markt hält dafür geeignete Angebote bereit, die mit Java und auch mit C/C++ arbeiten. Das ist sehr wichtig, wenn verschiedene Teile einer Anwendung in unterschiedlichen Sprachen implementiert werden. Dadurch steht in Entwicklung und Testing immer das vertraute Tool zu Verfügung, das die gleichen Reports liefert und so den Aufwand erheblich reduziert.
Android ist zukünftig gefragt
Embedded-Entwickler werden sich in Zukunft zunehmend mit Android auseinandersetzen müssen. Und damit ebenfalls mit der Sicherheit und Zuverlässigkeit der Anwendungen. Auch wenn aktuell sicherheitskritische Apps noch eine Nische sind: Der Trend geht dahin, dass Anwender ihrem Smartphone auch besonders schützenswerte Daten anvertrauen oder auf die korrekte Funktion einer App angewiesen sind.
Ein Vorreiter dabei wird sicher die Medizintechnik sein. Nur mit integrierten und automatisierten Prozessen bei der Qualitätssicherung können Sicherheit und Funktionalität der Apps zu einem günstigen Preis und mit einer kurzen Time-to-Market gewährleistet werden.
