Software-Test
Code-Coverage auf kleinen Targets
Fortsetzung des Artikels von Teil 2
Messung durch Code-Instrumentierung
Zur Messung der Code Coverage werden Hardware- und Softwarewerkzeuge eingesetzt. Dieser Beitrag konzentriert sich auf die Softwarewerkzeuge, welche derzeit die höchste Marktdurchdringung haben. Um die Code Coverage zu messen, müssen dabei durch ein Coverage Tool globale Zähler in den Programmcode eingefügt werden. Diese Zähler werden an den wichtigen Entscheidungspunkten inkrementiert, ohne dabei das logische Programmverhalten zu beeinflussen. Dieser Vorgang wird als Instrumentierung bezeichnet. Nach Abschluss der Tests können die Zählerstände verwendet werden, um mittels einer gespeicherten Referenztabelle die Code Coverage zu berechnen.
Die einfache Abfrage if ( a<0 ) könnte in C so instrumentiert werden.
if ( (a<0&&(zaehler1++||1)) ||(zaehler2++&&0) )
Alternativ geht das auch mit dem ternären Operator:
if ( (a<0) ? (zaehler1++,1) :(zaehler2++,0) )
Die Auslieferung der instrumentierten Programmversion ist eher unüblich. Idealerweise sollte der Automatisierungsgrad der White-Box- und Black-Box-Testsuiten recht hoch sein. So lassen sich die Tests mit und ohne instrumentierte Version effizient und nachvollziehbar wiederholen.
Besonderheiten kleiner Zielsysteme
Bei der Bestimmung der Code Coverage auf dem Target ergeben sich einige Herausforderungen, die man in dieser Form bei hostseitigen Tests nicht hat. Ist im Vorfeld ein für das kleine Target passende xUnit-Testframework ausgewählt und die Funktionen und Module lassen sich aufgrund der modularen Architektur durch Testdriver ansprechen, dann ist man dem Ziel einer hundertprozentigen Abdeckung einen wichtigen Schritt näher gekommen. Da kleine Targets meist über kein Dateisystem verfügen, müssen die globalen Zähler im RAM gehalten werden. Über Schnittstellen muss deren Inhalt nach Testende an das Hostsystem übermittelt werden. Steht hierfür keine passende Schnittstelle (z.B. RS 232 oder JTAG) zur Verfügung, so muss zumindest für die Tests eine solche Schnittstelle vorhanden sein.
Sind diese Hürden genommen, so ist meist der eingeschränkte RAM- und ROM-Speicher auf dem Target der begrenzende Faktor. Die globalen Zähler benötigen in Abhängigkeit von der Cyclomatic Complexity (CC) des instrumentierten Teils des Programmcodes entsprechend mehr Speicher. Bei der sparsamen Instrumentierung für Funktionsüberdeckung ist hingegen nur die Anzahl der Funktionen entscheidend. Auch der ausführbare Code im ROM wird durch die Instrumentierung entsprechend größer. Steht auf dem Target nicht genügend Speicher zur Verfügung, so zeigen praktische Erfahrungen auf, dass bei achtzig Prozent der Fälle die Speicherknappheit durch das RAM entsteht. Die restlichen zwanzig Prozent entfallen dabei auf den ROM-Speicher, in welchem oft noch zusätzlich eine kleine Laufzeitbibliothek zur Übergabe der Zählerstände an das Hostsystem enthalten ist.
Jobangebote+ passend zum Thema
Es bietet sich zur Lösung für beide Speicherengpässe grundsätzlich eine partielle Instrumentierung an, wie sie in Bild 4 dargestellt ist. Dabei werden m unterschiedliche Programmteile instrumentiert und die Tests müssen dann auf allen partiellen instrumentieren Versionen ausgeführt werden.
Ein weiterer Ansatz zur Reduzierung des Speicherbedarfs ist die Wahl der Abdeckungsstufe. Testwell CTC++ bietet beispielsweise bei der Instrumentierung drei Abdeckungsstufen (Funktionsüberdeckung, Zweigüberdeckung, Mehrfachbedingungsüberdeckung) an. Aus diesen können dann zusätzlich auch die Anweisungsüberdeckung C0 und MC/DC abgeleitet werden. In Abhängigkeit von der verwendeten Norm sollte hier die geringste geforderte Abdeckungsstufe ausgewählt werden.
- Code-Coverage auf kleinen Targets
- Coverage-Stufen
- Messung durch Code-Instrumentierung
- Engpass RAM-Speicher
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
