Herausforderung Embedded Devices Testabdeckung bei kleinen Targets

Die Instrumentierung des Codes erhöht den Ressourcen-Bedarf spürbar.
Die Instrumentierung des Codes erhöht den Ressourcen-Bedarf spürbar.

Die Überwachung des Testfortschritts, die von vielen Sicherheitsnormen gefordert wird, ist für Embedded Systeme nicht ganz trivial. Denn oft sind die Ressourcen limitiert und können durch die Code Coverage an ihre Grenzen stoßen - Kreativität ist daher gefordert.

Die Anforderungen an Embedded-Devices steigen. Vor allem unter dem Schlagwort „IoT“ erobern sich Embedded-Systeme eine wichtige, wenn nicht sogar kritische Position in den Geschäftsprozessen der Unternehmen. Das Marktforschungsunternehmen IDC erwartet laut einer Studie vom Juni 2018, dass der Markt für IoT-Technologien bis zum Jahr 2020 bei einer jährlichen Wachstumsrate von über 13 Prozent weltweit auf ein Volumen von 1,2 Billionen Dollar steigen wird. »Embedded-Geräte werden also für alle Branchen kritisch für den Geschäftsbetrieb, die Frage nach der Sicherheit wird drängend«, betont Klaus Lambertz, Geschäftsführer von Verifysoft Technology. »Und in anderen Bereichen ist die Sicherheit von Embedded-Devices heute schon ein zentraler Aspekt bei der Entwicklung.«

In Medizintechnik, Luftfahrt, Straßen- und Schienenverkehr regeln strenge Normen, wie Embedded-Geräte getestet und zertifiziert werden müssen, um überhaupt zum Einsatz zu kommen. Außerhalb dieser traditionell auf Sicherheit fokussierten Branchen besteht häufig Nachholbedarf. Laut einer Umfrage von Gartner vom Frühjahr 2018 wurden fast 20 Prozent der Unternehmen in den vergangenen drei Jahren bereits Opfer eines IoT-basierten Angriffs. Einer der Gründe dafür ist laut Gartner, dass sich die Standards für IoT-Security erst langsam entwickeln. Es mangele noch an Security by Design.

Für sichere Embedded-Geräte ist das Testing ein wichtiger Baustein. Nicht ohne Grund stellen Normen für die sicherheitskritische Softwareentwicklung genaue Anforderungen an die Testmethoden und die Testabdeckung. In der Regel setzen einschlägige Standards wie DO-178C in der Luftfahrt oder ISO 26262 im Automotive-Bereich Anweisungs- und Zweigüberdeckungstests voraus. Auch modifizierte Bedienungs- und Entscheidungsüberdeckungstests (MC/DC, Modified Condition/Decision-Coverage) sind häufig üblich. Grundsätzlich gilt: Je höher die Sicherheitsanforderungen an eine Software, desto höher muss die geforderte Testabdeckung sein. Nicht alle Code-Coverage-Stufen sind in jedem Szenario sinnvoll, zudem bringen sie unterschiedliche Erkenntnisse:

  • Die Function-Coverage (Aufrufüberdeckung) ignoriert die inneren Abläufe der Software komplett, ihr Nutzen ist also relativ gering.
  • Bei der Statement-Coverage (Anweisungsüberdeckung) wird ermittelt, welche Anweisungen durch die Tests ausgeführt wurden. Hier lassen sich unter anderem toter Code erkennen und Anweisungen, für die noch keine Tests vorliegen.
  • Die Branch-Coverage (Zweigüberdeckung) ermittelt, ob alle Programmzweige durchlaufen wurden. Damit ist Branch-Coverage ausführlicher als die Statement-Coverage und eine mit vertretbarem Aufwand realisierbare Mindestanforderung für das Testing.
  • MC/DC (Modified Condition/Decision-Coverage) ist die höchste in den Normen geforderte Testabdeckungsstufe. Da die Überprüfung aller Bedingungskombinationen einen enormen Aufwand erfordern würde, versucht MC/DC, diesen Testaufwand zu minimieren. Hierbei werden alle atomaren Bedingungen einer zusammengesetzten Bedingung herangezogen. Für jede der atomaren Bedingungen wird ein Testfallpaar getestet, welches zur Veränderung des Gesamtergebnisses der zusammengesetzten Bedingung führt, wobei sich jedoch nur der Wahrheitswert der betrachteten atomaren Bedingung ändert. Hierbei muss der Wahrheitswert der anderen atomaren Bedingungen konstant bleiben.