1 Einführung
2 Überblick
3 Installation und Programmstart
4 Benutzeroberfläche und Funktionalität
5 Dateien
6 Tutorien
6.1 Manueller Programmtest - Ziffernprogramm
6.1.1 Ziffernprogramm
6.1.2 SOTA und Eclipse
6.1.3 SOTA mit Ant-Buildfile und Startskript
6.2 Externes Testsystem (ATOSj) - HU-Seminarorganisation
6.2.1 ATOSj und HUSemOrg
6.2.2 SOTA und ATOSj
6.3 Automatisches Testsstem - SOTA-ATM
6.3.1 SOTA-ATM über Kommandozeilenaufruf
6.2.2 SOTA-ATM API
7 Anhang

6 Tutorien

Zur Erläuterung der Arbeitsweise mit SOTA behandeln die folgenden drei Tutorien die drei Einsatzmöglichkeiten von SOTA im Manuellen Programmtes, dem Programmtest mit einem externen Testprogramm und dem Test als Bibliothek in einem automatischen Testsystem.

6.1 Manueller Programmtest - Ziffernprogramm

6.1.1 Ziffernprogramm

Basis für die Tutorien zum Manuellen Programmtes ist ein einfaches Java-Programm, welches versucht, aus einem String eine positivrationale Zahl zu lesen. Das Testprogramm besteht aus einer Klasse Ziffer mit einer main-Funktion und der Funktion werteZiffernfolgeAus, welche die Auswertung des Strings übernimmt.

Der String kann entweder als Parameter des Programmes übergeben oder im Quellcode vorgegeben werden. Der im Quellcode "hartverdrahtete" String wird ausgewertet, wenn das Programm parameterlos aufgerufen wird. Das Programm gibt die Ziffer aus, wenn das Auslesen erfolgreich war, oder "-1", falls ein Fehler aufgetreten ist, d.h. der String keine solche Zahl enthielt.



         public class Ziffer {

            public static void main(String[] args) {

               if(args.length==0)
                  System.out.println(werteZiffernfolgeAus("."));
               else
                  System.out.println(werteZiffernfolgeAus(args[0]));

            }

            private static double werteZiffernfolgeAus(String inZiffernString) {

               double wert = 0.0;
               double genauigkeit = 1.0;
               String woBinIch = "VorKomma";
               boolean fehlerfrei = true;
               int position = 1;

               while(position <= inZiffernString.length() &fehlerfrei) {

                  String zchn = inZiffernString.substring(position-1, position);

                  if(zchn.matches("[0-9]")) {

                     if(woBinIch.equals("NachKomma"))
                        genauigkeit = genauigkeit / 10.0;
                        wert = 10.0*wert + Double.parseDouble(zchn);
                  }
                  else if(zchn.equals(".")  & woBinIch.equals("VorKomma"))
                     woBinIch  = "NachKomma";
                  else
                     fehlerfrei = false;

                  position ++;

               }

               if(!fehlerfrei | inZiffernString.length()==0 | ((woBinIch.equals("NachKomma")&inZiffernString.length()==1)))
                  return -1.0;
               else
                  return wert*genauigkeit;
             }
         }

6.1.2 SOTA und Eclipse

Allgemeiner Ablauf

Das Ziffernprogramm soll in Eclipse erstellt und dann einem strukturorientierten Programmtest unterworfen werden. Dies wird durch eine Folge von vier Phasen realisiert:

  1. Eclipse: Programmeingabe
  2. SOTA: Vorbereitungsphase
  3. Eclipse: Testphase
  4. SOTA: Auswertungsphase.

Das nachfolgende Datenflussdiagramm gibt alle wichtigen Aktionen sowie Ein-/Ausgaben wieder. Die vier Phasen ergeben sich durch den Wechsel zwischen Eclipse und SOTA und sind farblich differenziert dargestellt. Die Schnittstelle zwischen Eclipse und SOTA wird ausschließlich über die angegebenen Dateien realisiert.

Abb.: DFD-Diagramm Manueller Test mit Eclipse

Detailablauf

1. Eclipse: Programmeingabe

Das Testprogramm soll mit Eclipse erstellt werden. Falls Eclipse noch nicht installiert ist, kann dies anhand folgender Anleitung vollzogen werden: http://wiki.eclipse.org/Eclipse/Installation.

In Eclipse legt man zuallererst ein neues Projekt für das Testprogramm an. Dies lässt sich im Menü über File -> New -> Java Project erstellen. In dem sich öffnenden Dialog gibt man als Namen für das Projekt "Ziffer" ein, alle anderen Optionen können so verbleiben und der Wizard kann schon auf der ersten Seite durch Finish abgeschlossen werden.

Für das angelegte Projekt erstellt man nun eine Klasse Ziffer, indem man über File -> New -> Class den entsprechendenn Wizard aufruft. Hier trägt man den Namen der Klasse - Ziffer - ein und beendet den Dialog. In die erstelle Java-Datei, die sich im Hauptfenster von Eclipse öffnet, kopiert man abschließend den oben aufgelisteten Quellcode.

Abb.: Eclipse - New Java Project
Abb.: Eclipse - New Java Class

Als nächstes ist es noch notwendig, dem Projekt die Loggingkomponente als Bibliothek hinzuzufügen. Dazu erstellt man im Basisverzeichnis des Projektes (..\workspace\Ziffer\) einen Ordner lib und kopiert die Datei ASCLogger.jar aus dem SOTA-Verzeichnis dorthin. Wenn man dann die Eclipse-Projektübersicht aktualisiert (F5), so taucht diese Datei samt Verzeichnis dort auf (siehe Abbildung). Jetzt ist sie nur noch in den Buildpath des Projektes einzutragen, wozu man einfach per rechter Maustaste auf der ASCLogger.jar im Kontextmenü Build Path -> Add to Build Path auswählt. Daraufhin wird die Bibliothek bei den Referenced Libraries aufgenommen. Damit ist die Programmerstellung und die Vorbereitung für die Instrumentierung des Programmes durch SOTA abgeschossen.

Abb.: Ziffer-Projekt mit ASCLogger.jar ...
Abb.: ... und mit ASCLogger.jar im Buildpath

2. SOTA: Vorbereitungsphase - Projekterstellung

Nach dem Starten von SOTA über die SOTA.exe ist für das Testprogramm ein Projekt in SOTA anzulegen. Über den Menüpunkt New Project öffnet sich ein zweiseitiger Wizard, der durch die Projekterstellung führt.

Auf der ersten Seite ist der Name des Projektes - Ziffer - sowie das Basisverzeichnis (Project directory) des in Punkt 1 erstellten Projektes einzugegeben. Das Ausführungsverzeichns (Execution directory) des Projektes wird von SOTA automatisch auf das gleiche Verzeichnis gesetzt und muss nicht mehr verändert werden, da bei diesem Projekt beide Verzeichnisse identisch sind. Damit ist die erste Seite fertig ausgefüllt und über den Next-Button kann zur zweiten Seite des Wizards navigiert werden.

Auf der zweiten Seite sind die Quellen des Projektes zu importieren. Beim Ziffernprojekt existiert nur eine einzige Datei, das Markieren des Basisverzeichnisses genügt. Mit dem Finish-Button kann der Wizard beendet werden, woraufhin die Quelldatei eingelesen und geparst wird.

Mit dem Speichern des Projektes ist die Projekterstellung vollzogen. Es kann nun beim nächsten Mal über den Menüpunkt Open Project geladen werden. Sofort nach der Projekerstellung bzw. dem Laden eines Projektes kann der Quellcode in der View Source und der Kontrollflussgraph einer jeden Funktion (sobald sie in der View Project ausgewählt wurde) in der View CFG eingesehen werden. Die beim Parsen der Quellen berechneten statischen Maße sind in der View Metrics aufgelistet.

Abb.: erste Wizardseite
Abb.: zweite Wizardseite


3. SOTA: Vorbereitungsphase - Instrumentierung
Abb.: Dialog Start Test

Als nächster Schritt ist das Projekt für den nächsten Testlauf zu instrumentieren, d.h. mit Anweisungen anzureichern, die während des Programmablaufes Daten in eine Logdatei schreiben, die seine vollständige Rekonstruktion ermöglichen. Dazu wählt man im Menü Start Test. Im sich öffnenden Dialog ist eine Name für den Test einzugeben und ein Instrumentationsschema auszuwählen. Der Testname bestimmt auch den Namen der Logdatei, unter welcher die Logdaten gespeichert werden. Das Instrumentationsschema gibt die Art der Instrumentierung für alle Strukturen des Projektes vor. Hier ist im Normalfall das IScheme Level 2 instrumentation zu wählen, welches eine minimale Instrumentierung zur Berechnung aller Überdeckungsmaße für alle Dateien vollzieht.

Nach dem Bestätigen des Dialoges wird die Datei Ziffer.java als Ziffer.java.backup gesichert und im Anschluss mit Instrumentierungsanweisungen versehen. Damit ist die Instrumentierungsvorbereitung in SOTA beendet und die Testphase kann beginnen.



4. Eclipse: Testphase - Kompilation

In Eclipse muss als erstes der geänderte Quellcode für das gesamte Projekt geladen werden. Dazu wählt man das Projekt Ziffer in der Projektübersicht aus und aktualisiert es über "F5" oder per Kontextmenü -> Refresh. Eclipse kompiliert daraufhin automatisch die neuen Quelldateien.

Die instrumentierten Quellen benötigen als Bibliothek die ASCLogger.jar, die unter Schritt 2. eingefügt wurde. Ohne die korrekte Einbindung der Bibliothek kommt es zu Fehlermeldungen.

5. Eclipse: Testphase - Programmtest

Nach erfolgreicher Kompilation ist das Programm zum Test bereit. Es wird in Eclipse über den Button Run As... gestartet. Beim ersten Start fragt Eclipse über eine Dialogbox danach, ob das Programm als Application oder Applet zu starten ist. Hier wählt man Application. Der darauffolgende Dialog fragt nach der zu startenden Application, hier ist Ziffer zu wählen, wonach das Programm startet. Für die nächsten Starts sollte Eclipse die einmal gewählte Startkonfiguration nehmen, es reicht dann, den Button , welcher jetzt Run Ziffer heißt, zu drücken.

Abb.: Dialog Start Test
Abb.: Dialog Start Test


Die Parameter für den Programmstart unter Eclipse ließen sich in der Startkonfiguration des Projektes eintragen, aber da dieses Vorgehen für den einfachen Test etwas umständlich ist, wird empfohlen, den String in der Quellcodezeile

              System.out.println(werteZiffernfolgeAus("."));

zu ändern und dann das Programm parameterlos zu starten. Die Console in Eclipse sollte nun die erfolgreiche Initialisierungsausschrift des ASCLoggers anzeigen, sowie dann das Ergebnis des Auswertungsversuches des Strings.

Zusätzlich sollte nach dem ersten Programmtest mit instrumentierten Quellen in der Projektübersicht von Eclipse die entsprechende Logdatei mit dem Names des Tests auftauchten. Wiederholte Tests führen dazu, dass die neuen Logdaten an diese Datei angehängt werden.

6. SOTA: Auswertungsphase - Rekonstruktion

Sind die Tests in Eclipse beendet, so muss dies SOTA über den Menüpunkt Stop Test mitgeteilt werden. Die Quellen werden daraufhin wieder in den Originialzustand überführt. Alternativ dazu ließen sich die Quellen auch über den Menüpunkt Restore Sources wiederherstellen.

Abb.: Dialog Read Logs
7. SOTA: Auswertungsphase - Testauswertung

Um die Logdateien einzulesen, öffnet sich sofort nach Wahl des Menüpunktes Stop Test ein Dialog, der alle Dateien mit der Endung log des Ausführungsverzeichnis für die Importierung auflistet. Die dort gewählten Logdateien werden gelesen, für die weitere Auswertung analysiert und erscheinen anschließend in der View TestLogs. Die dort markierten TestLogs werden nun zur Berechnung der Überdeckungsmaße herangezogen und bestimmen die Darstellung der Überdeckung in den Views Source, CFG und Coverage.

Möchte man die Logdateien einlesen, ohne dass sich SOTA im Testmodus befindet, so ist der Menüpunkt Read Logs zu wählen, der denselben Dialog öffnet.



8. SOTA: Auswertungsphase - Reporterstellung

Der Programmtest wird durch die Erstellung eines Reports abgeschlossen. Hierzu wählt man den Menüpunkt Create Report, welcher abhängig von den Einstellung in den Präferenzen einen Dialog zur Eingabe des Dateinamens öffnet, oder aber einen generischen Namen wählt und die Reportdatei im Basisverzeichnis des Testprogrammes erstellt.

6.1.3 SOTA mit Ant-Buildfile und Startskript

Allgemeiner Ablauf

SOTA bietet die Möglichkeit, den Manuellen Programmtest durch die Verwendung zweier Skripte aus SOTA heraus zu vollziehen. Der Ablauf entspricht prinzipiell dem Ablauf aus Punkt 6.1.2, jedoch ist die dritte Phase, die Testphase unabhängig von Eclipse realisiert, welches lediglich zur Projekterstellung benötigt wird. Das folgende Datenflussdiagramm zeigt einen Überblick über die Arbeitsschritte in SOTA und an welchen Stellen die Skripte den Ablauf ergänzen.

Abb.: DFD-Diagramm Manueller Test mit Skripten

Detailablauf

Der Detailablauf entspricht dem aus Punkt 6.1.2, es werden lediglich abweichende Schritte aufgeführt.

1. Programmerstellung

Zusätzlich zur Projekterstellung aus 6.1.2 wird in Eclipse ein xml-Buildfile exportiert. Dies erreicht man, indem man über das Kontextmenü des Projektes Export ... aufruft und im sich öffnenden Dialog General -> Ant Buildfiles wählt.

Im zweiten Dialogfenser ist nur noch das entsprechende Projekt (hier: Ziffer) auszuwählen und nach dem Beenden wird eine XML-Datei namens ''build.xml'' im Basisverzeichnis des Projektes angelegt, die die Kompilation des gesamten Projektes ermöglicht.

Abb.: Eclipse Export Dialog
Abb.: Eclipse Ant-Buildfile-Dialog


Schließlich ist noch eine Batchdatei ''Ziffer.bat'' im Basisverzeichnis vom Ziffernprojekt anzulegen, mit welcher das Programm gestartet werden soll. Dazu ist einfach das Java-Kommando samt classpath dort einzutragen:

              java -cp bin;lib/ASCLogger.jar; Ziffer
2. Vorbereitungsphase: Projekterstellung
Abb.: Projekterstellung mit Skripten

Die Projekterstellung in SOTA funktioniert analog zu 6.1.2, mit dem einzigen Unterschied, dass nun die hier im ersten Schritt erzeugten Dateien ''build.xml'' und ''Ziffer.bat'' auf der ersten Wizardseite importiert werden. Diese Angaben können jedoch auch später noch über den Menüpunkt Configure Project geändert werden.

Damit die Kompilation anhand des Ant-Buildfiles gelingen soll, muss auch noch einmal für SOTA die ausführbare Ant-Datei ''ant.bat'' in den Präferenzen unter Preferences -gt; General -gt; Location of Ant eingebunden werden. Da die Einstellungen der Präferenzes projektübergreifend für SOTA gelten, ist dies nur einmal zu einzutragen.



3. Vorbereitungsphase: Instrumentierung / 4. Testphase: Kompilation / 5. Testphase: Programmtest

Durch die Einbindung beider Dateien ist der Manuelle Programmtest aus SOTA heraus möglich. Im unteren Bereich des Dialogs Start Test ist nun die Option Build project auswählbar, und wenn diese markiert ist, auch die Option Run project. Die erste Option führt nun dazu, dass nach dem Instrumentieren der Quellen nach dem ausgewählten IScheme das erstellte Ant-Buildfile abgearbeitet und so die instrumentierten Quellen kompiliert werden. Mit ausgewählter zweiter Option wird das angegebene Startskript ausgeführt und somit das Testprogramm gestartet. Die Startoption lässt in der gegenwärtigen Version von SOTA jedoch keine Parameterübergaben an das Testprogramm zu, wodurch der Einsatz für das Ziffernprogramm stark beschränkt wird. Um verschiedene Strings zu testen, wäre daher die Änderung des Startskripts vonnöten.

Abb.: Dialog Start Test mit Kompilations- und Startoption


6. Auswertungsphase: Rekonstruktion / 7. Auswertungsphase: Testauswertung / 8. Auswertungsphase: Reporterstellung

Die restlichen Schritte des Manuellen Programmtest verlaufen ohne Änderung wie in 6.1.2.

6.2 Test mit einem externem Testsystem (ATOSj) - HU-Seminarorganisation

6.2.1 ATOSj und HUSemOrg

Voraussetzung für die Nutzung von ATOSj als externes Testsystem und von HUSemOrg als Testprogramm ist ihre Installation.

Anleitungen hierzu findet man unter:

6.2.2 SOTA und ATOSj

Allgemeiner Ablauf

Der Testablauf orientiert sich am Manuellen Test, es folgt allerdings die Auslagerung des Testschrittes in das externe Testprogramm. Damit ergeben sich folgende Phasen im Testbetrieb:

  1. Eclipse: Programmeingabe
  2. SOTA: Vorbereitungsphase
  3. ATOSj: Testphase
  4. SOTA: Auswertungsphase.

Auch hier wird Eclipse durch die Verwendung eines Ant-Buildfiles lediglich zur Programmerstellung genutzt und spielt im weiteren Testverlauf keinerlei Rolle mehr. Das folgende Datenflussdiagramm gibt einen Überblick, an welcher Stelle das externe Testsystem in den Testphasen auftritt.

Abb.: DFD-Diagramm Manueller Test mit Skripten

Detailablauf

Der Detailablauf entspricht bis auf wenige Ausnahmen, die im Folgenden kurz ausgeführt werden, dem des Manuellen Tests.

1. Programmerstellung

Das Programm HuSemOrg wird in den Ordner workspace von Eclipse entpackt und enthält dabei schon die nötigen Anpassungen für die Verwendung mit SOTA. Analog zu 6.1.2 ist nun in Eclipse ein Projekt husemorg zu erstellen und die Bibliothek ASCLogger.jar zum Buildpath hinzuzufügen.

2. Vorbereitungsphase: Projekterstellung / 3. Vorbereitungsphase: Instrumentierung / 4. Testphase: Kompilation

Die nächsten drei Schritte beziehen sich nur auf die Vorbereitung in SOTA und sind identisch mit dem Manuellen Test.

5. Testphase: Programmtest

Nachdem nun die instrumentierten Quelldateien kompiliert wurden, wird für den Programmtest selbst ATOSj gestartet und auf den instrumentierten Klassen die Regressionstests ausgeführt. SOTA kann dafür beendet werden. Die Benutzung von ATOSj ändert sich in keiner Weise gegenüber dem normalen Regressionstest ohne SOTA, es gibt keine Interaktion zwischen den beiden Programmen.

6. Auswertungsphase: Rekonstruktion / 7. Auswertungsphase: Testauswertung / 8. Auswertungsphase: Reporterstellung

Die restlichen Schritte verlaufen ohne Änderung wie in 6.1.2.

6.3 Automatisches Testsstem - SOTA-ATM

SOTA-ATM (Automatisches Test-Modul) ist eine Bibliothek, die die Testfunktionalität von SOTA kapselt und völlig ohne GUI auskommt. Dadurch wird ermöglicht, die Instrumentierung von Projekten sowie die Auswertung der Logdateien aus anderen Programmen heraus automatisch zu steuern.

Zwei Steuerungsansätze werden für das Modul angeboten. Zum einen das Starten von SOTA-ATM als ausführbares Jar, welches über Kommandozeilenparameter gestartet und gesteuert werden kann und somit einfach in Skripten einsetzbar ist. Und zum anderen als integrierbare Bibliothek, welche Schnittstellen für die Funktionen zum Testen des Projektes bietet, die aus einem anderen Programm heraus aufgerufen werden können.

6.3.1 SOTA-ATM über Kommandozeilenaufruf

Parameter - Überblick

SOTA-ATM ist ein ausführbares Jar und lässt sich über die Kommandozeile mit verschiedenen Parametern starten. Die notwendigen Projektinformationen erhält SOTA-ATM entweder durch das Einlesen einer Projektdatei (-p) oder indem die notwendigen Werte beim Programmaufruf übergeben werden (-n). Eine Projektdatei kann über die graphische Benutzeroberfläche von SOTA, dem Nutzen der Option -n von SOTA-ATM oder auch manuell erstellt und mit Werten gefüllt werden.

Die weiteren Optionen verursachen die Ausführung der verschiedenen Teilfunktionen des Moduls im Test. Die wesentlichen Aspekte sind hier das Instrumentieren der Quelldateien (-i), das Wiederherstellen der originalen Quelldateien (-z), sowie die Auswertung von Tests durch das Einlesen der entsprechenden Logdateien (-t) und dem anschliessenden Erstellen eines Reports (-r).

Zusätzliche Funktionen, die damit kombiniert werden können, sind das Kompilieren (-c) und Starten des Testprogrammes (-s), falls die entsprechenden dazu notwendigen Dateien vorliegen. Die Reihenfolge der Optionen ist ohne Bedeutung.


         Usage: java -jar SOTA-ATM.jar [-options]

         options include:
                 -c [ <ant-buildfile> ]
                         compile sourefiles; only if ant-buildfile is provided
                 -i ( Level1 | Level2 | Level3 | <ischeme-name> )
                         instrument sourcefiles according to chosen level or IScheme
                 -n <name> <lang> <project-dir> [ <exec-dir> <src dir> ]
                         create new project file
                 -p <name>.project
                         open the project file
                 -r [ <report-file> ]
                         create report-file; if no name is provided it will be stored in "report.html"
                 -s [ <runscript> ]
                         start project; only if runscript is provided
                 -t <testname>.log [ <testname>.log ... ]
                         name of testlog to create or to import
                 -z      restore original sources

Parameter - detailliert

-c [ <ant-buildfile> ]

Der Parameter c führt dazu, dass das Projekt im Anschluss an die Dateioperationen kompiliert wird. Dazu ist es notwendig, dass in der Projektdatei ein Verweis auf Apache Ant eingetragen ist, und ein Ant-Buildfile entweder direkt nach -c übergeben wird, oder in der Projektdatei eingetragen ist.

-i ( Level1 | Level2 | Level3 | <ischeme-name> )

Mit dem Parameter i werden alle Quellen des Projektes als Backup gespeichert und danach instrumentiert. Es muss entweder der Name eines ISchemes aus der Projektdatei folgen, oder einer der Werte: "Level1", "Level2", "Level3", die für eine vollständige Instrumentierung des gesamten Projektes nach dem entsprechenden Level stehen. Das Projekt wird nur instrumentiert, wenn keine der Quelldateien schon instrumentiert ist.

Der Parameter i verlangt die Angabe eines Testnamens über den Parameter t und schließt die Verwendung der Parameters r zur Reporterzeugung und z zur Wiederherstellung der Quellen aus.

-n <name> <lang> <project-dir> [ <exec-dir> <src dir> ]

Der Parameter n führt zu einer Neuerstellung eines Projektes anhand der übergebenen Werte. Mindestens erforderlich ist die Angabe des Projektnamens, der verwendeten Programmiersprache und dem Projektverzeichnis des Testprogrammes. Die optionalen Parameter umfassen das Ausführungsverzeichnis und das Quellverzeichnis. Fehlen die optionalen Parameter, fällt für SOTA-ATM das Projektverzeichnis mit dem Ausführungsverzeichnis und dem Verzeichnis der Quelldateien zusammen.

Nach der Projekterstellung wird die Projektdatei unter dem Namen <name>.project gesichert. Der Parameter n schließt die Verwendung des Parameters p aus.

-p <name>.project

Mit diesem Parameter wird eine Projektdatei übergeben werden, welche die Informationen zur Charakterisierung des Projektes enthält. Solch eine Projektdatei kann zum einen über die graphische Benutzeroberfläche von SOTA, durch die Projektneuerstellung in SOTA-ATM über den Parameter -n oder manuell erstellt werden. Der Parameter p schließt die Verwendung des Parameters n aus.

-r [ <report-file> ]

Für die Testlogdateien, die über den Parameter t eingelesen wurden, werden die berechneten Überdeckungsmaße für das Projekt mit dem Parameter r in eine Reportdatei geschrieben. Folgt dem Parameter eine html-Datei, so wird in diese der Report geschrieben. Andernfalls erfolgt dies in die Datei "report.html".

Der Parameter r benötigt die Angabe mindestens einer Logdatei durch t und schließt die Verwendung des Parameters i für die Instrumentierung aus. Sind die Quelldateien instrumentiert, werden sie vor dem Testeinlesen wieder in den originalen Zustand überführt.

-s [ <runscript> ]

Mit dem Parameter s kann das Starten des Testprogrammes veranlasst werden. Dazu ist entweder die Angabe eines Runscriptes nach dem Parameter oder in der Projektdatei erfolderlich.

-t <log-file>.log [ <log-file>.log ... ]

Dieser Parameter hat zweierlei Bedeutung. Beim Instrumentieren mittels i legt er den Namen des Tests fest und damit auch, wie die zu erstellende Logdatei heißt. Für das Erstellen des Reports durch den Parameter r werden hier alle Testlogdateien aufgelistet, die importiert und für die Überdeckungsberechnung ausgewertet werden sollen.

-z

Der Parameter z führt dazu, dass alle Quelldateien des Projektes vom Backup wiederhergestellt werden. Er kann nicht zusammen mit dem Parameter i zur Instrumentierung verwendet werden.

Beispielnutzung

java -jar SOTA-ATM.jar -n Ziffer Java /workspace/Ziffer

Es wird ein Projekt ''Ziffer'' der Programmiersprache Java erstellt, dessen Projektverzeichnis unter ''/workspace/Ziffer'' zu finden ist. Von dort werden auch alle java-Dateien in das Projekt importiert. Nach der erfolgreichen Projekterstellung werden die Projektinformationen in die Datei ''Ziffer.project'' gespeichert. Dort können auch verschiedene Einstellung des Projektes, wie z.B. zu verwendende Buildfiles, verändert werden.

java -jar SOTA-ATM.jar -p Ziffer.project -i Level2 -t test1 -c -s

Dieser Aufruf des Moduls führt dazu, dass das Ziffer-Projekt geparst, vollständig nach Level 2 instrumentiert und im Anschluss kompiliert und gestartet wird. Außerdem wird als Name für den Test ''test1'' übergeben. Die Reihenfolge der Optionen ist ohne Bedeutung.

java -jar SOTA-ATM.jar -p Ziffer.project -z -c

Mit diesem Aufruf stellt man den Originalstand der Quellen und Binaries wieder her.

java -jar SOTA-ATM.jar -p Ziffer.project -t test1 -r

Dieser Aufruf des Moduls führt dazu, dass für das Projekt Ziffer der Test ''test1'' eingelesen wird und die dabei berechneten Überdeckungsdaten in die Standardreportdatei ''report.html'' geschrieben werden. Sind die Quelldateien instrumentiert, werden sie zu Beginn in den originalen Zustand überführt.

6.2.2 SOTA-ATM API

Überblick

Bindet man SOTA-ATM als Bibliothek in sein Programm ein, wird damit die Non-GUI-Funktionalität von SOTA für die statische Analyse und den Überdeckungstest zur Verfügung. Die Javadoc-Dokumentation ist hier zu finden.

Zentrale Klasse für den Programmtest ist die Klasse SotaATM, deren Objekte jeweils eine Testinstanz von SOTA darstellen. Konfiguriert wird eine Testinstanz entweder über das Laden einer Projektdatei oder der Übergabe einer ProjectConfiguration-Instanz, die analog zu einer Projektdatei alle relevanten Informationen für den Programmtest enthält. An dieser Testinstanz kann die Funktionalität von der Instrumentierung bis zur Reporterstellung genutzt werden (siehe javadoc).

Direkt nach dem Öffnen des Projektes lässt sich ein Metrics-Objekt von der Testinstanz zurückgeben, welche alle Maße der statischen Analyse enthält. Die Überdeckungsmaße sind im selben Objekt nach dem Programmtest und dem Auswerten der erzeugten Logdateien abrufbar.

Zur Konfiguration der Instrumentierung für einen Test, lassen sich variable ISchemes definieren, durch welche jeder einzelnen Struktur (Datei, Klasse, Funktion) des Testprojektes einem Instrumentationslevel zugewiesen werden kann. Die gesamte Instrumentierung des Projektes nach einem Instrumentationslevel lässt sich durch die Verwendung eines GlobalIScheme erreichen.

Beispielimplementation des manuellen Tests von HuSemOrg

Der folgende Java-Programmcode liest die vorgegebene Projektdatei ein, startet einen Test nach Instrumentationslevel 2, kompiliert und startet das Testprogramm. Nach Beendigung des Tests werden die originalen Quelldateien wiederhergestellt, das Projekt neu kompiliert und aus dem importierten Test ein Html-Report erstellt.


                String projectFile = "D:/Development/eclipse/husemorg.project";
                String reportFile = "report_test_1.html";
                String testName = "husemorg_test_1";
                String testDesc = "Test 08/15";

                TreeSet<String> testSet = new TreeSet<String>();
                testSet.add(testName);

                SotaATM atm = new SotaATM(fileName);
                atm.startTest(testName, testDesc, new GlobalIScheme("Level2", 2) , true);
                atm.stopTest(testSet, true);
                atm.createReport(reportFile);