Sind alle Codevarianten getestet?
Blinde Flecken im Code aufspüren
Von eingebetteter Software werden oft Varianten hergestellt. Dabei besteht die Gefahr, dass Varianten ungetestet bleiben. Code-Coverage-Messung hilft hier nicht.
Varianten von eingebetteter Software unterscheiden sich meist nur geringfügig. Durch die Varianten wird die Software beispielsweise an unterschiedliche Hardwarekomponenten angepasst oder an unterschiedliche Anforderungen von Kunden, die diese Software einsetzen.
Jobangebote+ passend zum Thema
Falls die eingebettete Software in den Programmiersprachen C oder C++ geschrieben ist, wird oftmals der Präprozessor dieser Sprachen zur Erzeugung der Varianten herangezogen. Welche Variante erzeugt wird, kann davon abhängen, welche Präprozessorkonstante definiert ist (Bild 1, links) oder welchen Wert eine Präprozessorvariable hat (Bild 1, rechts).
Im Bild ist auf der linken Seite die Möglichkeit dargestellt, Varianten durch Präprozessorkonstanten zu implementieren. Ist weder die Präprozessorkonstante VARIANT_1 noch die Präprozessorkonstante VARIANT_2 definiert, wird die Basis- oder Grundvariante der Software entstehen und der Variablen result wird der Wert 0 zugewiesen. Ist nur die Präprozessorkonstante VARIANT_1 definiert, wird der Variablen result der Wert 1 zugewiesen. Analog ist es bei VARIANT_2.
Die rechte Seite von Bild 1 zeigt das Vorgehen, Varianten durch Werte von Präprozessorvariablen zu implementieren. Ist die Präprozessorvariable VARIANT weder 1 noch 2, wird die Basis- oder Grundvariante der Software entstehen und der Variablen result wird der Wert 0 zugewiesen. Hat VARIANT den Wert 1 bzw. 2, wird der Variablen result der Wert 1 bzw. 2 zugewiesen.
Wie das Definieren der Präprozessorkonstanten bzw. das Setzen von Präprozessorvariablen technisch erfolgt, spielt für unser Problem der möglicherweise ungetesteten Varianten keine Rolle. Das Definieren bzw. Setzen kann auf der Kommandozeile des Compilers erfolgen oder es werden beispielsweise unterschiedliche, aber namensgleiche Header-Dateien eingebunden, in denen dann die Konstanten bzw. Variablen passend definiert oder gesetzt werden. Ebenfalls ist es unerheblich, wie genau die Auswahl der Varianten mithilfe des Präprozessors implementiert ist; Bild 1 zeigt lediglich zwei Beispiele hierfür.
Ungetestete Varianten finden
Um die Frage zu klären, ob es ungetestete Varianten gibt, müssen einige Informationen zusammengetragen werden. Zunächst müssen aus der Quelldatei, so wie sie in Bild 1 dargestellt ist, die Zeilen mit ausführbarem Code ermittelt werden. Dann müssen für jede Variante, in der die betroffene Quelldatei getestet wird, ebenfalls die Zeilen mit ausführbarem Code ermittelt werden, aber dieses Mal aus dem präprozessierten Code.
Der präprozessierte Code ist die eigentliche Basis für den Test; er ist das, was der Compiler sieht. Insbesondere sind die ausführbaren Zeilen aus der Quelldatei, die in einer Variante nicht ausgeführt werden, im präprozessierten Code durch Leerzeilen ersetzt. Die ausführbaren Zeilen aus dem präprozessierten Code aller Varianten müssen mit den ausführbaren Zeilen aus der Quelldatei abgeglichen werden. Findet man eine ausführbare Zeile aus der Quelldatei, die in keiner Variante vorkommt, wird diese Zeile auch nicht getestet. Es versteht sich von selbst, dass Änderungen, beispielsweise an der Quelldatei, die gesammelten Informationen ungültig machen.
Code-Access-Analyse
In Bild 2 ist das Ergebnis einer Code-Access-Analyse von TESSY dargestellt. TESSY ist ein Werkzeug zum automatisierten Modul-/Unit-Test von eingebetteter Software. Eine neue Funktion in Version 5.1 von TESSY ist die Code-Access-Analyse. TESSY ermittelt diese durch die oben beschriebene Vorgehensweise. Bei der Analyse einer Quelldatei in TESSY entsteht der präprozessierte Code. TESSY verwendet Prüfsummen (SHA1, sowohl für den Quellcode als auch für den präprozessierten Code), um sicherzustellen, dass die verwendeten Informationen zusammenpassen. Die gelb unterlegte Zeile 10 in Bild 2 bedeutet, dass es keinen präprozessierten Code gibt, in dem der Code aus Zeile 10 enthalten ist, also wird diese Zeile nicht getestet, sowohl für die Implementierung auf der linken Seite von Bild 2 als auch auf der rechten Seite. Oder anders ausgedrückt: Variante 2 wird nicht getestet.
Das Ergebnis der Code-Access-Analyse wird von TESSY auch in Prozent ermittelt, sowohl für jede einzelne Quelldatei als auch über alle Quelldateien aufsummiert. Ist die Code-Access-Summe bei 100 %, weiß man, dass es keine ungetesteten Varianten gibt. In den beiden Beispielen in Bild 2 zählt TESSY jeweils sieben Zeilen mit ausführbarem Code (Zeilen 1, 3, 4, 5, 7, 10, 12); eine davon (Zeile 10) ist nicht ausgeführt; damit ergibt sich ein Code-Access-Wert von 85,71 % (6/7).
Werden die Basisvariante und Variante 1 getestet, wird dabei (im vorliegenden Beispiel mit je nur einem Testfall) 100 % Codeüberdeckung erzielt. Das liegt daran, dass beim Test dieser beiden Varianten die Zeile 10 eine Leerzeile ist und somit für die Coverage-Messung nicht betrachtet wird. Code-Coverage-Messung entdeckt den fehlenden Test von Variante 2 also nicht.
Werden Varianten nicht mithilfe des Präprozessors implementiert, sondern mit Anweisungen der eigentlichen Sprache (beispielsweise if-Anweisungen), so werden ungetestete Varianten durch die Coverage-Messung aufgedeckt. In diesem Fall tritt das oben beschriebene Problem nicht auf.
Sicherheitskritischen Code vollständig testen
Insbesondere bei sicherheitskritischen Projekten mit vielen Varianten ist es wichtig, nachweisen zu können, dass alle Varianten getestet wurden, bzw. auf einen Blick zu sehen, welche Quellcodemodule ungetestete Varianten enthalten.
Bild 3 zeigt die grafische Darstellung der Code-Access-Analyse in einem Testreport von TESSY. Die X-Achse zeigt die Quellcodemodule und die Y-Achse die Codezeilen. Natürlich gibt es im Testreport auch eine Tabelle mit den Quellcodenamen und der erreichten Code-Access-Prozentzahl.
Weitere Informationen zu TESSY gibt es unter www.hitex.de/tessy. Dort befindet sich auch eine kostenlose Evaluierungsversion zum Ausprobieren.
Der Autor
Frank Büchner
hat ein Diplom in Informatik der Technischen Hochschule Karlsruhe, heute KIT. Seit vielen Jahren widmet er sich den Themen Testen und Software-Qualität. Momentan arbeitet er als Principal Engineer Software Quality bei der Fa. Hitex GmbH in Karlsruhe.
Lesen Sie mehr zum Thema
