1 Einführung
2 Überblick
3 Installation und Programmstart
4 Benutzeroberfläche und Funktionalität
4.1 Menüs und Toolbar
4.1.1 Menü Project
4.1.2 Menü Tasks
4.1.3 Menü Configuration
4.1.4 Menü Help
4.2 Views
4.2.1 View Project
4.2.2 View Testlogs
4.2.3 View IScheme
4.2.4 View Source
4.2.5 View CFG
4.2.6 View Coverage
4.2.7 View Metrics
4.3 Präferenzen
4.3.1 Präferenz View CFG
4.3.2 Präferenz View Coverage
4.3.1 Präferenz General
4.3.1 Präferenz Report
4.3.1 Präferenz View Source
4.4 Projekt löschen
5 Dateien
6 Tutorien
7 Anhang

4 Benutzeroberfläche und Funktionalität

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 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 Instrumentationsschemata des Projektes auflisten. Den größten Teil des Fensters nimmt der rechte Bereich ein, dessen verschiedene Views umfangreiche Informationen zum Quellcode, zu den Kontrollflussgraphen, Überdeckungs- und Metrikauswertungen liefert.

Die Views sind miteinander verknüpft, so dass z.B. die Auswahl einer Datei in der ProjectView den entsprechenden Quellcode im SourceView anzeigt. Die Auswahl eines Tests in der TestView aktualisiert daraufhin die Überdeckungsmaße für das gesamte Projekt und die Darstellung der Überdeckung für die ausgewählte Datei. Für Eingaben bei größeren Aktionen wie Projekterstellungen werden Wizards oder Dialoge geöffnet.

Am unteren Fensterrand befindet sich schließlich die Statuszeile, die zum einen Informationen über den Zustand der Quelldateien liefert und zum anderen anzeigt, wie der Status des durch SOTA geparsten und daraufhin angezeigten Quellcodes ist. Der originale Zustand wird dabei als CLEAN und der instrumentierte als DIRTY gekennzeichnet.

Abb.: Hauptfenster von SOTA

4.1 Menüs und Toolbar

4.1.1 Menü Project

Abb.: Menü Project

New Project

Der Menüpunkt New Project öffnet den zweiseitigen Wizard für die Projekterstellung. Auf der ersten Seite muss ein Name für das Projekt angegeben werden, unter welchem SOTA dieses verwaltet, sowie das Projektverzeichnis und das Ausführungsverzeichnis. Aus dem Projektnamen generiert SOTA die Datei <projektname>.project und legt diese im SOTA-Verzeichnis ab.

Das Projektverzeichnis ist dabei das Basisverzeichnis des Testprogrammes (entspricht bei Eclipse-Projekten "../workspace/projektname"). Von hier ausgehend werden die Quellcodes importiert und in dieses Verzeichnis wird auch der Testreport geschrieben. Das Ausführungsverzeichnis ist das Verzeichnis, aus welchem das Testprogramm beim Test gestartet wird. Dies entspricht in den meisten Fällen dem Basisverzeichnis des Testprogrammes, jedoch bei Eclipse-RCP-Projekten dem Eclipse-Basisverzeichnis "..\eclipse\". In dem Ausführungsverzeichnis wird die ASCLogger.ini erstellt, die beim Test vom ASCLogger eingelesen werden muss und von hier werden auch nach dem Test die Testlogs eingelesen.

Die Wahl der verwendeten Programmiersprache ist obligatorisch, in der aktuellen Version aber auf Java beschränkt. Abschließend können noch eine Ant-Buildfile zum Kompilieren und eine Batchdatei zum Starten des Testprojektes eingebunden werden.

Auf der zweiten Wizardseite werden die Quelldateien des Projektes eingebunden, die im Test berücksichtigt werden. Dazu können Verzeichnisse ausgewählt werden, wodurch alle Quelldateien aus den Unterverzeichnissen importiert werden, oder aber nur einzelne Dateien.

Nach dem Beenden des Wizards wird das Projekt erstellt und die ausgewählten Quelldateien werden geladen.

Abb.: erste Wizardseite
Abb.: zweite Wizardseite


Open Project

Mit dem Menüpunkt Open Project lässt sich ein zuvor erstelltes Projekt öffnen. Dazu wird ein Standarddialog zum Laden einer Datei im Basisverzeichnis von SOTA geöffnet, in welchem man das entsprechende Projekt auswählen kann.
Nach der Bestätigung durch OK wird das Projekt in SOTA geöffnet und die dem Projekt zugehörigen Quelldateien werden geladen.

Abb.: Dialog Open Project

Save Project

Das Speichern des Projektes über den Menüpunkt Save Project führt beim erstmaligen Ausführen zur Erstellung der Projektdatei im Basisverzeichnis von SOTA, dessen Name identisch mit dem eingegebenen Projektnamen ist und auf ''project'' endet. Diese Datei enthält die Projektdaten und auch alle erstellten InstrumentationsSchemata. Existiert diese Datei schon, wird sie mit den aktuellen Daten überschrieben.

Close Project

Über den Menüpunkt Close Project lässt sich das aktuelle Projekt schließen. Sota befindet sich daraufhin wieder im Startzustand.

Recover Project

Der Menüpunkt Recover Project hat die Aufgabe, korrupte Projekte wiederherzustellen. Dazu wird analog zum Menüpunkt Open Project ein Dialog geöffnet, womit man ein Projekt auswählen kann. Für dieses Projekt werden alle Quelldateien wieder in ihren Originalzustand zurückversetzt und daraufhin das Projekt geöffnet.

Exit

Über den Menüpunkt Exit wird SOTA beendet.

4.1.2 Menü Tasks

Abb.: Menü Tasks

New InstrumentationScheme

Der Menüpunkt New InstrumentationScheme öffnet einen Dialog, der das Erstellen eines neuen Instrumentationsschemas (kurz: IScheme) für das aktuelle Projekt ermöglicht. Ein IScheme entspricht einer Instrumentierungsvorgabe für alle Quelldateien des Projekts, die jeweils verschiedene Grade annehmen kann. Der Sinn dieser Konfigurationsmöglichkeit für die Instrumentierung besteht darin, dem Nutzer zu erlauben, den abhängig vom Testfall mitunter sehr hoch ausfallenden Speicherbedarf der Logdateien sinnvoll zu begrenzen.

Abb.: Dialog New IScheme

Für die Erstellung eines ISchemes muss im Dialog ein Name angegeben werden, unter dem dieses im Projekt verwaltet wird. Die Angabe einer Beschreibung ist optional. Die sich darunter befindliche Projektansicht zeigt hierarchisch alle Strukturen des aktuellen Projektes in Baumform, beginnend von Dateien über Klassen zu den einzelnen Funktionen. Jeder der Strukturen kann ein Level der Instrumentierung von 0 bis 3 zugewiesen werden, indem man nach der Auswahl der Struktur den entsprechenden Button für das Level drückt, wodurch diese Belegung auch farblich gekennzeichnet wird. Dabei gibt das Zuweisen eines Instrumentierungslevels für eine Struktur dieses auch an alle untergeordneten Strukturen weiter. Die einzelnen Level haben folgende Auswirkung:

Das empfohlene Instrumentationslevel für den Programmtest ist Level 2, welches die Ermittlung aller Überdeckungsmaße erlaubt. Im Bedarfsfall kann man dieses auf ein niedrigeres Level reduzieren, um Kapazitäten zu sparen. Die Verwendung von Level 3 ist dort sinnvoll, wo man bei nicht korrekt beendenden Programmen bzw. Funktionen die genaue Abbruchstelle bzw. den Ort des Ausnahmefalles ermitteln möchte.

Nach dem Bestätigen des Dialoges werden das Instrumentationsschema mitsamt der ausgewählten Einstellung in der projektspezifischen .ischeme-Datei gesichert und steht ab sofort für den Programmtest zur Verfügung.


Start Test / Restart Test

Abb.: Dialog Start Test

Der Programmtest wird in SOTA durch den Menüpunkt Start Test eingeleitet, welcher eine Dialogbox zum Konfigurieren des Tests öffnet. Der eingegebene Name für den Test dient gleichzeitig als Name für das dann zu erstellene Testlog, d.h. bei der Wahl des Namens muss auf die Beschränkungen von Dateinamen für das jeweilige Betriebssystem Rücksicht genommen werden. Eine Beschreibung des Tests kann zusätzlich hinzugefügt werden, ist jedoch nicht zwingend.

Als nächstes ist es notwendig, die Instrumentierung des Projektes zu konfigurieren. Dazu stehen neben den selbsterstellten ISchemes die drei elementaren ISchemes zur Verfügung, die das gesamte Projekt nach Level 1, Level 2 sowie Level 3 instrumentieren. Die hierarchische Projektübersicht zeigt die konkrete Instrumentierung der einzelnen Projektstrukturen für das gewählte IScheme. Mit den beiden Buttons Expand All sowie Collapse All lässt sich die Baumstruktur komplett auf- bzw. zuklappen.

Sobald ein Name für den Test eingegeben und ein IScheme ausgewählt wurde, kann der Programmtest durch bestätigen des Dialoges gestartet werden. Die Informationen für die Loggingkomponente wird in die Datei ''ASCLogger.ini'' in den Ausführungspfad des Projektes geschrieben, es folgt die Sicherung der originalen Quelldatein durch eine Änderung der Dateiendungen in ''.backup'' und die Instrumentierung des Quellcodes. Daraufhin wird das Projekt erneut geparst und der instrumentierte Quellcode kann in der SourceView betrachtet werden. Der Quelltext liegt nun in instrumentierter Fassung vor und kann kompiliert und z.B. mit einem externen Testsystem systematisch getestet werden.

Drei weitere Optionen sind am unteren Rand durch Checkboxen auswählbar. Rerun configuration führt dazu, dass lediglich der Name des Tests und die Beschreibung in der ASCLogger.ini geändert wird, aber keine Änderung am Quelltext vollzogen wird. Dies ermöglicht einen erneuten Test mit der gleichen Konfiguration, ohne dass noch einmal instrumentiert und kompiliert werden muss. Build project veranlasst SOTA nach dem Instrumentieren das zu testende Projekt zu kompilieren. Dazu ist es zum einen notwendig, in den Präferenzen unter dem Punkt General eine Ant-Version über die Angabe des Pfades der ''ant.bat'' einzubinden und zum andern, zum Projekt eine entsprechende xml-Datei hinzufügen, die das Kompilieren mittels Ant ermöglicht. Diese Option ist nur auswählbar, wenn ein entsprechendes Skript vorliegt und nicht die Option Rerun configuration ausgewählt wurde. Schließlich erlaubt die Option Run project das Projekt nach dem Kompilieren auch zu starten, sofern ein entsprechendes Startskript für das Projekt angegeben wurde. Das Starten ist nur möglich, wenn eine der beiden anderen Optionen ausgewählt wurde.

Wurde ein Test gestartet oder findet SOTA beim Parsen der Quellen diese schon instrumentiert vor, dann ändert sich die Option Start Test zu Restart Test. Es ist nicht möglich, die Quellen neu zu instrumentieren, ohne dass der aktuelle Test beendet und die Originaldateien wiederhergestell worden sind. Stattdessen besteht die Möglichkeit, das vorliegende instrumentierte Testprogramm erneut unter einem neuen Namen für den Test zu starten. Dabei wird lediglich die Initialisierungsdatei für die Loggingkomponente mit dem neuen Namen für den Test aktualisiert, jedoch werden keine Quelldateien oder Binaries verändert. Dieser Neustart entspricht der rerun-Option im normalen Start-Test-Dialog.


Stop Test

Abb.: Dialog Read Logs

Der Menüpunkt Stop Test beendet den aktuellen Testlauf. Die originalen Quelldateien werden daraufhin wiederhergestellt sowie neu eingelesen. Liegt das entsprechende Ant-Buildfile vor, werden die originalen Quellen auch wieder neu kompiliert.

Zum Abschluss wird ein Dialog geöffnet, der es erlaubt Logdateien aus dem Ausführungsverzeichnis auszuwählen, woraufhin diese eingelesen, ausgewertet und daraufhin in der View TestLogs aufgelistet werden. Im Anschluss daran lassen sich die Überdeckungsmaße für einzelne Testlogs oder Kombinationen von mehreren berechnen und anzeigen.


Create Report

Abb.: Dialog Create Report

Über den Menüpunkt Create Report lässt sich ein Überdeckungsreport anhand der eingelesenen Testlogs für das aktuelle Projekt erstellen. Wurde in den Präferenzen eingestellt, dass bei der Reporterstellung nach einem Dateinamen gefragt werden soll, öffnet sich ein Dialog zur Bestimmung der Reportdatei. Ansonsten wird der Report im Basisverzeichnis des Projekts unter dem Namen ''report.html'' gespeichert. Falls in den Präferenzen bestimmt wurde, dass diese Datei nicht überschrieben werden soll, so wird für jeden Report eine neue Datei nach folgendem Format generiert: "report_<date>_<index>.html". Diese und weitere Einstellung zur Reporterstellung lassen sich im Präferenzenmenü unter Report vornehmen

Build Project

Der Menüpunkt Build Project erlaubt unabhängig vom Teststatus das Kompilieren des Projektes aufgrund der aktuellen Quelldateien aus SOTA heraus. Dieser Menüpunkt ist nur dann aktiviert, wenn ein xml-Buildscript für das aktuelle Projekt angegeben und eine Ant-Version in den Präferenzen eingebunden wurde.

Run Project

Der Menüpunkt Run Project ist wählbar, wenn ein Startskript für das aktuelle Projekt angegeben wurde und führt dazu, dass dieses ausgeführt wird.

Restore Sources

Um das Projekt wieder in den Originalzustand zu überführen, kann auch der Menüpunkt Restore Sources gewählt werden. Im Gegensatz zum Menüpunkt Stop Test werden hier ausschließlich die Quelldateien wiederhergestellt und eingelesen, es wird weder neu kompiliert (so ein Buildfile vorliegt) noch wird der Dialog für das Einlesen der Testlogs geöffnet.

Read Logs

Mit dem Menüpunkt Read Logs kann man manuell die Logdateien unabhängig vom Teststatus des Projektes einlesen. Es wird dazu derselbe Dialog wie im Menüpunkt Stop Test geöffnet, der das Einlesen der Logdateien ermöglicht. Nach der Auswahl der Logdateien aus dem Ausführungsverzeichnis des Projektes, folgt wiederum das Einlesen und Aufbereiten der Testergebnisse.

Show Coverage

Die Aktivierung des Menüpunkts Show Coverage führt dazu, dass in der Quellcode- und der Überdeckungsansicht die Überdeckungsangaben farbig dargestellt werden.

4.1.3 Menü Configuration

Abb.: Menü Configuration

Configure Project

Abb.: Dialog Configure Project

Projektspezifische Einstellungen können über den Menüpunkt Configure Project vorgenommen werden. Im Einzelnen sind dies die beiden für SOTA relevanten Pfade des Testprojektes, nämlich das Basisverzeichnis sowie das Ausführungsverzeichnis, und darunter die eventuell vorliegenden Skripte, die zum Zweck der Kompilation und des Startens des Projektes in SOTA an dieser Stelle eingebunden werden können. Diese Werte werden nach Bestätigung durch Ok die bei der Projekterstellung eingegebenen Werte überschreiben.

Select Sources

Möchte man die vom Projekt umfassten Quelldateien erweitern oder ändern, ist dies über den Menüpunkt Update Sources möglich. Der sich daraufhin öffnende Dialog ist identisch zur zweiten Wizardseite der Projekterstellung. Hier lassen sich dazu analog die Quelldateien für das Projekt auswählen. Mit der Bestätigung der Auswahl werden die aktuellen Quelldateien durch die neuausgewählten ersetzt.

Preferences

Über den Menüpunkt Preferences lassen sich allgemeine Einstellungen zu SOTA durchführen, die für alle Projekte gelten und auch beim Verlassen des Programmes gespeichert werden. Die genaue Erläuterung der umfangreichen Einstellungsmöglichkeiten erfolgt unter dem Punkt 4.3 Präferenzen.

4.1.4 Menü Help

Abb.: Menü Help

Manual

Durch Auswahl des Menüpunktes Manual lässt sich die vorliegende Benutzerdokumentation aus SOTA heraus im Standardsystembrowser öffnen.

About

Der Menüpunkt About öffnet den Info-Dialog mit den Informationen zur benutzten SOTA-Version und den Plugin-Status der Applikation.

4.2 Views

4.2.1 View Project

Abb.: View Project
(hierarchische Darstellung)

In der View Project werden die Quellcodedateien des Testprogrammes und ihre untergeordneten Strukturen, wie Klassen und Methoden als Baum aufgelistet. Die obersten Knoten stehen für die Quellcodedateien, die man bei der Projekterstellung importiert 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 und kann der Baum komplett expandiert bzw. kollabiert werden. Der Button lässt die Liste abwechselnd aufsteigend und absteigend sortieren. Die Auswahl eines Element der Baumstruktur aktualisiert automatisch die Views Source und CFG.

Die einzelnen in dieser View aufgelisteten Strukturen sind dabei:

Wenn beim Parsen der Datei Instrumentationsanweisungen festgestellt werden, wie z.B. während des Testlaufes auf instrumentierten Quellen, so wird auf dem Icon zusätzlich noch ein rotes Ausrufezeichen angezeigt (Bsp.:).

Abb.: View-Menü
Abb.: View Project
(flache Darstellung ohne Dateien)

Über das rechts oben in der View auswählbare Menü lässt sich die Darstellung der Projektstrukturen konfigurieren. Hier lassen sich die zwei Darstellungsoptionen Hierarchical Presentation und Flat Presentation auswählen. Die hierarchische Darstellung entspricht der oben beschrieben Darstellung als Baumstruktur, welche die Standardeinstellung ist. Bei der flachen Darstellung liegen alle Struktureinheiten auf der Wurzelebene des Baumes, d.h. Datei, Klassen und Funktionen werden gleichrangig aufgelistet.

Mit den weiteren Optionen lässt sich die Darstellung wie folgt einstellen:


4.2.2 View Testlogs

Abb.: View TestLogs (unlocked)

Wurden Logdateien in das Projekt eingelesen, so werden diese in der View TestLogs aufgelistet. Falls die Logdatei schon vorhanden ist, werden die Logdaten an deren Ende angefügt, so dass ein Testlog eine Vielzahl von Testfalldaten enthalten kann. Als Standardeinstellung werden die einzelnen Testfälle vor dem Nutzer verborgen und lediglich die Testlogs aufgeführt. Um auch detailliert den Inhalt der Testlogs anzeigen zu lassen, muss man in den Toolbar der View den Button Lock Testlogs entriegeln, woraufhin zu jedem Testlog unter diesem alle in ihm enthaltenen Testfälle samt IScheme aufgelistet werden.

Nicht jede Logdatei ist von SOTA erstellt worden und nicht alle Testfalldaten gehört zu dem aktuellen Projekt. Die View TestLogs verwendet daher folgende Icons, um die Kompatibilität darzustellen:

Wählt man valide Testlogs bzw. Testfälle aus, werden automatisch die Überdeckungsinformation in den Views Source, CFG und Coverage entsprechend aktualisiert. Zum Ändern der kompletten Auswahl können die Buttons und verwendet werden. Eine Mehrfachauswahl von einzelnen Testlogs kann durch das Gedrückthalten der Tasten <Shift> bzw. <Strg> mit anschließender Auswahl der gewünschten Testlogs erreicht werden.

Ausgewählte Testlogs können über den Button Delete TestLogs gelöscht werden. Sie werden dann nicht nur aus dem Projekt sondern aus dem System entfernt. Diese Option steht nicht für Testfalldaten, also einzelne Teile eines Testlogs zur Verfügung.

Abb.: Dialog TestLogs

Durch einen Doppelklick auf einen der aufgelisteten Testlogs bzw. Testfalldatensatz lässt sich ein Dialog öffnen, welcher detaillierte Informationen zu den Testdaten enthält. Hier werden zuerst der Name und die Beschreibung des Tests sowie der Name des Instrumentierungsschemas aufgeführt. Als nächstes erfolgt zum einen die Angabe der Anzahl an Pfaden (d.h. Durchläufen einer Funktion), die der Testfall insgesamt enthält, sowie eine Auflistung aller durch diesen Test berührten Funktionen. Zu diesen Funktionen wird außerdem aufgelistet, wieviele Pfade zu ihr gehören. Die Liste lässt sich durch das Anklicken der Spaltenköpfe jeweils auf- und absteigend alphabetisch nach den Funktionsnamen und der Anzahl der Pfade sortieren.


4.2.3 View IScheme

Abb.: View ISchemes

In der View IScheme befinden sich lediglich die zum Projekt gehörigen Instrumentationsschemata, kurz Ischemes genannt. Zu jedem Projekt werden automatisch drei Ischemes erstellt, die jeweils das gesamte Projekt nach Level 1, 2 bzw. 3 instrumentieren. Zusätzliche ISchemes können über den Menüpunkt New IScheme erstellt werden und erscheinen danach in dieser View.

Durch Doppelklicken auf ein IScheme öffnet sich sich ein Dialog, der analog zum Menüpunkt New IScheme die gespeicherten Instrumentierungseinstellungen des ISchemes auflistet und die Änderung sämtlicher Informationen erlaubt. Über den Button Delete IScheme kann ein IScheme auch aus dem Projekt gelöscht werden.

Die werkseigenen ISchemes über Level 1,2 und 3 sind von diesen Änderungen ausgenommen und können auch nicht gelöscht werden.


4.2.4 View Source

In der View Source wird der Quellcode der ausgewählten Datei aus der View Project angezeigt. Werden Klassen oder Methoden ausgewählt, werden nur die entsprechenden Quellcodezeilen angezeigt, die zu dieser Einheit gehören.

Ist die Überdeckungsanzeige Show Coverage in der Toolbar aktiviert, wird die Überdeckung des Quelltextes durch die ausgewählten Testlogs der View TestLogs farbig dargestellt. Grüne Quellcodezeilen wurden durch die Tests abgedeckt, rote wurden im Test nicht berührt. Liegen mehrere Anweisungen in einer Zeile, wird die Zeile grün markiert, wenn auch nur eine einzige der Anweisungen überdeckt wurde. Die entsprechenden Farben für die Zeilenüberdeckung sowie das Syntaxhighlighting können im Menüpunkt Preferences eingestellt werden.

Abb.: View Source

4.2.5 View CFG

Während die View Source nur die Zeilenüberdeckung anzeigen kann und primär für den Überblick über die Quellcodeüberdeckung gedacht ist, hat die View CFG (Control Flow Graph) die Aufgabe, detaillierte Informationen zur Überdeckung der Quellcodestrukturen zu vermitteln. Wird in der View Project eine Funktion ausgewählt, so zeigt der obere Teil der View CFG den entsprechenden Kontrollflussgraphen an. Zu jeder Funktion wird mindestens ein Knoten für den Funktionseingang und einrr für den Funktionsausgang, mit dem alle die Funktion verlassenden Kanten verbunden sind, dargestellt. Die einzelnen verzweigenden Strukturen werden durch Knoten mit folgenden Labeln im Kontrollflussgraphen abgebildet:

Für die Zuordnung der Knoten zu den entsprechendne Quelllcodeteilen genügt das Anklicken eines Knotens, woraufhin im unteren Teil der View CFG der Quellcode auf den entsprechende Quellcodeabschnitt fokussiert und die korrespondierende Zeile gelb hinterlegt wird. Ist in der Viewtoolbar die Option Pin SourceView ausgewählt, wird nur bei der ersten Auswahl eines Knotens die entsprechende Quellcodezeile fokussiert, danach bleibt die Quellcodeanzeige ''gepinnt'' und scrollt nicht mehr automatisch. Die Auswahl der Option Show Number of Paths zeigt links neben jeder Kante des Kontrollflussgraphen die Anzahl der Kantendurchläufe an, die in den aktuellen Tests stattgefunden haben.

Damit auch große Graphen übersichtlich eingesehen werden können, lässt sich die Darstellung des Kontrollflussgraphen über den Button Zoom Out verkleinern und dann wieder über Zoom In vergrößern. SOTA bietet sieben Zoomstufen an, wobei noch auf den ersten drei Zoomstufe die Bedingungsüberdeckungsanzeige möglich ist und auf der vierten auch noch die Knotenbeschriftung angezeigt wird. Bei den kleinsten drei Zoomstufen werden die Knoten nur noch als unbeschriftete Quadrate dargestellt. Genauere Information sind über den Tooltip oder den Knoten-Informationsdialog erhältlich (siehe unten).

Abb.: View CFG

Werden in der View TestLogs Testlogs oder Testfalldaten ausgewählt, so ändert sich die Farbe der Knoten und Kanten entsprechend der Überdeckung durch die ausgewählte Testfallmenge. Die Überdeckungsdaten werden dabei automatisch aktualisiert. Überdeckte Knoten und Kanten werden grün dargestellt, nichtüberdeckte rot. Zur besseren Erkennung von überdeckten Knoten, die mehrere Ausgänge haben, von denen 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.

Abb.: Tooltip
(Iteration-Knoten)

Zusätzliche Informationen erhält man, wenn man den Mauszeiger kurz über einem Knoten stehen lässt. Der sich öffnende Tooltip gibt zu jedem Knoten seinen Typ und die Anzahl der Berührungen (''nrHits'') durch die Testfallmenge an, sowie seine projektinterne ID und die Zeilennummer, in welcher er zu finden ist. Verzweigende Knoten halten zudem Informationen, wie oft welche Verzweigung genommen wurde. Für If-Knoten wird daher je ein Wert für die true- und false-Verzweigung aufgeführt, Switch-Knoten halten eine Übersicht über die gewählten Selektionen und eine Auflistung, wie oft jeder Case angesprungen wurde. Im Case-Knoten wird dieser Wert, der sich von der Anzahl der Berührungen unterscheiden kann, als ''nrSelects'' nochmal aufgeführt. Der Tooltip für Iterationsknoten enthält neben der Anzahl der Berührungen auch noch die Angaben, wie häufig der Schleifenkörper übersprungen wurde (''nrSkips''), wie oft er genau ein einziges mal ausgeführt wurde (''nrSingleLoops''), wie oft zweimal und mehr (''nrMultipleLoops'') sowie die Angabe, wie häufig der Schleifenkörper insgesamt durchlaufen wurde (''nrLoops''). Schließlich wird noch bei den try-Knoten, die die Ausnahmebehandlung einleiten, angegeben, wie oft der try-Block ohne Ausnahme abgearbeitet werden konnte.

Abb.: Knoten-Information mit MCDC-Paar

Informationen zur Bedingungsüberdeckung kann man über zwei Wege erhalten. Zum einen befinden sich an den Knoten, die eine nicht-triviale Bedingung enthalten, an der rechten Seite vier kleine Kästchen, die für die verschiedenen Bedingungsüberdeckungsgrade stehen. Von oben nach unten sind dies die einfache, die minimal Mehrfach-, die MC/DC- sowie die Mehrfach-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, wo auch ihre Darstellung abgeschaltet sowie zusätzlich noch zwei weitere Sätze an überdeckungsanzeigenden Kästchen eingeblendet werden können.

Für genauere Informationen über die Überdeckung einzelner Knoten mit oder ohne Bedingung kann durch Doppelklicken auf diesen eine Dialogbox geöffnet werden. Als erstes werden hier sämtliche Informationen des Tooltips und zusätzlich dazu noch alle für diesen Knoten relevanten Überdeckungsinformationen sowohl prozentual als auch numerisch aufgelistet. Enthält dieser Knoten eine nicht-triviale Bedingung, findet man hier auch die logische Struktur der Bedingung sowie alle Belegungen ihrer Atome tabellarisch aufgelistet. In der ersten Spalte befindet sich der Wahrheitsvektor für die gesamte Bedingung, wie er aus der Testlogdatei eingelesen wurde. Die zweite Spalte enthält die Auswertung für die Gesamtbedingung und die darauffolgenden Spalten die Auswertung für alle atomaren Teilbedingungen. Für jede atomare Bedingung lässt sich das entsprechende MCDC-Paar, falls vorhanden, farblich hervorheben, indem man auf den entsprechenden Tabellenkopf der Bedingung klickt.


4.2.6 View Coverage

Die zentrale Auswertung der Überdeckung des Projektes erfolgt mittels der View Coverage. Hier werden analog zur View Project sämtliche Strukturen des Projektes hierarchisch in einem Baum aufgelistet, wobei die Darstellung der Baumstruktur analog zur View Project über das Viewmenü konfiguriert und somit auch zu einer flachen Darstellung gewechselt werden kann. Für jede einzelne Projektstruktur wird in den dazugehörigen Spalten 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 Präferenzen definiert werden können.

Die aufgeführten Überdeckungsmaße sind: Function Entry Exit Coverage (FEEC), Anweisungsüberdeckung (C0), Zweigüberdeckung (C1), einfache Bedingungsüberdeckung (C2), Minimale Mehrfach-Bedingungsüberdeckung (MMDC), Modifzierte Bedingungs-/Entscheidungsüberdeckung (MCDC), Mehrfach-Bedingungsüberdeckung (C3), Modifzierte Boundary-Interior-Pfadüberdeckung (MBI) sowie Boundary-Interior-Pfadüberdeckung(BI). Die Definition der einzelnen Überdeckungsmaße ist im Anhang aufgeführt.

Steht statt einer Wertangabe ein Strich in der View, so lässt sich das entsprechende Maß nicht auf diese Struktur anwenden, weil z.B. keine Bedingungen oder Anweisungen in dieser Klasse enthalten sind. Die Wertdarstellung selber lässt sich über das Ändern der Option Change Info von der prozentualen in die Verhältnisdarstellung und wieder zurück ändern. Mit den beiden Buttons Expand All und Collapse All lässt sich in der hiearchischen Darstellung die Projektstruktur auf- bzw. zuklappen.

Die gesamte Tabelle lässt sich nach den einzelnen Spalten, d.h. nach Name und Überdeckungsgrad sortieren, indem man auf die entsprechenden Spaltenköpfe klickt. Die Sortierung erfolgt dabei ausschließlich auf der Basis der Wurzelelemente des Baumes, d.h. in der hierarchischen Darstellung auf den Wert der Dateien bzw. Klassen. Jedoch kann für eine Sortierung nach Funktionen über das Viewmenü in die flache Darstellung umgeschaltet werden.

Abb.: View Coverage

4.2.7 View Metrics

Während der syntaktischen Analyse des Quellcodes beim Parsen werden eine Vielzahl statischer Metriken berechnet. In der View Metrics können diese direkt nach dem Einlesen des Projektes ausgewertet werden. Die View besteht analog zur View Coverage aus dem Projektbaum und einer Zuordnung folgender Maßzahlen zu den einzelnen Projekteinheiten: Zyklomatische Komplexität, Essentielle Komplexität, Lines of code, Anzahl der Anweisungen, Anzahl der Abzweigungen, Anzahl der Modifizierten Boundary-Interior-Pfadsegmente, Anzahl der Boundary-Interior-Pfade, Anzahl der Anweisungen mit Bedingungsauswertung, Anzahl der Atome in allen Bedingungen und Anzahl Bedingungen. Die Erläuterung und Definition der einzelnen Metriken ist im Anhang aufgeführt.

Auch hier lassen sich die Projektstrukturen wie in der View Coverage im Viewmenü in ihrer Darstellung konfigurieren und über die Buttons Expand All und Collapse All auf- und zuklappen. Gleichermaßen funktioniert die Sortierung der Tabelle durch Anklicken der entsprechenden Spaltenköpfe.

Abb.: View Metrics

4.3 Präferenzen

4.3.1 Präferenz View CFG

Abb.: Präferenz View CFG

Auf der Präferenzseite zur View CFG kann man im ersten Optionsblock einstellen, welche Überdeckungsmaße im Kontrollflussgraphen durch kleine quadratische Label neben den Knoten angezeigt werden. Die Standardeinstellung zeigt nur die vier Label für die Bedingungsüberdeckungsmaße (C2, MMDC, MCDC, C3) an allen Knoten an, die nicht-triviale Bedingungen enthalten sowie am Funktionsknoten. Durch das Aktivieren der Anzeige von Pfadüberdeckungsmaßen (2. Option) erscheinen am Funktionsknoten drei weitere Label, welche die Modifizierte Boundary-Interior-Pfadüberdeckung insgesamt, die Überdeckung der Modifizierte Boundary-Interior-Pfade durch den Funktionsrumpf, sowie die Boundary-Interior-Pfadüberdeckung anzeigt. Analog zum zweiten Label wird auch an jedem Iterationsknoten ein Label für die Überdeckung der Modifizierte Boundary-Interior-Pfade für die entsprechende Iteration erstellt. Die letzte Option stellt die verbleibenden drei Überdeckungsmaße (FEEC, C0, C1) am Funktionsknoten dar.

Im zweiten Block lässt sich die Darstellung der Knoten des Kontrolflussgraphen konfigurieren. Es können Farben für die normalen Knoten ohne Überdeckungsanzeige, überdeckte und nichtüberdeckte Knoten ausgewählt werden. Für eine differenzierte Darstellung werden verzweigende Knoten, die zwar überdeckt, aber deren Ausgänge nicht vollständig überdeckt sind, farbig hervorgehoben. Deren Farbe lässt sich unter Branching CFG-Nodes einstellen. Durch das Entfernen des Häkchens an der Option darüber, lässt sich diese differenzierte Darstellung auch abstellen.

Dazu ergänzend lässt sich im dritten Block die Farbe der Kanten des Kontrollflussgraphen für die Darstellung ohne Überdeckung, sowie für überdeckte und nichtüberdeckte Kanten einstellen. Zusätzlich lässt sich die Linienstärke der Kanten auf einen Wert von eins bis drei einstellen.

>

Abschließen kann man noch die Farbe für die Hervorhebung derjenigen Zeile im Quelltext auswählen, in welcher sich der aktuelle ausgewählte Knoten im Kontrollflusgraphen befindet.


4.3.2 Präferenz View Coverage

Abb.: Präferenz View Coverage

Für die farbliche Hinterlegung der prozentualen Überdeckungsanzeige in der View Coverage lassen sich hier Schranken und Farben definieren.

Zwei natürliche Schranken sind dabei eine vollständige (100%) und überhaupt keine (0%) Überdeckung. Für fünf weitere Schranken lassen sich prozentuale Werte eingeben, so dass beim Erreichen des Wertes die entsprechende Zelle mit der dieser Schranke zugewiesenen Farbe hinterlegt wird. Die default-Schranken sind hierfür: 25%, 50%, 75%, 90% und 99%. Falls für eine Schranke ein Wert angegeben wird, der größer ist als einer der über ihr liegenden Schranken, so wird er bei der Farbbestimmung ignoriert.

Anschließend lässt sich jeder Schranke ein Farbe zuordnen, mit welcher in der Tabelle der View Coverage alle Zellen hinterlegt werden, in welchen die prozentuale Überdeckung diese Schranke erreicht.


4.3.3 Präferenz General

Abb.: Präferenz General

Allgemeine Einstellungen zu SOTA lassen sich im Präferenzenpunkt General vornehmen. Falls man für ein Projekt ein Ant-Buildfile zur automatischen Kompilation nutzen möchte, so muss man hier die entsprechende Ant-Datei (\bin\ant.bat) einer installierte Ant-Version einbinden. Daraufhin lässt sich im Dialog Start Test die Option Build Project auswählen und auch der Menüeintrag Build Project bzw. sein Pendant in der Toolbar ist aktiviert. Wurde das Testprogramm mit Eclipse erstellt, so kann ein Ant-Buildfile für die Kompilation des Programmes dort über File -> Export -> Ant Buildfile exportiert werden.

Wird Create log file aktiviert, so werden für jeden Programmstart Systemmeldungen aus SOTA in Logdateien im Format sota_<YY-MM-DD>_<index>.log gesichert. Ist zusätztlich die Option Overwrite existing log file aktiviert, so wird immer nur eine Logdatei namens sota.log erstellt und bei jedem neuen Programmstart überschrieben.

Die beiden letzten Optionen bestimmmen noch allgemeine Teilaspekte des Verhaltens von SOTA. Ist Parse instrumented sourcecode aktiviert, so wird das Projek nach dem Teststart neu geparst, die Ansicht von Überdeckungsinformationen wird deaktiviert und der Darstellung des Projektes in allen Views liegen die nun instrumentierten Quellen zugrunde. Der dargestellte Quellcode in der View Source ist in diesem Fall immer identisch mit den aktuellen Quellen, d.h. die beiden Statusanzeigen in der Statuszeile weisen immer den gleichen Wert auf. Ist die Option deaktiviert, so wird statt der instrumentierten Datei das Backup geparst und angezeigt. Somit können unabhängig vom Status der Quelldateien auch immer Testlogs ausgewertet werden. Die letzte Option bestimmt, ob beim Teststopp zusätzlich zur Wiederherstellung des originalen Quellcodes das Testprojekt auch automatisch neu kompiliert werden soll, falls ein entsprechendes Ant-Skript eingebunden wurde. Andernfalls würden die Binaries des Testprogramm weiterhin instrumentiert bleiben und beständig Logausschriften erzeugen.


4.3.4 Präferenz Report

Abb.: Präferenz Report

Im Präferenzpunkt Report lässt sich die Ausgabe des Reports in die html-Datei konfigurieren.

Ist im ersten Block die Option Prompt for file name aktiviert, öffnet sich bei Wahl des Menüpunktes Create Report ein Dateiauswahldialog, der nach dem Namen der zu erstellenden Reportdatei fragt. Andernfalls wird der Report unter report.html im Projektverzeichnis des Testprogrammes erstellt und bei jeder neuen Reporterstellung überschrieben, oder aber jeweils ein neuer Name für den Report nach dem Schema report_<date>_<index>.html erstellt. Dieses Verhalten wird über den Präferenzpunkt Overwrite existing report bestimmt.

Der zweite Block bestimmt den Inhalt und die Darstellung des Reports. So kann eingestellt werden, ob alle importierten Testlogs für den Report genutzt werden sollen, oder nur die aktuell ausgewählten, und welche der folgenden Elemente in der Report-Datei aufgeführt werden sollen: die verwendeten Tests mit IScheme und Beschreibung, eine Übersicht über die Überdeckung aller Klassen (inklusive oder exklusive innerer Klassen) und/oder eine Übersicht über alle Funktionen, geordnet nach ihren Klassen. Schließlich kann noch die Font-Größe für das Reportfile vorgegeben werden.

Ist Use Colors ausgewählt, werden die Überdeckungsmaßzahlen in der Reportdatei analog zur Darstellung in der View Coverage entsprechend dem Grad der Überdeckung farblich hinterlegt. Die Werte für die Schranken werden aus dem Präferenzpunkt View Coverage übernommen, die Farben jeder einzelnen Schranke kann separat für die Reportdatei an dieser Stelle definiert werden.


4.3.5 Präferenz View Source

Abb.: Präferenz View Source

Das Syntaxhighlighting in der View Source lässt sich im gleichnamigen Präferenzpunkt einstellen. Die Farben für Keywords der Sprache, Kommentare, Strings sowie jene Kommentare, die durch das Instrumentieren durch SOTA hinzugefügt wurden, kann man hier frei wählen und schließlich auch die Schriftgröße für die Darstellung des Quelltextes einstellen

Für die Darstellung der Überdeckung des Quellcodes in der View Source kann man hier die Hintergrundfarbe für die überdeckten und nicht-überdeckten Quellcodezeilen wählen. Diese farbige Hinterlegung erfolgt, sobald Testslogs eingelesen wurden und die Option Show Coverage aktiviert ist.


4.4 Projekt löschen

Eine Funktion ''Delete Project'' ist nicht implementiert. D.h., dass alle zu einem Projekt gehörenden SOTA-Dateien mit Ausnahme der Logdateien (siehe View Testlogs) von Hand gelöscht werden müssen.

Alle SOTA-Dateien sind in 5.1beschrieben. Die von SOTA angelegten und zur Bereinigung des Systems zu löschenden Dateien sind im einzelnen:

Vor dem Löschen der Backup-Dateien ist es unbedingt nötig, etwaige instrumentierte Quelldateien wieder in ihren Originalzustand zu überführen (über den Menüpunkt Restore Sources), da dies ohne Backup-Datei kaum mehr möglich ist!