Herzlich Willkommen beim beam-Verlag in Marburg, dem Fachverlag für anspruchsvolle Elektronik-Literatur.


Wir freuen uns, Sie auf unserem ePaper-Kiosk begrüßen zu können.

Aufrufe
vor 1 Jahr

3-2023

  • Text
  • Kuenstliche intelligenz
  • Elektromechanik
  • Antriebe
  • Stromversorgung
  • Hmi
  • Industrielle kommunikation
  • Robotik
  • Qualitaetssicherung
  • Bildverarbeitung
  • Automatisierung
  • Sensorik
  • Bedienen und visualisieren
  • Messen steuern regeln
  • Bauelemente
  • Iot
  • Embedded systeme
  • Sbc boards module
  • Software
  • Industrie pc
  • Embedded

Software/Tools/Kits Mit

Software/Tools/Kits Mit Hyper-Coverage zur sicherheitszertifizierten Software Embedded-Software-Entwicklung • Die Quelldatei selbst bildet die Grundlage für die Analyse, in der Teile des originalen Source- Codes über Makros ausgeblendet sein können. • Eingebundene Header-Dateien können über Makros kontrollierte Konfigurationen enthalten, die wiederum andere Teile des Source- Codes sichtbar machen oder weitere Makros definieren. • Wichtig sind auch die Compiler- Optionen für die jeweilige Quelldatei, wie sie z. B. über eine Entwicklungsumgebung oder ein Makefile eingesteuert und auf der Kommandozeile an den Compiler übergeben werden. © Adobe Stock / THAWEERAT Autor: Michael Wittner Geschäftsführer Razorcat Development GmbH info@razorcat.com www.razorcat.com Für eine Functional-Safety-Zertifizierung müssen Entwickler die Code-Coverage für den gesamten Quellcode inklusive aller Code-Varianten nachweisen. Doch wie lässt sich nicht getesteter Code in den originalen C/C++-Quelldateien erkennen? Eine Lösung bietet hier die Ermittlung einer „Hyper-Coverage“. Testabdeckung Als „Code-Coverage“ (Testabdeckung) bezeichnet man den Nachweis, dass alle Teile eines C/C++-Quellcodes möglichst vollständig getestet wurden. Die Normen empfehlen dabei je nach Einstufung einer sicherheitskritischen Anwendung passende Coverage- Maße wie beispielsweise Statement/Branch-Coverage (C0/C1) oder MC/DC-Coverage. Wurden alle verfügbaren Tests durchgeführt, erhält man eine Aussage, ob und welche Teile des Codes nicht getestet wurden. Die Coverage-Messung stützt sich dabei auf den Kontrollfluss der Funktionen/Methoden einer Quelldatei und prüft die erreichten Programmzweige bzw. Bedingungen. Stellt sich die Frage, welcher Code tatsächlich im Kontrollfluss abgebildet wird. Die vielfachen Möglichkeiten des Präprozessors erlauben es, durch den Einsatz von Makros aus ein und derselben Quelldatei mehrere unterschiedliche Programme zu erstellen. Code-Varianten Aus dem Source-Code einer Quelldatei werden durch den Präprozessor zunächst alle Makros aufgelöst, sodass ein präprozessierter Code entsteht, der letztendlich vom Compiler übersetzt wird. In diesen Prozess fließen die folgenden Informationen ein: Aus diesen Teilen entsteht der präprozessierte Code, der jeweils eine bestimmte Variante des originalen Source-Codes repräsentiert. Die Präprozessor-Makros werden dabei entweder durch #define / #ifdef-Anweisungen in den Header-Dateien oder durch Compiler- Switches aus der Konfiguration beim Aufruf des Compilers übergeben. Dieser präprozessierte Code stellt auch die technische Basis für Testwerkzeuge dar, auf dem die Analyse und Instrumentierung für die Coverage-Messung durchgeführt wird. Varianten testen Bild 1: Unterschiedlicher Kontrollfluss zweier Varianten Beim Test von Varianten ist es entscheidend zu wissen, welche Code- Zeilen aus der Original-Quelldatei in der jeweiligen Variante tatsächlich existieren. Und auch umgekehrt: Gibt es Code in der Origi- 42 PC & Industrie 3/2023

Software/Tools/Kits Bild 2: Kombination der Coverage aus Unit- und Integrationstest nal-Quelldatei, der in keiner Variante enthalten ist? Zunächst muss jede existierende Code-Zeile einer Variante auch genau in dieser Variante getestet werden. Für jede einzelne Variante muss eine möglichst vollständige Code-Coverage erreicht werden. Über Varianten von Testfällen lassen sich die meist relativ ähnlichen Code-Strukturen der Varianten gut testen, so dass der Testaufwand reduziert werden kann. In Bild 1 ist der Kontrollfluss von zwei Varianten mit der erreichten Code-Coverage dargestellt. Man sieht dort, dass die Coverage- Ergebnisse aufgrund der unterschiedlichen Kontrollflüsse nicht einfach übertragen werden können, aber die Testfälle aus der Basis-Implementierung genutzt werden könnten, um den in der Variante fehlenden Programmzweig auf der rechten Seite noch abzudecken. Eine Vererbung und Anpassung der Basis-Testfälle für die Variante spart Aufwand bei der Testerstellung und verhindert redundante Testfälle. Zusammenführen von Coverage Beim Test mit vielen Varianten stellt sich die Frage, ob sich die Coverage-Ergebnisse zusammenfassen lassen, um den Testaufwand zu reduzieren. Diese Möglichkeit bietet sich zunächst nur für unterschiedliche Tests derselben Variante: Bei identischer Präprozessor-Datei ist die Code-Struktur ebenfalls identisch. Damit können die Coverage-Ergebnisse unproblematisch über den Kontrollfluss zusammengeführt werden. Beispielsweise lässt sich fehlende Coverage für Statements/ Branches oder Bedingungskombinationen einer Funktion durch zusätzliche Unit- und Integrations-Tests ergänzen. In Bild 2 wird auf der linken Seite die erreichte Coverage aus dem Integrationstest- Test dargestellt. Der rot unterlegte Programmzweig mit der Sonderbehandlung in dieser Funktion wird im Integrationstest nicht erreicht und daher durch einen weiteren Unit- Bild 3: Coverage-Übersicht pro Funktion der jeweiligen Varianten Test ergänzt. In Summe ergibt sich damit eine vollständige Coverage für diese Funktion in dieser Code- Variante (rechts im Bild 2). Hierarchie aus der Source-Code-Analyse Aus der Analyse des präprozessierten Source-Codes der Varianten ergibt sich eine Hierarchie von Quelldateien mit deren Präprozessor-Varianten und den jeweils darin enthaltenen Funktionen. Bild 3 zeigt eine Quelldatei mit zwei Varianten und den Coverage-Ergebnissen der enthaltenen Funktionen. In dieser Übersicht wurde die kombinierte Coverage aus verschiedenen Tests bereits pro Funktion zusammengefasst. Die Übersicht zeigt zwei noch offene Probleme: Obwohl die Funktionen aus derselben Quelldatei hervorgehen, kann die Coverage aufgrund unterschiedlicher Kontrollflüsse nicht kombiniert werden. Zum anderen fehlt eine Coverage- Aussage auf der Ebene der Original-Quelldatei. Hyper-Coverage als Lösung Eine Zusammenfassung der Coverage-Ergebnisse unterschiedlicher Varianten ist nur auf Zeilenbasis der ursprünglichen Quelldatei möglich. Aus der Analyse des Source-Codes jeder Variante kann ermittelt werden, welche Zeilen der ursprünglichen Quelldatei zu einem Statement/ Branch oder zu einer Bedingung in dieser Variante gehören. Die Zeilen können daher wie folgt bewertet werden: • Wenn die Coverage-Ergebnisse einer Variante erfolgreich sind, dann können die dazugehörigen Zeilen der Quelldatei ebenfalls als erfolgreich markiert werden. • Falls mindestens eine Coverage- Art in einer Variante eine fehlende Abdeckung ergibt, dann wird die Zeile als nicht abgedeckt markiert. • Falls es in keiner Variante Coverage-Ergebnisse zu einer Zeile gibt, dann wird diese Zeile ebenfalls als nicht abgedeckt markiert. Auf diese Art können nicht getestete Code-Zeilen einfach entdeckt werden. In Bild 4 ist das Ergebnis der Hyper-Coverage auf Source-Code- Ebene dargestellt. Der gelb markierte Teil zeigt einen Code-Bereich, für den entweder keine Tests vorhanden sind oder die Tests nicht ausgeführt wurden. Die rot markierten Teile zeigen fehlende Coverage aus unterschiedlichen Coverage-Arten. Für die unten aufgelistete Funktion „func3“ wurden genügend Tests durchgeführt, so dass die geforderte Code-Coverage erreicht wurde. Vorteil der Hyper-Coverage Der Vorteil der Hyper-Coverage besteht darin, dass zwar eine zeilenbasierte Auswertung vorgenommen wird, aber die zugrundeliegenden Coverage-Ergebnisse aus der gewählten Coverage-Art vollständig berücksichtigt werden. Wenn beispielsweise MC/DC-Coverage gefordert ist, dann muss für eine Zeile mit einer komplexen Bedingung in allen Varianten eine vollständige MC/DC-Coverage erreicht PC & Industrie 3/2023 43

hf-praxis

PC & Industrie

© beam-Verlag Dipl.-Ing. Reinhard Birchel