SOTA Benutzer-Dokumentation - Version 1.0 |
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.
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;
}
}
Das Ziffernprogramm soll in Eclipse erstellt und dann einem strukturorientierten Programmtest unterworfen werden. Dies wird durch eine Folge von vier Phasen realisiert:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Der Detailablauf entspricht dem aus Punkt 6.1.2, es werden lediglich abweichende Schritte aufgeführt.
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.
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
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.
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.
Die restlichen Schritte des Manuellen Programmtest verlaufen ohne Änderung wie in 6.1.2.
Voraussetzung für die Nutzung von ATOSj als externes Testsystem und von HUSemOrg als Testprogramm ist ihre Installation.
Anleitungen hierzu findet man unter:
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:
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.
Der Detailablauf entspricht bis auf wenige Ausnahmen, die im Folgenden kurz ausgeführt werden, dem des Manuellen Tests.
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.
Die nächsten drei Schritte beziehen sich nur auf die Vorbereitung in SOTA und sind identisch mit dem Manuellen Test.
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.
Die restlichen Schritte verlaufen ohne Änderung wie in 6.1.2.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Mit diesem Aufruf stellt man den Originalstand der Quellen und Binaries wieder her.
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.
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.
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);