2008-10-16 6 views
6

Ich habe vor kurzem begonnen, an einem sehr großen C++ - Projekt zu arbeiten, das nach Abschluss von 90% der Implementierung festgestellt hat, dass es eine 100% ige Zweigabdeckung während des Testens demonstrieren muss. Das Projekt wird auf einer eingebetteten Plattform gehostet (Green Hills Integrity). Ich suche nach Vorschlägen und Erfahrungen von anderen Benutzern von StackOverflow, die Code Coverage-Produkte in ähnlichen Umgebungen verwendet haben. Ich bin an positiven und negativen Kommentaren zu diesen Tools interessiert.Code-Coverage-Analyse für eingebettete C++ - Projekte

Antwort

5

100% Filialabdeckung? Das ist durchaus erforderlich, insbesondere da einige Zweige (z. B. Voreinstellungen für State-Maschinen) nicht ausgeführt werden können. Ich erwarte, dass es einige Ausnahmen gibt, und wenn es nicht gibt, müssen Sie vielleicht verstehen, was Abdeckungstests können und nicht erreichen können, bevor Sie beginnen - sonst werden Sie am Ende ziehen Ihre Haare oder schlimmer - geben falsche Daten.

Die meisten Abdeckungstests für eingebettete Systeme werden tatsächlich auf PCs durchgeführt. Der Code wird portiert, bestimmte Aspekte des Mikrocontrollers werden in Software emuliert, und Bullseye oder ein anderes ähnliches PC-Code-Abdeckungs-Dienstprogramm wird ausgeführt. Der Grund dafür ist, dass es zu viele Mikrocontroller und Compiler/Debugger/Testumgebungen gibt, um Code-Coverage-Tools für jeden zu entwickeln.

Wenn Code Coverage-Tools für eine bestimmte eingebettete Plattform vorhanden sind, sind sie nicht so leistungsstark, konfigurierbar, einfach zu verwenden und fehlerfrei wie die für die PC-Plattform entwickelten. Die Prozessoren verfügen häufig nicht über die Trace - Fähigkeit (ohne High - End - Emulationshardware), die für eine gute Codeabdeckung erforderlich ist, ohne zusätzlichen Debugcode in die Firmware einzufügen. Dies hat dann schwer zu kontrollierende Konsequenzen und Nebenwirkungen, insbesondere bei Timing - Problemen Echtzeitsysteme.

Portieren von Code ist nicht schrecklich schwierig, solange Sie den Hardware-spezifischen Code abstrahieren können (und da Sie C++ richtig verwenden, sollte das einfach sein, richtig? ;-D). Das größte Problem, mit dem Sie konfrontiert werden, sind Typen, die, obwohl sie in C++ besser spezifiziert sind als in C, immer noch einige Probleme aufwerfen. Stellen Sie sicher, dass Sie ein types.h oder ein ähnliches Setup verwenden, um dem Compiler genau zu sagen, was jeder verwendete Typ ist und wie er interpretiert werden soll.

Danach können Sie in die Stadt gehen, um die Kernlogik auf dem PC zu testen. Sie können sogar die Hardwaretreiber auf niedriger Ebene testen, wenn Sie daran interessiert sind, die erforderliche Softwareemulation zu entwickeln, obwohl Timing-Probleme etwas mühsam sein können.

Software-Test-Tools wie MxVDev führen eine Menge der Mikrocontroller-Emulation für Sie durch und helfen auch bei Timing-Problemen, aber Sie werden auch mit dieser Hilfe noch ein bisschen arbeiten müssen.

Wenn Sie dies auf dem System selbst tun müssen, müssen Sie einen Emulator für den Prozessor mit Abdeckungsfähigkeit kaufen - kein kostengünstiges Angebot (viele Emulatoren kosten mehr als $ 30k für den vollen Satz von Tools und Emulationshardware), aber es ist eines der vielen Tools, die in Umgebungen mit hoher Zuverlässigkeit wie der Automobil- und der Luft- und Raumfahrtindustrie verwendet werden.

-Adam

Disclaimer: Ich für das Unternehmen arbeiten, die MxVDev produziert.

+0

Nur eine Notiz, die Bullseye scheint nicht Greenhills Integrität für jeden in Anbetracht seiner Verwendung zu unterstützen. – Gary

2

Wie bei Adam, portieren wir unseren Embedded-Code auf einen PC-basierten Kabelbaum und machen den größten Teil der Abdeckung und Profilerstellung dort. Ich habe AutomatedQA AQTime und Compuwares DevPartner verwendet, die beide gute Produkte sind,

Wenn Sie Coverage-Board zu tun hatten, müssten Sie einen Coverage-Profiler verwenden, der eine instrumentierte Version der Quelle erstellt.Es gibt sowohl kommerzielle als auch Open-Source-Tools zur Verfügung, aber IMO, fügt es eine Menge Arbeit für nicht viel Gewinn hinzu.

100% Deckung ist ambitioniert, da Sie eine Menge Fehlerinjektion benötigen, um in alle Ihre Fehlerbehandler und Exception Handler zu gelangen. IMO, dies wäre auch einfacher in einem Gurtzeug als an Bord.

Es ist auch wert, darauf hinzuweisen, wer für 100% Code-Abdeckung, 100% Code-Abdeckung in keiner Weise entspricht 100% Testabdeckung angefordert hat. Betrachten Sie zum Beispiel die folgende Funktion;

100% Codeabdeckung erfordert nur, dass wir diese Funktion einmal aufrufen, 100% Testabdeckung würde viel mehr Anrufe erfordern. Meine eigene Teststrategie beinhaltet die Entwicklung automatisierter Testfälle, um mir ein akzeptables Niveau von Testabdeckung zu geben und ein Code-Coverage-Tool zu verwenden, nur um nach ungeprüften Bereichen zu suchen. Bis zu einem gewissen Grad hängt dies von Ihrem Testbudget ab; Für mich ist eine 100% ige Codeabdeckung viel zu teuer für das, was sie liefert.

3

Wir haben Cantata und vectorcast in der Vergangenheit für Unit-Tests und Code-Abdeckung verwendet. Wir verwenden auch die Greenhills-Tools und beide Tools arbeiten mit den GreenHills-Entwicklungstools. Wir führen den größten Teil unseres Tests mit dem PPC-Simulator aus und führen einfach Tests durch, die auf Hardware auf der Zielhardware über einen JTAG-Pod basieren. Canatata und Vector cast sind sehr ähnlich mit catata nur ein bisschen einfacher zu bedienen und haben ein bisschen mehr Funktionen, aber die kleinen Extras machen einen großen Unterschied in der Benutzererfahrung.

Im Allgemeinen, wenn Sie eine hohe Zweigabdeckung erreichen möchten, müssen Sie Ihren Code für Testbarkeit entwerfen. Je mehr Sie testen, desto mehr lernen Sie, testbaren Code zu schreiben.

Wir haben auch versucht, PC-Tests versus Embedded-Tests gab uns Probleme wegen der Endianess, aber das ist nur ein Problem auf der Hardware-Ebene.

Zusätzlich sind diese Werkzeuge nach RTCA/DO-178B Standard zertifiziert.

+0

+1 für Kantate ... wir müssen es auch benutzen! – espais

0

Siehe SD C++ Test Coverage. Dies ist eine Familie von (Zweig-) Testabdeckungswerkzeugen für eine Vielzahl von C++ - Dialekten (ANSI, GNU, MS ...), die sogar in der tatsächlichen Hardware eingebetteter Systeme gut spielen, da sie einen sehr geringen Platzbedarf haben und einfach sind Möglichkeit, die gesammelten Testdaten zu exportieren. Es gibt eine GUI-Coverage-Anzeige, die nicht von Ihrer tatsächlichen eingebetteten Hardware abhängig ist, die auch eine vollständige Berichterstattungszusammenfassung erzeugt.

[Ich bin ein Haupt in der Firma, die diese Werkzeuge zur Verfügung stellt.]