Vector Software W H I T E P A P E R

Transkript

1 Vector Software W H I T E P A P E R Nutzung der Code-Abdeckungsanalyse zur Erhöhung der Zuverlässigkeit von Embedded Software Einleitung Die Code-Abdeckungsanalyse oder Code Coverage dient der Vollständigkeitsprüfung von Softwaretests. Hierbei werden die getesteten Teile des Quellcodes einer Anwendung identifiziert. Auf diese Weise kann schnell und sicher gewährleistet werden, dass keine Anwendung veröffentlicht wird, deren Code nicht komplett getestet wurde. Kann Code Coverage zur Verbesserung der Zuverlässigkeit beitragen? Die Antwort lautet zweifelsfrei Ja! Die Code Coverage Analyse ist der einfachste Weg um die Qualität einer Softwareanwendung zu gewährleisten. Code Coverage Level Code Coverage kann auf verschiedene Arten gemessen werden. Die gängigste Methode ist eine oder eine Kombination der Statement Coverage, Branch Coverage oder Modified Condition/Decision Coverage (MC/DC). Im Folgenden werden die verschiedenen Arten der Code Abdeckungsanalyse detailliert beschrieben. Statement Coverage Statement Coverage zeigt, in welchem Maß funktionale Codezeilen ausgeführt wurden. Hierbei werden keine Schleifen oder Bedienungsanweisungen berücksichtigt, sondern nur die Anweisungen einer ausführbaren Zeile, wobei eine Anweisung hier nicht automatisch das Gleiche bedeutet wie eine Codezeile. In C, C++, Java oder Ada wird eine Anweisung typischerweise anhand eines Semikolons beendet. Es ist also durchaus möglich, dass sich eine einzige Anweisung über mehrere Codezeilen erstreckt. Statement Coverage bietet zwar einen guten Überblick darüber, was ausgeführt wurde und was nicht, dennoch bestehen einige Einschränkungen. Statement Coverage Beschränkungen Betrachten Sie das folgende Code- Fragment in Abbildung 1.

2 int* p = NULL; if (condition) p = &variable; *p = 123; Abbildung 1 Statement Coverage Beispiel zu defektem Code Wenn die condition = true ist, besteht die Möglichkeit 100% Statement Coverage zu erreichen. Allerdings fehlt in diesem Testfall das Szenario, bei dem die condition = false ist. Das Programm würde in diesem Fall einen Nullzeiger dereferenzieren. Statement Coverage gilt als Einstiegslevel der Code Coverage. Im Idealfall wird auch der Fall getestet in dem die condition = false ist. Branch Coverage Branch Coverage misst, ob Entscheidungs- und Verzweigungspunkte für alle möglichen Ergebnisse lückenlos getestet wurden. Zum Beispiel müssen für eine if Aussage sowohl true als auch false Resultate durchlaufen werden, damit sie als abgedeckt gelten. Wenn nur einer der Pfade berücksichtigt wurde, wird die Verzweigung als partiell abgedeckt klassifiziert. Wie bei der Statement Coverage müssen wir auch hier einige Feinheiten beachten. Dies gilt vor allem bei Programmiersprachen, die Lazy Evaluation" durchführen. Lazy Evaluation ist eine Methode, bei der das Codestück erst dann ausgewertet wird, wenn es benötigt wird. Branch Coverage Beschränkungen Typischerweise kommt Lazy Evaluation bei komplexen Booleschen Ausdrücken, wie in Abbildung 2 vor: int* p = NULL; if (condition1 && (condition2 function1(*p))) statement1; else Abbildung 2 Branch Coverage Beispiel zu defektem Code Betrachtet man das Szenario in dem die condition1 = false ist. Bei der Lazy Evaluation wäre es nicht mehr nötig, condition2' oder function1(*p)' auszuwerten. Ebenso wäre der false - Zweig für if (condition1 && (condition2 function1(*p)))' abgedeckt. Nun wird das Szenario in dem sowohl condition1' als auch condition2' true' sind betrachtet. Auch hier würde aufgrund der Lazy Evaluation function1(*p)' nicht aufgerufen. Hier würde dann der true - Zweig für die obige Bedingung durchlaufen. In diesem Fall ist es also möglich 100% Branch Coverage zu erreichen, obwohl möglicherweise Fehler in der Software vorhanden sein können. Seite2

3 Modified Condition / Decision Coverage (MC/DC) MC/DC ist eine Art von Super Branch Coverage. Es zeigt, wie bei der Branch Coverage, die true und die false Ergebnisse einer komplexen Bedingung an. Allerdings berichtet es auch über die true und false Ergebnisse der Sub-Condition einer komplexen Bedingung. MC/DC wurde einst von Boeing entwickelt und wird typischerweise benötigt um eine DO-178B Level A Zertifizierung für Luftfahrtsoftware zu erhalten. Es löst das Problem der Lazy Evaluation, indem gezeigt wird, dass jede Sub-Condition das Ergebnis der Bedingung beeinflussen kann und zwar vollkommen unabhängig von anderen Sub-Condition Werten. Betrachtet man das Beispiel in Abbildung 2, muss hier condition1 für true und false verifiziert werden, während condition2 und function1(*p)' fix sind. Daraufhin muss das gleiche für condition2 gemacht werden während dementsprechend condition1 und function1(*p) fix bleiben. Schließlich wird das Ganze noch für function1(*p)' durchgeführt, während condition1' und condition2' unverändert bleiben. Die beiden Tesfälle zur Verifizierung der True und False Werte einzelner Sub-Conditions, bei gleichzeitigem Beibehalten der anderen Sub-Conditions, bezeichnet man als MC/DC Paar'. Eine MC/DC Wertetabelle wird normalerweise zur Identifizierung der Paare genutzt. Ein Beispiel hierfür kann in Tabelle 1 betrachtet werden. Row Ca Cb Cc Rslt Pa Pb Pc *1 T T T T 5 *2 T T F T T F T T T F F F F T T F 1 6 F T F F 2 7 F F T F 3 Tatsächlicher Ausdruck lautet: ( condition1 && ( condition2 function1 ( *p ) ) ) Condition "a" (Ca) ist: condition1 Condition "b" (Cb) ist: condition2 Condition "c" (Cc) ist: function1 ( *p ) Vereinfachter Ausdruck lautet: ( a && ( b c ) ) Pa => kein Paar wurde erfüllt 1/5 2/6 3/7 Pb => kein Paar wurde erfüllt 2/4 Pc => kein Paar wurde erfüllt ¾ Tabelle 1 Modified Condition / Decision Coverage Wertetabelle Seite3

4 Coverage von verschiedenen Testarten Es gibt viele verschiedene Arten von Softwaretests. Um diesen komplexen Sachverhalt zu vereinfachen, beschränken wir uns hier auf die folgenden drei Ausdrücke: > > > System / Funktionstests: Die komplett integrierte Applikation wird getestet Integrationstests: Integrierte Sub-Systeme werden getestet Unit Tests: Einige individuelle Dateien oder Klassen werden getestet In jedem Software Entwicklungsprozess werden mehr oder weniger umfangreiche Systemtests durchgeführt, in denen der Quellcode mit Aktionen stimuliert wird, die später vom Endnutzer durchgeführt werden. Eine der häufigsten Ursachen für fehlerhafte Anwendungen sind unerwartete und somit ungetestete Eingabekombinationen die während der Nutzung der Anwendung auftreten. Nicht alle Projekte nutzen Integrationstests oder Modul- bzw. Unit Tests da eine große Menge an Test-Code generiert werden muss, um eine einzelne Datei oder eine Gruppe von Dateien vom Rest der Anwendung isoliert zu testen. Wenn Unit- oder Integrationstests auf hohem Niveau durchgeführt werden, ist es nicht unüblich, dass die Menge des geschriebenen Testcodes die Menge des zu testenden Anwendungscodes übersteigt. Daher werden diese Testniveaus normalerweise bei missionsund sicherheitskritischen Anwendungen in reglementierten Märkten, wie: Luftfahrt, Medizintechnik, Eisenbahn, Industrie-Automation und der Automobilindustrie angewendet. Viele der für diese Industriezweige geschriebenen Anwendungen beinhalten Embedded Software. Strukturelle Testverfahren für reglementierte Branchen drehen sich oft um die Prüfung der High-und Low-Level-Anforderungen und der Analyse der Code Coverage, die aus diesen anforderungsbasierten Tests resultiert. Bei vielen Projekten werden zuerst High-Level- oder Funktionsanforderungen getestet. Die Code Coverage Analyse kann verwendet werden um die erreichte Codeabdeckung zu erfassen und diese zu beschreiben. Leider ist es fast unmöglich eine hundertprozentige Code Coverage durch System- / Funktionstests zu erreichen. Im Normalfall werden Sie etwa 60% -70% Code Coverage bei diesen Tests erlangen. Die restlichen 30-40% Code Coverage werden erst durch Unit- und Integrationstests erreicht. Zu Unit-Tests gehört auch die Verwendung von Testcode in Form von Test-Treibern und Stubs, um bestimmte Funktionen der Anwendung zu isolieren und diese Funktionen mit Testfällen zu Seite4

5 stimulieren. Diese anforderungsbasierten Low-Level"- Tests ermöglichen eine viel größere Kontrolle über den getesteten Code und werden verwendet, um die zuvor ausgeführten Systemtests zu erweitern und bis zu 100% Coverage zu erreichen. Daher ist es sehr vorteilhaft, Coverage-Daten von verschiedenen Testarten zu kombinieren. Herausforderungen des Erfassens von Coverage in einer Embedded Umgebung Eine alte Redewendung besagt: Von Nichts kommt Nichts. Im Falle der Code Coverage ist der zu betreibende Aufwand das Instrumentieren der zu testenden Quelldateien. Instrumentierung bedeutet das Hinzufügen von Quellcode um das Sammeln von Coverage- Daten einer Anwendung zu ermöglichen, während Funktionstests ausgeführt werden. Der Overhead, der durch die Instrumentierung entsteht, führt unmittelbar zu größeren Quelldateien und Programmen und indirekt zu einer erhöhten Ausführungszeit. Die Möglichkeit, die Auswirkungen der Instrumentierung des Quellcodes für die Coverage zu prognostizieren, kann von entscheidender Bedeutung sein. Dies gilt insbesondere bei Tests in einer Echtzeit Embedded Umgebung. Leider ist es nicht hundertprozentig genau möglich, die exakten Auswirkungen zu prognostizieren, die die Instrumentierung auf einen bestimmten Satz von Anwendungsdateien haben kann. Für diesen Zweck gibt es keinen Algorithmus und es wird vermutlich auch nie einen geben. Zu viele Variabeln sind beteiligt und jede Anwendung ist einzigartig in ihrer Komplexität. Es ist jedoch möglich, eine Reihe von Schätzungen von einem repräsentativen Beispiel abzuleiten. Erfassen von Coverage Daten auf dem Zielsystem Eines der Hauptprobleme bei der Verwaltung von Code Coverage in einer Embedded Umgebung kann das Fehlen von Speicher sein, um den zusätzlichen Instrumentierungscode unterzubringen. Schätzungen zufolge, kann bei einem Coverage Tool auf dem neusten Stand der Technik, der Quellcode um bis zu 10 Prozent anwachsen. Für die meisten 32-Bit-Targets stellt dies heute kein Problem dar. Für 8 und 16 Bit-Targets mit sehr begrenzten Speicherkapazitäten kann dies jedoch von großer Bedeutung sein. Daher werden unterschiedliche Code Instrumentierungstechniken eingesetzt, um die Größe der ausführbaren Programme zu reduzieren. Verschiedene Datenerfassungsverfahren werden auch in Abhängigkeit des verfügbaren Speichers verwendet. In-Memory-Speicher-Systeme werden genutzt, um zu messen, welche der Codezweige erreicht wurden. Dies gehört zur Seite5

6 wesentlichen Technologie zur Minimierung der genutzten RAM-Menge in der instrumentierten Anwendung. Fazit Code Coverage bedeutet nicht das gleiche wie komplett getestet oder fehlerfrei. Wenn die Code Coverage bei einer Anwendung 100% beträgt, heißt das nicht zwangsläufig, dass die Anwendung auch zuverlässig ist. Es bedeutet lediglich, dass die durchgeführten Tests den gesamten Code durchlaufen haben, um so den gewünschten Grad an Coverage zu erreichen. Code Coverage ist keine Lösung für alles, sondern eher eine kontinuierliche Bemühung in Richtung einer zuverlässigen Software. Je früher sie eingesetzt wird, desto besser. Sie bietet Raum, um Tests hinzuzufügen, Tests zu verbessern, redundante Tests zu entfernen und mehr Code abzudecken, wodurch eine höhere Qualität und zuverlässigere Systeme gewährleistet werden können. Zwar gibt es einige Hürden, die bei der Nutzung von Code Coverage Werkzeugen in einer Embedded Umgebung überwunden werden müssen, dennoch ist der Einsatz dieser Werkzeuge dank der neusten Fortschritte in fast allen Fällen sehr wirkungsvoll. Über Vector Software Vector Software ist der weltweit führende Anbieter von Software Test Lösungen für sicherheitskritische und geschäftskritische embedded Applikationen. Weltweit vertrauen Unternehmen in Luft und Raumfahrt, Militär, Medizintechnologie, Automobilindustrie, Bahnverkehr und anderer Industriezweige in geschäftskritischen Sektoren auf Vector Software s VectorCAST. Durch die Automatisierung und die Bewältigung komplexer Aufgaben im Zusammenhang mit Modul, Integrationsund Systemlevel Tests, erleichtert VectorCAST Unternehmen, deren Entwicklungen zu beschleunigen und die Beständigkeit Ihrer eingebetteten Software Applikationen zu gewährleisten. Vector Software, Inc South County Trail, Suite 310 East Greenwich, RI USA T: F: E: info@vectorcast.com Vector Software Golden Cross House 8 Duncannon Street London WC2N 4JF, UK T: F: E: info@vectorcast.com Vector Software St. Töniser Str 2a Kempen Germany T: F: E: info@vectorcast.com Vector Software Rm 403, Building 6, No.88 Daerwen Rd, Zhangjiang Hi-tech Park Pudong New Area Shanghai China T: F: E: info@apac.vectorcast.com Seite6