Vector Software W H I T E P A P E R. Die Bewertung von Werkzeugen für Softwaretests in eingebetteten Systemen

Vector Software W H I T E P A P E R Die Bewertung von Werkzeugen für Softwaretests in eingebetteten Systemen Was kann Ihr Testwerkzeug? In den letzten Jahren wurde der Markt für Testautomatisierungstools förmlich überschwemmt mit Tools, die alle für sich in Anspruch nehmen, Testprozeduren automatisieren zu können. In Wikipedia sind allein für C/C++ 38 Testframework-Tools aufgeführt. Das Problem für potenzielle Nutzer besteht darin, dass sie beim Blättern in Produktdokumentationen oder dem Betrachten einfacher Produkt-Demos kaum Unterschiede zwischen diesen Testwerkzeugen erkennen. In diesem White Paper sind die Merkmale und Daten aufgeführt, auf die Techniker bei der Bewertung von automatisierten Software-Test-Tools, insbesondere den dynamischen, achten sollten. Beurteilen Sie nicht nur anhand des Datenblatts Datenblätter sehen alle ziemlich ähnlich aus. Sie enthalten die üblichen Schlagwörter wie Branchenführer, Einzigartige Technologie, Automatisiertes Testen oder fortgeschrittene Techniken. Und die Abbildungen umfassen Balkendiagramme, Ablaufdiagramme, HTML-Reports und Status-Prozentzahlen. Kurzum: Solche Informationen sind todlangweilig. Was genau versteht man eigentlich unter Softwaretests? Wir alle haben schon auf die eine oder andere Art Software getestet und wissen deshalb, dass es unterschiedliche Arten von Test gibt. Um Unklarheiten zu vermeiden, verwenden wir in diesem White Paper folgende drei Überbegriffe: Systemtest: Test der vollintegrierten Applikation Integrationstest: Test eines integrierten Teilsystems Modultest: Test einiger einzelner Dateien oder Klassen Jeder führt hin und wieder Systemtests durch, indem er etwas ausprobiert, was voraussichtlich auch der Endanwender tun wird. Etwas, nicht alles. Einer der häufigsten Gründe für Fehler in einer Anwendung ist der, dass es in der Praxis zu Eingabekombinationen kommt, die von den Entwicklern nicht erwartet und dementsprechend vorher nicht getestet wurden. 2010 - All rights reserved - Vector Software VectorCAST.com

Integrationstests werden schon weniger oft durchgeführt und Modultests noch seltener. Wenn Sie schon einmal Integrations- oder Modultests durchgeführt haben, ist Ihnen schmerzlich bewusst, wie viel Testcode generiert werden muss, um eine einzelne Datei oder Gruppe von Dateien aus einer Anwendung zu isolieren. Bei besonders strengen Tests ist es nichts Ungewöhnliches, dass der geschriebene Testcode umfangreicher ist als der zu testende Anwendungscode. Solche Tests sind deshalb in der Regel nur für sicherheitskritische Anwendungsbereiche, wie zum Beispiel Luft- und Raumfahrt, Medizintechnik und Schienenverkehr, üblich. Was genau bedeutet Testautomatisierung? Es ist bekannt, dass manuelle Integrations- oder Modultests langwierige und arbeitsintensive Vorgänge sind. Dementsprechend schreibt sich jedes in diesem Markt verkaufte Tool den Begriff Testautomatisierung auf die Fahnen. Aber was genau versteht man eigentlich darunter? Automatisierung ist nicht für jeden das Gleiche. Viele Techniker erhoffen sich von einer Testautomatisierung, dass sie lediglich eine Taste drücken müssen, um dann entweder ein grünes Häkchen angezeigt zu bekommen, welches die Richtigkeit ihres Codes signalisiert, oder aber ein rotes X (Fehler). Leider gibt es so ein Testwerkzeug nicht. Was aber, wenn es doch angeboten auf dem Markt wäre? Würden Sie es nutzen wollen? Denken Sie mal darüber nach. Wären Sie denn wirklich schlauer, wenn Ihnen das Tool angeben würde, dass Ihr Code Ok ist? Was würde das bedeuten? Dass Sie den Code gut formatiert haben? Dass er Ihren Codierungs- Standards entspricht? Vielleicht. Aber wüssten Sie auch ob Ihr Code wirklich richtig ist? Leider nein! Vollständig automatisierte Tests sind weder möglich noch wünschenswert. Die Automatisierung sollte sich auf die Teile des Testvorgangs erstrecken, die ihrem Wesen nach algorithmisch und arbeitsintensiv sind. Die so eingesparte Zeit kann der Software- Entwickler in anspruchsvollere Tätigkeiten in Zusammenhang mit dem Test investieren, wie zum Beispiel in die Entwicklung besserer und vollständigerer Tests. Die logische Frage bei der Evaluierung eines Testwerkzeugs lautet: Wie viel Automatisierung bietet es? Dies ist die große Grauzone und eine Quelle großer Unsicherheit, wenn ein Unternehmen die Rendite aus Investitionen in solche Werkzeuge einschätzen möchte. VectorCAST.com Seite 2

Analyse von Testwerkzeugen Test-Tools stellen im Allgemeinen zahlreiche Funktionalitäten zur Verfügung. Die Hersteller geben ihnen unterschiedliche Namen und nicht alle Werkzeuge bieten alle Funktionalitäten. In diesem Dokument verwenden wir folgende Namen für Module, wie sie in (manchen) Test-Tools enthalten sind: Parser CodeGen Testrahmen (Test Harness) Compiler Ziel (Target) Testeditor Abdeckung (Coverage) Mittels des Parser-Moduls versteht das Tool Ihren Code. Es liest den Code und stellt ihn dar (meistens als Baumstruktur). Also so ähnlich wie ein Compiler. Die resultierenden Parse-Daten werden in der Regel in einer Intermediate Language (IL) Datei ausgegeben. Das Codegenerator-Modul verwendet die Parse-Daten, um den Testrahmen- Quellcode zu erstellen. Der Testrahmen selbst ist kein ausgewiesener Bestandteil des Tools, aber die Entscheidungen, die in der Testrahmenarchitektur fallen, betreffen alle anderen Merkmale des Tools. Die Rahmenarchitektur ist für die Bewertung eines Tools also sehr wichtig. Das Compiler-Modul ruft den Compiler auf, damit dieser die Übersetzung durchführt und die Testrahmenkomponenten verknüpft. Das Ziel-Modul macht es möglich, dass Tests problemlos in verschiedenen Umgebungen ablaufen können. Dazu gehört auch die Unterstützung von Emulatoren, Simulatoren, eingebetteten Debuggern und gängigen RTOS. Durch den Testeditor hat der Anwender die Wahl, ob er zur Festlegung von Bedingungen und Erwartungswerten (PASS/FAIL-Kriterien) für Testfälle eine Skriptsprache oder eine komplexe grafische Benutzeroberfläche (GUI) nutzen will. Mithilfe dieses Moduls erhält der Anwender die Informationen, welche Teile des Codes von dem jeweilig durchgeführten Test ausgeführt werden. Reporting Das Report-Modul sorgt dafür, dass erfasste Daten in einer Projektdokumentation kompiliert werden können. CLI Regression Integration Eine Command Line Interface (CLI) ermöglicht eine erweiterte Automatisierung bei der Tool-Anwendung; das Tool kann von Skripts, Make etc. aus aufgerufen werden. Mittels des Regression-Moduls können Tests, die für eine Anwendungsversion erstellt wurden, auch für die neuen Versionen durchgeführt werden. Integrationen in ein Drittanbieter-Tool sind unter Umständen eine interessante Möglichkeit, um Ihre Investitionen in ein Test-Tool zu finanzieren. Üblicherweise gibt es Integrationen mit Konfigurationsmanagement, Anforderungsmanagement-Tools sowie statischen Analyse-Tools. Später erfahren Sie hier noch, wie Sie die einzelnen Module in den Ihnen zur Auswahl stehenden Tools evaluieren sollten. VectorCAST.com Seite 3

Testwerkzeug-Kategorien / Automatisierungsgrade Da nicht alle Test-Tools die oben beschriebenen Funktionen oder Module umfassen und auch weil die angebotene Automatisierungsstufe recht unterschiedlich ist, unterteilen wir sie in die folgenden Hauptkategorien. Manuell Halbautomatisiert Automatisiert Manuelle Tools erstellen im Allgemeinen einen leeren Testrahmen und verlangen vom Anwender, die für die Implementierung der Testfälle benötigten Testdaten und Logik manuell zu codieren. Sie umfassen oft eine Skriptsprache und/oder einen Satz von Bibliotheksfunktionen, die für die Ausführung üblicher Vorgänge wie Testaussagen oder zur Erstellung formatierter Berichte für Testdokumentationen verwendet werden können. Halbautomatisierte Tools versehen einen Teil der automatisierten Funktionalität, wie sie ein manuelles Tool bietet, mit einer grafischen Oberfläche. Zum Testen komplexerer Konstrukte sind aber ebenfalls manuelles Codieren und/oder Skripten erforderlich. Bestimmte Module, über die ein automatisiertes Tool auf jeden Fall verfügt, wie zum Beispiel integrierte Unterstützung für Target-Deployment, fehlen in halbautomatisierten Tools. Automatisierte Tools eignen sich für jeden der im vorherigen Abschnitt aufgeführten Funktionsbereiche oder Module. Bei Test-Tools dieser Kategorie ist keine manuelle Codierung erforderlich. Sie unterstützen alle Sprachkonstrukte ebenso wie eine große Anzahl von Target-Deployments. Kleinere Unterschiede Nicht nur der Vergleich von angebotenen Funktionen und Automatisierungsgraden ist wichtig, sondern auch die Evaluierung und der Vergleich der angewendeten Methoden. So werden zum Beispiel einige Test-Tools bei der Erstellung eines Projekts die Dateien einfach in die IDE laden und Testrahmen oder Testfälle erst erstellen, wenn Sie eine Aktion anstoßen. Auf diese Weise könnten Mängel im Tool verborgen bleiben. Es ist deshalb wichtig, dass Sie nicht einfach nur Ihren Code in das Tool laden, sondern auch versuchen, für jedes Verfahren in der von Ihnen getesteten Kategorie einige einfache Testfälle zu erstellen. Richtet das Tool einen vollständigen Testrahmen ein? Werden alle Scheinprozeduren automatisch erstellt? Können Sie die GUI zur Definition von Parametern und globalen Daten für die Testdatensätze verwenden oder müssen Sie Code schreiben, so als ob Sie einen manuellen Test durchführen würden? Auch die Zielsystemunterstützung ist bei den Tools recht unterschiedlich. Seien Sie auf der Hut, wenn Ihnen ein Anbieter sagt: Wir unterstützen alle Compiler und alle Ziele. Übersetzt heißt das nämlich: Sie müssen selbst dafür sorgen, dass unser Tool in Ihrer Umgebung läuft. VectorCAST.com Seite 4

Wie Sie Testwerkzeuge bewerten (evaluieren) In den folgenden Abschnitten erhalten Sie ausführliche Informationen zu den Merkmalen, auf die Sie bei der Evaluierung eines Software-Test-Tools besonders achten sollten. Überprüfen Sie bei der praktischen Erprobung eines Tools möglichst jedes dieser Merkmale. Da der Rest dieses Dokuments nun ziemlich fachspezifisch sein wird, möchten wir vorher noch erklären, wie wir vorgehen. Die Überschrift jedes Abschnitts gibt das zu beachtende Merkmal an. Dann folgt die Erklärung, warum dieses Merkmal wichtig ist. Die Stichpunkte am Ende eines Abschnitts fassen zusammen, auf was konkret Sie achten sollten. Noch eine Anmerkung zur verwendeten Terminologie: Der Begriff Funktion bezieht sich entweder auf eine C-Function oder eine C++ Klassenmethode; Einheit bezieht sich auf eine C-Datei oder eine C++ Klasse. Und denken Sie immer daran, dass praktisch jedes Tool die in den Stichpunkten am Ende eines Abschnitts erwähnten Anforderungen irgendwie erfüllt. Die Unterschiede zeigen sich darin, wie automatisiert, wie bedienerfreundlich und wie vollständig die entsprechenden Abläufe sind. Parser und Codegenerator Es ist relativ einfach, einen Parser für C zu erstellen. Ein vollständiger Parser für C++ dagegen stellt eine echte Herausforderung dar. Stellen Sie sich bei der Tool-Evaluierung die Frage: Wie stabil und ausgereift ist die Parser-Technologie?. Einige Tool-Anbieter verwenden eine Technologie, die sie von einem Parsertechnologie-Unternehmen als Lizenz erworben haben; andere bevorzugen selbst entwickelte Parser. Überprüfen Sie die Stabilität von Parser und Codegenerator, indem Sie das Tool mit komplexen Code- Konstrukten füttern, die so ähnlich sind wie der bei Ihrem Projekt zum Einsatz kommende Code. Wird eine selbst entwickelte Parsertechnologie verwendet oder die eines anderen Unternehmens? Welche Sprachen werden unterstützt? Sind die Tool-Versionen für C und C++ identisch oder nicht? Ist die gesamte C++ Sprache implementiert oder gibt es Einschränkungen? Funktioniert das Tool auch mit unserem kompliziertestem Code? VectorCAST.com Seite 5

Der Testtreiber Der Testtreiber ist das Hauptprogramm, das den Test steuert. Hier ein einfaches Beispiel eines Treibers, der die Sinus-Funktion der Standard C-Bibliothek überprüft: #include <math.h #include <stdio.h int main () { } float local; local = sin (90.0); if (local == 1.0) printf ("My Test Passed!\n"); else printf ("My Test Failed!\n"); return 0; Schon mit einem solch simplen Beispiel lassen sich Unterschiede feststellen. Ein manueller Tool wird wahrscheinlich manuelles Eingeben und Debugging dieses kleinen Code-Schnipsels anfordern; ein halbautomatisiertes Tool bietet Ihnen vielleicht eine Art von Skriptsprache oder einfacher GUI an, mittels derer Sie den Stimuluswert für Sinus definieren können. Ein automatisiertes Tool verfügt über eine vollständige GUI für die Erstellung von Testfällen, eine integrierte Abdeckungsanalyse, einen integrierten Debugger und ein integriertes Target-Deployment. Haben Sie eigentlich gemerkt, dass der Treiber oben einen Fehler aufweist? Auflösung: In der Sinusfunktion wird der Eingangswinkel als Bogenmaß und nicht in Grad angegeben. Wird der Treiber automatisch generiert oder muss ich den Code schreiben? Kann ich Folgendes testen, ohne einen Code schreiben zu müssen? o Einen ganzen Wertebereich o Kombinatorik o Datenpartition (Äquivalenzsätze) o Listen mit Eingangsgrößen o Listen mit erwarteten Werten o Ausnahmen als erwartete Werte o Signalverarbeitung Kann ich eine Aufruffolge für verschiedene Verfahren im selben Test erstellen? VectorCAST.com Seite 6

Stubs bei abhängigen Funktionen Stubs für abhängige Funktionen sind erforderlich, wenn Sie die Werte kontrollieren möchten, die eine abhängige Funktion während eines Tests ausgibt. Stubbing ist ein sehr wichtiger Bestandteil von Integrations- und Modultests, weil damit der getestete Code von anderen Teilen Ihrer Anwendung isoliert werden und die Ausführung des jeweiligen Moduls oder Teilsystems leichter angestoßen werden kann. Bei vielen Tools muss der Testcode manuell generiert werden, damit ein Stub mehr als lediglich einen statischen Skalarwert ausgibt (return 0;) Werden Stubs automatisch generiert oder schreiben Sie Code dafür? Werden komplexe Ausgaben automatisch unterstützt (Strukturen, Kategorien)? Ist es möglich, dass bei jedem Stub-Aufruf ein anderer Wert ausgegeben wird? Merkt sich der Stub, wie oft er schon aufgerufen wurde? Merkt sich der Stub die Eingabeparameter mehrerer Aufrufe? Können Sie Aufrufe an die Standard C Bibliotheksfunktionen wie malloc stubben? Testdaten Es gibt zwei grundlegende Methoden, mittels derer halbautomatisierte und automatisierte Tools Testfälle implementieren: die datengesteuerte und die Einzeltestarchitektur. Bei einer datengesteuerten Architektur wird der Testrahmen für alle getesteten Einheiten erstellt und unterstützt alle in diesen Einheiten definierten Funktionen. Wenn ein Test durchgeführt werden soll, liefert das Tool einfach die Stimulusdaten über einen Datenstrom, wie eine Dateikennung, oder eine physikalische Schnittstelle, zum Beispiel eine UART. Bei einer Einzeltestarchitektur baut das Tool für jeden Test einen eigenen Testtreiber und kompiliert und verknüpft ihn in eine ausführbare Datei. Dazu zwei Anmerkungen: a) Durch die bei der Einzeltestmethode benötigte zusätzliche Codegenerierung sowie die Kompilierung und Verknüpfung dauert der Test länger; b) im Endeffekt erstellt man für jeden Testfall einen eigenen Testrahmen. VectorCAST.com Seite 7

Das bedeutet, dass ein Test-Tool bei einigen nominellen Tests vielleicht einwandfrei funktioniert, aber bei komplexeren Tests dann schon nicht mehr. Ist der Testrahmen datengesteuert? Wie lange dauert die Ausführung eines Testfalles (einschließlich Codegenerierung und Kompilierzeit)? Können die Testfälle auch außerhalb der Test-Tool-IDE bearbeitet werden? Wenn nicht, habe ich das Tool genügend ausprobiert und auch mit komplexen Code-Beispielen gefüttert, um festzustellen, welche Beschränkungen es aufweist? Automatisierte Generierung von Testdaten Einige automatisierte Tools erlauben bis zu einem gewissen Maße eine automatisierte Testfallerstellung. Es gibt diesbezüglich verschiedene Methoden, von denen nachfolgend einige beschrieben sind: MMM Min-Mid-Max Test Cases EC Equivalence Classes RV Random Values BP Basis Path Tests MMM-Tests betonen eine Funktion an den Grenzen der Eingabedatentypen. C und C++ Codes sind oft nicht gegen out-of-bound-eingaben geschützt. Der Techniker hat einen bestimmten Funktionsbereich im Kopf und unterlässt es, Vorkehrungen gegen Eingaben außerhalb dieses Bereichs zu treffen. EC-Tests erstellen Teilmengen (Segmente) für jeden Datentyp und wählen aus jeder Teilmenge einige Werte als Beispiele aus. Dies geschieht auf der Grundlage der Annahme, dass Werte aus demselben Segment die Anwendung auf ähnliche Weise aktivieren. Bei RV-Tests werden für jeden Parameter einer Funktion Kombinationen von Zufallswerten festgelegt. BP-Tests verwenden die Basis-Path-Analyse zur Überprüfung der eindeutigen Pfade während einer Prozedur. BP-Tests können automatisch einen hohen Grad an Verzweigungs-Abdeckung erzeugen. Im Zusammenhang mit einer automatischen Testfallgenerierung sollte man immer den Zweck des Tests im Auge behalten. Automatisierte Tests eignen sich gut dazu, die Stabilität eines Anwendungscodes zu überprüfen, nicht aber seine Korrektheit (auch wenn die Codeabdeckung der Tests recht hoch ist). Für die Feststellung der Korrektheit sind Tests erforderlich, die darauf basieren, was die Anwendung tun soll (Anforderungen), und nicht darauf, was sie wirklich tut (Code). VectorCAST.com Seite 8

Compiler-Integration Die Compiler-Integration ist aus zwei Gründen wichtig. Einmal können damit die Testrahmen-Komponenten automatisch kompiliert und verknüpft werden, ohne dass der Anwender erst herausfinden muss, welche Compiler-Optionen benötigt werden. Zum Zweiten kann das Test-Tool spezifische Spracherweiterungen des verwendeten Compilers berücksichtigen. Insbesondere bei Cross-Compilern kommen Erweiterungen, die nicht zu den C/C++ Sprachstandards gehören, sehr häufig vor. Einige Tools definieren diese Erweiterungen auf Null-Strings. Diese sehr grobe Vorgehensweise ist vor allem deshalb ungünstig, weil sie den Objektcode ändert, den der Compiler erstellt. Nehmen wir zum Beispiel das folgende globale Extern mit einem GCC-Attribut: extern int MyGlobal attribute ((aligned (16))); Wenn das Test-Tool bei der Definition des globalen Objekts MyGlobal das Attribut nicht verwaltet (beibehält), verhält sich der Code bei den Tests anders als später in der praktischen Anwendung des Tools, weil der Speicher nicht identisch abgeglichen wird. Kompiliert und verknüpft das Tool den Testrahmen automatisch? Berücksichtigt und implementiert das Tool Compiler-spezifische Spracherweiterungen? Welche Schnittstelle besteht zum Compiler (IDE, CL, etc.)? Hat das Tool eine Schnittstelle zum Import von Projekteinstellungen von Ihrer Entwicklungsumgebung oder müssen diese manuell importiert werden? Falls das Tool Projekteinstellungen importiert: Ist die Importfunktion universell einsetzbar oder auf bestimmte Compiler oder Compiler-Familien beschränkt? Ist das Tool mit Ihrem Debugger integriert, sodass Sie Tests von Fehlern bereinigen können? VectorCAST.com Seite 9

Unterstützung von Tests auf einem embedded Gerät In diesem Abschnitt verwenden wir den Begriff Tool-Chain und beziehen uns damit auf die gesamte Cross-Entwicklungsumgebung, einschließlich Cross-Compiler, Debug- Schnittstelle (Emulator), Zielboard und Realzeit-Betriebssystem (RTOS). Überprüfen Sie, ob das Test-Tool über stabile Zielintegrationen für Ihre Tool-Chain verfügt und was im Tool geändert werden muss, wenn Sie zu einer anderen Tool-Chain migrieren. Außerdem müssen Sie den Automatisierungsgrad und die Stabilität der Zielintegrierung in Erfahrung bringen. Wie schon mal erwähnt: Wenn ein Anbieter sagt Wir unterstützen alle Compiler und alle Ziele heißt das übersetzt Sie müssen selbst dafür sorgen, dass unser Tool in Ihrer Umgebung läuft. Im Idealfall ermöglicht das Test-Tool eine Testdurchführung per Tastendruck, bei der die gesamte Komplexität des Downloadens auf das Ziel und der Übertragung der Testergebnisse zurück zum Host in der Funktion Testdurchführung zusammengefasst ist und keine weiteren Aktionen des Anwenders mehr nötig sind. Eine zusätzliche Komplikation beim Testen eines eingebetteten Ziels ist die Hardwareverfügbarkeit. Oft wird die Hardware parallel mit der Software entwickelt oder es besteht eine nur beschränkte Hardwareverfügbarkeit. Es ist sehr wichtig, dass die Tests in der Anwenderumgebung gestartet werden und der Übergang auf die reale Hardware erst später erfolgt. Im Idealfall sind die Toolfunktionen hardwareunabhängig. Wird meine Tool-Chain unterstützt? Wenn nicht, kann sie unterstützt werden? Was bedeutet unterstützt? Kann ich Tests auf einem Host System einrichten und sie später für Zieltests anwenden? Wie wird der Testrahmen auf das Ziel heruntergeladen? Wie werden die Testergebnisse zurück an den Host übertragen? Welche Ziele, Cross-Compiler und RTOS werden standardmäßig unterstützt? Wer sorgt für die Unterstützung einer neuen Tool-Chain? Sind Bestandteil der Tool-Chain Integration frei konfigurierbar? VectorCAST.com Seite 10

Test Case Editor Während der interaktiven Arbeit mit einem Test-Tool sind Sie hauptsächlich im Test Case Editor aktiv. Wenn die Funktionen, die wir bisher in diesem Dokument erörtert haben, wirklich automatisiert sind, benötigt der Aufbau der Testumgebung und der Zielverbindung nur wenig Zeit. Wie am Anfang erwähnt, sollen Entwickler Zeit haben, um bessere und vollständigere Tests ausarbeiten zu können. Die wichtigste Frage, die Sie sich bei Ihrer Evaluierung stellen müssen, lautet, wie schwierig es ist, Testeingaben und Erwartungswerte für nicht triviale Konstrukte einzurichten. Skalarwerte lassen sich mit sämtlichen gängigen Tools problemlos erstellen. Aber bietet Ihr Tool eine einfache und intuitive Möglichkeit zum Aufbau einer Klasse? Gibt es eine abstrakte Möglichkeit, einen STL-Container zu erstellen; wie einen Vektor oder eine Abbildung? Das sind wichtige Aspekte, auf die Sie bei der Bewertung des Test Case Editor achten sollten. Es gibt Unterstützung und es gibt automatisierte Unterstützung. Berücksichtigen Sie dies, wenn Sie Konstrukte bewerten, die für Sie von Interesse sind. Werden mögliche Bereiche für Skalarwerte angezeigt? Werden Array-Größen angezeigt? Ist es einfach, Minimal- und Maximalwerte mit Tags statt Werten zu setzen? Dies ist wichtig, damit die Integrität des Tests erhalten bleibt, wenn ein Typ sich ändert. Werden spezielle Gleitkommazahlen unterstützt (z.b. NaN, +/- Infinity)? Sind kombinatorische Tests möglich (variieren Sie fünf Parameter eines Bereichs und lassen Sie das Tool alle Kombinationen dieser Werte ausführen)? Erkennt der Editor Bases, sodass Sie problemlos Werte auch in anderen Bases wie Hex, Octal und Binary eingeben können? Können Sie für erwartete Ergebnisse problemlos absolute Toleranzen (z. B. +/- 0.05) und relative Toleranzen (z. B.; +/- 1%) für Fließkommawerte eingeben? Können Testdaten ohne Umstände von anderen Quellen, wie Excel, importiert werden? VectorCAST.com Seite 11

Code-Abdeckung (Code Coverage) Die meisten halb-automatisierten und alle automatisierten Test-Tools haben eine Code-Abdeckung-Funktion, die anzeigt, welche Teile des Anwendungsprogramms ausgeführt werden. Einige Tools geben diese Informationen in Tabellenform aus, manche als Ablaufdiagramme und wieder andere in Form von kommentierten Programmlisten. Tabellenausgaben eignen sich gut als Zusammenfassung, aber wenn Sie eine möglichst hundertprozentige Code-Abdeckung haben wollen, ist eine kommentierte Programmliste die beste Option. In einer solchen Liste finden Sie die ursprüngliche Quellcode-Datei, in der abgedeckte, teilweise abgedeckte und nicht abgedeckte Konstrukte farblich unterschieden werden. Auf diese Weise erkennen Sie schnell, welche Testfälle zum Erzielen einer 100 %- Abdeckung noch erforderlich sind. Es ist auch wichtig, den Einfluss der Ausstattung (Instrumentation) zu verstehen. Der Ihrer Anwendung noch hinzugefügte Quellcode. Zwei Dinge sind dabei besonders zu beachten: Die Vergrößerung des Objektcodes und die verlängerte Ablaufzeit. Sie müssen auf jeden Fall wissen, ob Ihre Anwendung speicher- oder echtzeitbegrenzt (oder beides) ist. Dann können Sie entscheiden, welche Option für Ihre Anwendung am wichtigsten ist. Um welchen Wert vergrößert sich bei den einzelnen Ausstattungsarten der Code? Um welchen Wert verlängert sich bei den einzelnen Ausstattungsarten die Laufzeit? Lässt sich die Ausstattung in Ihr Make - oder Build -System integrieren? Wie werden die Abdeckungsergebnisse dem Anwender präsentiert? Als mit Anmerkungen versehene Listen mit einem grafischen Abdeckungs-Browser oder lediglich als Zahlentabellen? Wie werden die Abdeckungsinformationen vom Ziel abgerufen? Ist der Prozess flexibel? Können Daten im RAM zwischengespeichert werden? Werden Statement- und Branch- Coverage und MC/DC (Modified Condition / Decision Coverage) unterstützt? Können bei einem Durchlauf mehrere Abdeckungsarten erfasst werden? Können Abdeckungdaten von mehreren Testumgebungen genutzt werden (kann also zum Beispiel die bei einem Systemtest erfasste Abdeckung mit Abdeckungen von Integrations- und Modultests kombiniert werden)? Können Sie mithilfe der Abdeckungsdaten und ohne Einsatz eines Debuggers bei der Testdurchführung den Kontrollfluss durch Ihre Anwendung sehen? Können Sie einen Bericht anfordern, der die Abdeckungen sämtlicher Testläufe enthält? Kann das Test-Tool den Standard DO-178B einhalten ebenso wie anwendbare Richtlinien über Medizinprodukte? VectorCAST.com Seite 12

Regressionstests Mit einem Test-Tool sollten zwei grundlegende Ziele erreichbar sein. Das eine ist Zeitersparnis beim Testen (wenn Sie diesen Text bis hierher gelesen haben, stimmen Sie dem sicher zu!). Das zweite Ziel besteht darin, dass einmal erstellte Tests während der gesamten Lebensdauer der Anwendung immer wieder genutzt werden können. Zeit und Gelder, die für die Erstellung von Tests investiert wurden, sollten Tests zum Ergebnis haben, die auch dann noch ablauffähig sind, wenn sich die Anwendung im Laufe der Zeit verändert, und bei denen das Konfigurationsmanagement problemlos ist. Überprüfen Sie deshalb bei dem zu evaluierenden Test-Tool, welche spezifischen Elemente zu speichern sind, damit auch später die gleichen Tests immer wieder aufgerufen werden können, und wie die Wiederholungen der Testläufe gesteuert werden. Für welche Datei oder welche Dateien ist für die Regressionstests Konfigurationsmanagement erforderlich? Verfügt das Tool über eine vollständige und dokumentierte Befehlszeilenoberfläche (CLI)? Sind es Text- oder binäre Dateien? Dies wirkt sich auf Ihre Fähigkeit aus, mithilfe eines diff-programms Änderungen über längere Zeiträume auszuwerten. Ist für die vom Tool generierten Testrahmendateien Konfigurationsmanagement erforderlich? Gibt es eine Integration mit Konfigurationsmanagement-Tools? Richten Sie für eine Einheit einen Test ein. Nun ändern Sie den Namen eines Parameters und bauen die Testumgebung erneut auf. Wie lange dauert das? Ist der Vorgang kompliziert? Unterstützt das Tool Datenbanktechnologie und statistische Grafiken, damit man eine Trendanalyse der Testabläufe und Code-Abdeckung über einen längeren Zeitraum erstellen kann? Können Sie mehrere Ursprungscodes mit der gleichen Testfallreihe testen (automatisch)? Wird verteiltes Testen auf verschiedenen Rechnern unterstützt, um die Testgeschwindigkeit zu erhöhen? VectorCAST.com Seite 13

Reporting Die Reporting-Funktion ist bei den meisten Tools recht ähnlich. Die Mindestanforderung hier sind leicht verständliche Reports/Berichte, die die Eingaben, erwarteten Ergebnisse, tatsächlichen Ergebnisse und einen Vergleich der erwarteten und tatsächlichen Werte enthalten. Welche Ausgabeformate werden unterstützt? HTML? Text? CSV? XML? Ist es problemlos möglich, für eine Funktion sowohl einen High Level (projektweiten) Bericht als auch einen Detailbericht zu erhalten? Ist der Berichtinhalt frei konfigurierbar? Ist das Berichtformat frei konfigurierbar? Integration mit anderen Tools Unabhängig von ihrer Qualität oder Nützlichkeit müssen alle Tools auf jeden Fall in einer Multivendor-Umgebung ablauffähig sein. Es kam schon öfter vor, dass größere Unternehmen kleinere aufgekauft haben, um das Tool auf den Markt bringen zu können, welches jedem alles bietet. Es stellte sich dann aber meist heraus, dass bei diesen Mega- Toolsuites das Ganze viel weniger ist als die Summe der Teile. Anscheinend fassen solche Unternehmen einfach vier bis fünf coole kleine Werkzeuge zu einem mehr oder weniger unbrauchbaren großen Tool zusammen. Abgesehen von der Integration mit der Entwicklungs-Tool-Chain, die wir bereits erörtert haben, sind die nützlichsten Integrationen für Test-Tools die mit Tools für statische Analyse, Konfigurationsmanagement- und Anforderungsmanagement-Tools. Jeder möchte seine Testwerkzeuge einer Konfigurationssteuerung unterstellen, um sie wieder nutzen zu können, und die meisten Anwender möchten ihre Anforderungen in den Testfällen zurückverfolgen. Mit welchen Tools lässt sich Ihr Tool auf unkomplizierte Weise integrieren, und kann der Endanwender Integrationen hinzufügen? Wünschenswerte Merkmale eines Testwerkzeugs Damit wäre die Analyse des Testwerkzeugs beendet. Auf den vorherigen Seiten haben wir Funktionen beschrieben, die jedes automatisierte Test-Tool umfassen muss. In den nächsten Abschnitten führen wir nun Funktionen und Merkmale an, die wünschenswert wären, und erklären auch, warum sie wichtig sind. Es hängt natürlich auch sehr von Ihrem Projekt ab, ob Sie für diese Funktionen wirklich Verwendung haben. VectorCAST.com Seite 14

Integrationstests / Test mehrerer Module Integrationstests sind eine Erweiterung der Modultests. Sie dienen dazu, Schnittstellen zwischen Modulen zu überprüfen. Der Anwender muss dafür Module kombinieren, die zusammen einen Funktionsablauf bilden. Von vielen Test-Tools wird behauptet, dass sie Integrationstests unterstützen, indem sie den Objektcode für reale Module mit dem Testrahmen verknüpfen. Bei dieser Methode werden mehrere Dateien innerhalb des ausführbaren Testrahmens erstellt, jedoch können die Funktionen in diesen zusätzlichen Einheiten nicht aktiviert werden. Im Idealfall müsste es möglich sein, in einem Testfall jede Funktion in jedem Modul zu aktivieren, und zwar in beliebiger Reihenfolge. Bei den Tests der Schnittstellen zwischen Modulen werden im Allgemeinen viele versteckte Annahmen und Fehler in der Applikation aufgedeckt. Integrationstests können ein guter erster Schritt für Projekte sein, bei denen es noch keine Modultests gab. Kann ich mehrere Module in die Testumgebung einfügen? Kann ich komplexe Testszenarien für diese Klassen erstellen, wobei innerhalb eines Testfalls ein Funktionsablauf in mehreren Modulen aktiviert wird? Kann ich Code-Abdeckungs-Messdaten für mehrere Module erfassen? Dynamisches Stubben Dynamisches Stubben bedeutet, dass einzelne Funktion-Stubs dynamisch deaktiviert und aktiviert werden. Auf diese Weise kann ein Test für eine einzelne Funktion erstellt werden und alle anderen Funktionen sind stubbed (selbst wenn sie zum selben Modul wie die getestete Funktion gehören). Bei sehr komplizierten Codes ist dies ein tolles Merkmal, das die Implementierung eines Tests sehr erleichtert. Können Stubs auf Funktionsebene oder nur auf Modulebene ausgewählt werden? Können Funktion-Stubs für jeden Testfall einzeln ein- und ausgeschaltet werden? Werden die Funktion-Stubs automatisch generiert? (siehe den vorherigen Abschnitt) VectorCAST.com Seite 15

Thread-Tests auf Anwendungs- und Bibliotheksebene (Systemtests) Eine der Herausforderungen bei Systemtests besteht darin, dass der an die vollintegrierte Applikation angelegte Teststimulus vom Anwender das Drücken von Tasten, Kippen von Schaltern oder Eingaben an einer Konsole verlangt. Bei einer eingebetteten Anwendung sind die Eingaben noch schwieriger zu steuern. Nehmen wir an, Sie könnten Ihre vollintegrierte Applikation auf der Funktionsebene stimulieren, so ähnlich wie bei einem Integrationstest. Dies würde Ihnen erlauben, komplexe Testszenarien aufzubauen, die nur von der API der Anwendung abhängen. Einige der moderneren Tools erlauben diese Art von Tests, deren weiterer Vorzug darin besteht, dass für das testen der Anwendung der Quellcode nicht erforderlich ist. Es genügt die Definition der API (oder allgemein der Headerdateien). Tester haben hiermit eine automatisierte und skriptfähige Systemtestmethode. Agile Prozesse und testgetriebene Entwicklung (TDD) Testgetriebene Entwicklung verspricht, Testfälle früher als jemals zuvor in den Entwicklungsprozess zu integrieren. Anstatt zuerst Anwendungscode zu schreiben und erst nachträglich die Modultests, führen Sie die Testfallentwicklung durch, noch bevor der Code geschrieben wird. Dies ist ein neuer und bei Entwicklern zunehmend beliebter Ansatz nach dem Motto: Teste zuerst und teste oft. Ihr automatisiertes Tool sollte diese Testmethode unterstützen, wenn Sie mit agiler Entwicklung arbeiten möchten. Bidirektionale Integration mit Anforderungs-Tools Wenn Sie Anforderungen mit Testfällen verknüpfen möchten, ist es wünschenswert, dass das Test-Tool mit einem Anforderungsmanagement-Tool verbunden wird. Sie müssten in diesem Fall eine bidirektionale Schnittstelle haben, damit bei mit Anforderungen markierten Testfällen die Testfallinformationen wie Testname und Ergebnisse (Pass / Fail) zurück zu Ihrer Anforderungsmanagement-Datenbank fließen können. Auf diese Weise können Sie einen Sinn für Vollständigkeit bezüglich Ihrer Anforderungstests entwickeln. VectorCAST.com Seite 16

Zulassung Wenn Sie in einem reglementierten Umfeld tätig sind, also zum Beispiel in der Verkehrsluftfahrt oder bei der Herstellung von Medizinprodukten der Klasse III, sind Sie verpflichtet, die für den Aufbau und die Tests Ihrer Anwendung verwendeten Entwicklungswerkzeuge zu qualifizieren. Für eine solche Qualifikationsprozedur zur Zulassung sind Dokumente über den Verwendungszweck und die Einsatzbedingungen des Tools erforderlich sowie Tests, die die Einhaltung der Anforderungen nachweisen. Im Idealfall stellt Ihnen der Verkäufer diese Materialien zur Verfügung, zusammen mit einer Liste der Kunden, die die Zulassungsdaten für Ihre Branche schon verwendet haben. Stellt der Tool-Verkäufer Zulassungsdokumente bereit, die genau auf Ihr Einsatzumfeld und Ihre Tool-Chain zugeschnitten sind? Welche Projekte haben diese Materialien bereits erfolgreich angewendet? Wie sind die Materialien lizenziert? Wie wurden die Materialien für ein bestimmtes Projekt angepasst und genehmigt? Falls es sich um ein FAA-Projekt (FAA: US-amerikanische Luftfahrtaufsichtsbehörde) handelt, wurden die Qualifikationsmaterialien erfolgreich für die DO-178B Level A Zertifizierung herangezogen? Falls es sich um ein FDA-Projekt (FDA: US-amerikanische Lebensmittel- und Arzneimittelzulassungsbehörde) handelt, wurden die Tools für den vorgesehenen Verwendungszweck zertifiziert? VectorCAST.com Seite 17

Zusammenfassung Dieses White Paper hat Ihnen hoffentlich nützliche Informationen gegeben, mit deren Hilfe Sie sich im Angebotsdschungel der Testwerkzeug-Anbieter besser zurechtfinden. Die relative Bedeutung jedes der angesprochenen Punkte hängt natürlich vom jeweiligen Projekt ab. Hier noch einige abschließende Empfehlungen: Evaluieren Sie die von Ihnen in Erwägung gezogenen Tools mit einem Code, der der Komplexität des Codes in Ihrer Anwendung ungefähr entspricht. Und evaluieren Sie mit der Tool-Chain, die Sie auch für Ihr Projekt verwenden. Sprechen Sie mit langjährigen Kunden des Anbieters und stellen Sie ihnen einige der in diesem White Paper aufgeführten Fragen. Erkundigen Sie sich nach dem technischen Support-Team für die Test-Tools. Und stellen Sie einige Ihre Fragen gleich mal direkt an die Supportmitarbeiter, anstatt an den Verkäufer. Und vergessen Sie nicht, dass fast jedes Werkzeug für den Test von Software in eingebetteten Systemen die Anforderungen, die wir in der Rubrik am Ende jedes Abschnitts aufgeführt haben, irgendwie erfüllt. Ihre Aufgabe ist es herausfinden, in welchem Maße: Wie hoch ist der Automatisierungsgrad? Wie bedienerfreundlich ist das Tool? wie vollständig werden Ihre Anforderungen unterstützt? Über Vector Software Vector Software, Inc., ist der führende unabhängige Anbieter von automatisierten Testwerkzeugen für Entwickler von sicherheitskritischen eingebetteten Applikationen. Unsere Produktfamilie VectorCAST automatisiert und standardisiert die komplexen Aufgaben in Zusammenhang mit Modul-, Integrations- und Systemtests. VectorCAST Produkte unterstützen die Programmiersprachen C, C++ und Ada. Vector Software, Inc. 1351 South County Trail, Suite 310 East Greenwich, RI 02818 USA Telefon: 001.401.398.7185 Fax: 001.401.398.7186 E-Mail: info@vectorcast.com www. vectorcast.com Vector Software Vorster Strasse 80 47906 Kempen Germany Telefon: +49 2152 8088808 Fax: +49 2152 8088888 E-Mail: info@vectorcast.com www. vectorcast.com VectorCAST.com Seite 18