SBTWAN Benutzer-Dokumentation |
SBTWAN ermittelt die Überdeckung durch Instrumentierung des Quellcodes, d.h. das zu testende Programm muss als kompilierbarer Quellcode vorliegen.
SBTWAN 1.0 arbeitet ausschließlich auf Java-Programmen, ist aber dafür ausgelegt, alle gängigen imperativen und objektorientierten Programmiersprachen unterstützen zu können. Die dazu notwendigen Maßnahmen kann man in den Entwicklerdokumentation nachlesen.
Es gibt drei grundlegende Arten SBTWAN im Programmtest einzusetzen: der manuelle Test, zusammen mit einem externen Testsystem oder integriert in ein automatisches Testsystem. Im manuellen Programmtest arbeitet man lediglich mit SBTWAN und dem zu testenden Programm. Die Arbeit mit einem externen Testsystem ist davon kaum verschieden, lediglich die Art des Testen wird davon betroffen. Um SBTWAN im automatischen Testsystem einzubinden, kann auf das automatische Testmodul SBTWAN-ATM zurückgegriffen werden, welches als Bibliothek eingebunden oder über Kommandozeilenparameter aufgerufen die Kernfunktionen von SBTWAN ausführen kann und auf die Verwendung der graphischen Benutzeroberfläche verzichtet.
In der Vorbereitungsphase für den Programmtest bestehen die grundlegenden Arbeitsschritte bestehen darin, den Quellcode einzulesen, die Art der Instrumentierung zu bestimmen und die Quelldateien zu instrumentieren. Im manuellen Programmtest und in der Zusammenarbeit mit einem externen Testsystem geschieht dies über die graphische Benutzeroberfläche. Nun liegen die instrumentierten Quelldateien vor und müssen kompiliert werden. Liegt eine entsprechende Batchdatei oder Ant-Skript vor, lässt sich dieser Prozess auch aus SBTWAN heraus starten.
Der eigentliche Programmtest kann nun ausgeführt werden, wobei dies entweder ein Testsystem übernimmt oder man einen manuellen Test am Programm durchführt. Der Programmtest produziert eine Logdatei, welche die nötigen Informationen zur Berechnung der Überdeckungsmaße enthält.
In der Auswertungsphase wird der originale Quellcode wiederhergestellt, die Logdateien eingelesen und die verschiedenen Überdeckungsmaße berechnet. Die Ergebnisse lassen sich dann sowohl in SBTWAN auf verschiedene Arten visuell auswerten, als auch in einen HTML-Report exportieren.
SBTWAN im Testbetrieb |
Aufgaben |
Manueller Programmtest |
Mit externem Testsystem (ATOSj) |
Im automatischen Testbetrieb |
Vorbereitungsphase |
Einlesen und Parsen des Quellcodes |
SBTWAN |
SBTWAN |
SBTWAN-ATM |
Konfiguration der Instrumentierung |
SBTWAN |
SBTWAN |
Konfigurationsdatei |
|
Instrumentierung des Quellcodes |
SBTWAN |
SBTWAN |
SBTWAN-ATM |
|
Testphase |
Kompilieren des Quellcodes |
Extern / aus SBTWAN per Skript |
Extern / aus SBTWAN per Skript |
Extern |
Programmtest |
Manuell (Start per Skript aus SBTWAN) |
Extern |
Extern |
|
Auswertungsphase |
Restauration des originalen Quellcodes |
SBTWAN |
SBTWAN |
SBTWAN-ATM |
Einlesen der Logdateien und Berechnung der Überdeckungsmaße |
SBTWAN |
SBTWAN |
SBTWAN-ATM |
|
Visualisierung der Ergebnisse |
SBTWAN |
SBTWAN |
Keine / SBTWAN (nach den Tests) |
|
Reporterstellung |
SBTWAN |
SBTWAN |
SBTWAN-ATM |
SBTWAN wurde als eine Standalone-Eclipse-RCP-Application entwickelt und stellt außer einer aktuellen Java Installation ab Java 5.0 keine weiteren Anforderungen an das System. Ein einfaches Aufrufen der sbtwan.exe startet das Programm, das Programmverzeichnis dient dabei als Speicherplatz für alle Projektdateien, lediglich die Logdateien werden im Basisverzeichnis des zu testenden Programmes gespeichert und müssen von dort importiert werden.
Möchte man das Testprogramm automatisch per Antskript aus SBTWAN heraus kompilieren lassen, muss man im Menü Help->Preferences->General die entsprechende Ant-Datei einbinden. Im selben Menü lässt sich einstellen, ob SBTWAN seine Aktionen in einer Datei protokollieren soll und ob diese zu jedem neuen Start des Programmes überschrieben werden soll.
Neben der obligatorischen Menüleiste und der Toolbar für den schnellen Zugriff auf die gebräuchlichsten Aktionen besteht die Benutzeroberfläche aus verschiedenen Views, die in drei Bereichen im Programm per Tabs einsehbar sind. Im linken, oberen Bereich befindet sich die View mit der Übersicht über das Projekt. Darunter sind zwei Views angeordnet, die zum einen die Testfälle und zum anderen die Instrumentationschemata des Projektes auflisten. Den größten Teil des Fenster nimmt der rechte Bereich ein, dessen verschiedene Views umfangreiche Informationen zum Quellcode, Kontrollflussgraphen, Überdeckungs- und Metrikauswertungen sowie den Testfällen liefert. Die Views sind miteinander verknüpft, so dass z.B. die Auswahl einer Datei im ProjectView den entsprechenden Quellcode im SourceView anzeigt. Für Eingaben bei größere Aktionen wie Projekterstellungen werden Wizards oder Dialoge geöffnet.
4.1.1 Das Project-Menü
![]()
|
|
- Öffnet den Wizard für die Projekterstellung. Ist schon ein Projekt geöffnet, dann wird dieses geschlossen. |
|
- Öffnet ein existierendes Projekt. |
|
|
- Speichert das aktuelle Projekt in einer Datei gleichen Namens mit der Endung ''.project''. |
|
|
- Schließt das aktuelle Projekt. |
|
|
- Stellt für ein gegebenes Projekt den Originalzustand der Quellen wieder her. |
|
|
- Beendet SBTWAN. |
|
![]()
|
||
4.1.2 Das Task-Menü |
||
![]()
|
|
- Öffnet den Dialog zur Erstellung eines neuen Instrumentationsschema. |
|
- Beginnt einen neuen Testlauf. Das beinhaltet: Instrumentieren, Kompilieren und Starten des Testprogrammes, soweit dies über die bereitgestellten Skripte möglich ist. |
|
|
- Beendet den aktuellen Testlauf. Die originalen Quellen werden wiederhergestellt und die Logdateien eingelesen. Liegt das entsprechende Skript vor, werden die originalen Quellen neu kompiliert. |
|
|
- Erstellt einen Überdeckungsreport anhand der eingelesenen Testlogs. |
|
|
- Führt das Kompilationsskript aus. |
|
|
- Startet das Testprojekt. |
|
|
- Stellt die originalen Quelldateien wieder her. |
|
![]()
|
||
|
- Liest die Logdateien zum aktuellen Projekt ein und berechnet die Überdeckungsmaße. |
|
|
- Wenn aktiviert, werden die Überdeckungsinformationen in der Quellcodeansicht und der Überdeckungsansicht farbig dargestellt. |
|
4.1.3 Das Preference-Menü |
||
![]()
|
|
- Die Präferenzen für SBTWAN. |
|
- Das Menü für projektspezifische Einstellungen. |
|
4.1.4 Das Help-Menü |
||
![]()
|
|
- Öffnet diese Benutzer-Dokumentation im System-Browser. |
|
- Öffnet den Dialog mit den Programminformation. |
|
|
Im ProjectView werden die Projektdateien und ihre
untergeordneten Strukturen, wie Klassen und Methoden als ein Baum
aufgelistet. Die obersten Knoten stehen für die
Quellcodedateien, die man bei der Projekterstellung importert hat.
Als Kinder werden dann hierarchisch geordnet die Toplevel-Klassen
und -Methoden und ihre jeweiligen inneren Klassen und Methoden bis
zu einer beliebigen Schachtelungstiefe aufgeführt. Mittels
der beiden Buttons
Wird im IschemeView ein IScheme ausgewählt, so färbt sich das Icon zu jeder Struktur analog zum entsprechenden Instrumentationslevel.
Wenn beim Parsen der Datei Instrumentationsanweisungen
festgestellt werden, wie z.B. während des Testlaufes auf
instrumentierten Quellen, so ändert sich das Icon zu
|
![]() Abbildung 1: Die ProjectView
|
Die TestView besteht aus der Liste aller eingelesener Testlogs des Projektes. In Klammern folgt die Angabe über das verwendete Instrumentierungsschema. Werden Testlogs ausgewählt, so wird automatisch die
Überdeckungsinformation in den anderen Views aktualisiert.
Zum Ändern der kompletten Auswahl können die Buttons
|
![]() Abbildung 2: Die TestView
|
In der IschemeView befinden sich lediglich die zum Projekt gehörigen Instrumentationsschemata, kurz Ischeme genannt. Zu jedes Projekt werden automatisch drei Ischemes erstellt, die jeweils das gesamte Projekt nach Level 1, 2 bzw. 3 instrumentieren. Wird ein Ischeme ausgewählt, so ändern sich die Icons im ProjectView, um die entsprechende Instrumentierung der Dateien, Klassen und Methoden wiederzuspiegeln. |
![]() Abbildung 3: Die ISchemeView
|
In der SourceView wird der Quellcode der ausgewählten Datei aus der ProjektView angezeigt. Werden Klassen oder Methoden ausgewählt, so werden nur die entsprechenden Quellcodezeilen angezeigt, die zu dieser Einheit gehören.
Ist die Überdeckungsanzeige
in der Toolbar aktiviert, wird die Überdeckung des Quelltextes
durch die ausgewählten Testlogs im TestView farbig dargestellt.
Grüne Quellcodezeilen würden durch die Tests abgedeckt,
rote wurden im Test nicht berührt. Die entsprechenden Farben
sowie das Syntaxhighlighting können im Preference-Menü
eingestellt werden.
Während die SourceView nur die Zeilenüberdeckung anzeigen kann und primär für den Überblick über die Quellcodeüberdeckung gedacht ist, hat die CFGView die Aufgabe, detailierte Informationen zur Überdeckung der Quellcodestrukturen zu vermitteln. Wird im ProjectView eine Methode ausgewählt, so zeigt der obere Teil derr CFGView den entsprechenden Kontrollflussgraphen an. Für die Zuordnung der Knoten zu den entsprechendne Quelllcodeteilen genügt das Anklicken eines Knotens, woraufhin im unteren Teil der CFGView der Quellcode auf den entsprechende Quellcodeabschnitt fokussiert und die korrospondierende Zeile gelb hinterlegt wird.
Werden zusätzlich Testlogs im TestView angewählt, so ändert sich die Farbe der Knoten und Kanten entsprechend der Überdeckung durch die Testfallmenge. Grüne Knoten und Kanten wurden überdeckt, rote hingegen nicht. Zur besseren Visualiserung der Knoten, die mehrere Ausgänge haben, von denen mindestens einer aber nicht alle überdeckt wurden – wo also die Ursache der fehlenden Überdeckung von Codeabschnitten zu suchen wäre – werden diese gelb gefärbt. Dies lässt sich aber in den Präferenzen genauso wie alle anderen Farben und auch der Linienstil sowie -dicke konfigurieren.
Zusätzliche Informationen erhält man, wenn man den Mauszeiger kurz über einen Knoten hält. Der sich öffnende Tooltip gibt zu jedem Knoten die Anzahl der Berührungen durch die Testfallmenge an sowie seine projektinterne ID und die Zeilennummer, in welcher er zu finden ist. Für verzweigende Knoten wird angegeben, wie oft die verschiedenen Ausgänge genommen wurden.
Informationen zur Bedingungsüberdeckung kann man über zwei Wege erhalten. Zum einen befinden sich an Knoten, die eine nicht-triviale Bedingung enthalten an der rechten Seiten vier kleine Kästchen, die für die verschiedenen Bedingungsüberdeckungsgrade stehen. Von oben nach unten sind dies die einfache, die minimal mehrfache, die MC/DC sowie die mehrfache Bedingungsüberdeckung. Die Färbung zeigt den Grad der Überdeckung von grün gleich 100% bis dunkelrot gleich 0% an. Die Schwellwerte und Farben können in den Präferenzen festgelegt werden.
Für genaue Informationen über die Bedingungsüberdeckung kann durch Doppelklicken auf entsprechenden Knoten eine Dialogbox geöffnet werden, in welcher die logische Struktur der Bedingung und alle Belegungen ihrer Atome tabellarisch aufgelistet wird. In der ersten Spalte befindet sich der Wahrheitsvector für die gesamte Bedingung, wie er aus der Testlogdatei eingelesen wurde. Die zweite Spalte enthält die Auswertung für die Gesamtbedingung, die darauffolgenden Spalten die Auswertung für alle atomaren Teilbedingungen.
Die zentrale Auswertung der Überdeckung
des Projektes erfolgt mittels der CoverageView. Hier werden analog
zur ProjectView sämtliche Strukturen des Projektes hierarchisch
in einem Baum aufgelistet und für jede einzelne die prozentuale
Erfüllung der verschiedenen Überdeckungsmaße
angegeben. Wenn die Überdeckungsanzeige
in der Toolbar aktiviert ist, werden die Maßzahlen zur besseren
Übersichtlichkeit farbig hinterlegt, wobei die einzelnen Farben
und Schranken in den Preferences definiert werden können.
Die einzelnen Überdeckungsmaße sind: Function Entry Exit Coverage (FEEC), Anweisungsüberdeckung (C0), Zweigüberdeckung (C1), Bedingungsüberdeckung (C2), Minimal mehrfache Bedingungsüberdeckung (MMDC), Multiple Condition/Decision Coverage (MCDC), Mehrfache Bedingungsüberdeckung (C3) und Boundary interior path coverage (BI). Steht statt einer Prozentangabe ein Strich in der View, so lässt sich das entsprechende Maß nicht auf die diese Struktur anwenden, weil z.B. keine Bedingungen oder Anweisungen in der Klasse enthalten sind.
Ein Nebenprodukt der syntaktischen Analyse des Quellcodes beim Parsen sind die statischen Metriken. In der MetricsView können diese direkt nach dem Einlesen des Projektes ausgewertet werden. Die View besteht analog zur CoverageView aus dem Projektbaum und einer Zuordnung folgender Maßzahlen zu den einzelnen Projekteinheiten: Zyklomatische Komplexität, Essentielle Komplexität, Lines of code (LOC), Anzahl der Anweisungen, Anzahl der Bedingungen, Anzahl der Atome in allen Bedingungen und Anzahl aller atomarer und komplexer Bedingungen.
Ein
neues Projekt beginnt man über den Menüpunkt Project->New
Projet oder durch Anwählen des entsprechenden Buttons
in der Toolleiste, woraufhin man durch einen zweiseitegen Wizard das
neue Projekt konfigurieren kann.
Auf der ersten Seite wird