1 Einführung
2 Überblick
3 Installation und Programmstart
4 Benutzeroberfläche und Funktionalität
5 Dateien
6.1 Übersicht
6.2 Projektdatei
6.3 Reportdatei
6 Tutorien
7 Anhang

5 Dateien

5.1 Übersicht

SOTA-Verzeichnis

Das SOTA-Verzeichnis beinhaltet das SOTA-System, wie z.B. die Startdatei SOTA.exe und die mit SOTA installierte Eclipse-Rich-Client-Platform, sowie weitere spezielle SOTA-Dateien und die Projektdateien.

sota.log, sota_<datum>_<index>.log

Hier protokolliert SOTA alle seine Aktivitäten.

language.spec

Die Spezifikationsdatei für die verschiedenen unterstützten Sprachen.

ASCLogger.jar

Die Logging-Komponente für Java-Testprogramme muss in das Testprogramm eingebunden werden und verlangt beim Test nach einer Initialisierungsdatei namens ASCLogger.ini (siehe unten).

<projectname>.project

Für jedes Projekt werden hier allgemeine Projektdaten vermerkt.

SOTA-ATM.jar

Das Automatische Test-Modul von SOTA, womit dessen Testfunktionalität ohne GUI einsetzbar ist. SOTA-ATM.jar ist eine ausführbare Jar-Datei, die aber auch als Programmbibliothek importiert werden kann. Der Zugriff ist damit sowohl über die Kommandozeile (Skripte) als auch softwaretechnisch möglich. Siehe dazu das Tutorium.

Basisverzeichnis des Testprogramms (Project directory)

Das Basisverzeichnis des Projektes beinhaltet (eventuell in einem Unterverzeichnis) die Quellen des Testprogrammes und an gleicher Stelle auch deren Backups, die von SOTA beim Erzeugen des Projektes erstellt werden. An diese Stelle werden auch die von SOTA automatisch generierten Reportdateien geschrieben, wenn nicht in den Präferenzen die Nachfrage über einen Dateiauswahldialog aktiviert wurde.

(\src\) <xyz>.java

Die Quelldateien des Testprojektes, sind nach dem Teststart (teilweise) instrumentiert.

(\src\) <xyz>.java.backup

Das Backup der originalen Quelldateien wird vor dem Teststart für alle nicht-instrumentierten Quelldateien erstellt.

(\bin\)<xyz>.class

Die kompilierten Class-Dateien, die je nach Zustand der Quelldateien instrumentiert sein können.

report.html, report_<datum>_<index>.html

Die von SOTA generierten Reportdateien.

<antbuildfilename>.xml

Eine eventuell vorhandenes Ant-Buildfile, das die Kompilation des Testprogrammes aus SOTA heraus ermöglicht. Kann bei Eclipse-Projekten über File -> Export -> Ant Buildfile erzeugt werden.

<runscriptname>.bat

Eine Batchdatei zum Starten des Testprogrammes, die, wenn in SOTA eingebunden, in Zusammenspiel mit dem Andbuildscript den manuellen Programmtest aus SOTA heraus ermöglicht.

Ausführungsverzeichnis des Testprogramms (Execution directory)

Das Ausführungsverzeichnis ist das Verzeichnis, aus welchem das Testprogramm gestartet wird. In den meisten Fällen entspricht diese Verzeichnis dem Basisverzeichnis des Testprogrammes. Eine Ausnahme hierzu bildet z.B. das Testen einer Eclipse-RCP-Application durch Eclipse, da hier das Ausführungsverzeichnis dem Basisverzeichnis der genutzten Rich-Client-Platform entspricht, d.h. im Allgemeinen: ..\eclipse\ .

ASCLogger.ini

Diese Initialisierungsdatei für die Loggingkomponente wird beim Teststart in dieses Verzeichnis kopiert, von wo es durch die Klasse ASCLogger.jar für die Erstellung der Logdatei benötigt wird.

<testname>.log

Die durch den ASCLogger erstellten Logdateien.

5.2 Projektdatei

Die Nutzung von SOTA erfordert es nicht, die Projektdateien zu verändern. Möchte man aber SOTA-ATM als automatisches Testmodul einsetzen, kann es von Vorteil sein, Projektdateien manuell oder per Skript zu erstellen bzw. zu verändern, um eine umfangreiche Kontrolle über den Test zu haben.

Die von SOTA verwendeten Projektdateien sind einfache XML-Dateien, welche die projektspezifischen Informationen als Werte der einzelnen Entitäten speichern. Ihre Form wird durch die Schema-Definition project.dtd definiert ist

Die Projektdatei definiert ein Project, das mindestens durch folgende Werte charakterisiert wird:

Name

der Name des Projektes, muss identisch mit dem Dateinamen ohne Endung sein.

Language

die Sprache des Projektes, muss in der Sprachspezifikation aufgeführt sein.

Prefix

der Präfix, der beim Instrumentieren zur Kennzeichnung von SOTA eingeführter Variablen dient, um Namenskollisionen zu vermeiden.

BackupExtension

die Endung, mit welcher die Backup-Dateien gespeichert werden sollen.

ProjectDir

das Basisverzeichnis des Projektes.

ExecDir

das Ausführungsverzeichnis des Projektes.

SourceFiles

eine Auflistung der Quelldateien (als SourceFile), die zum Projekt gehören.

Optional ist die Verwendung folgender Werte, welche spezielle Features des Programmes ermöglichen:

AntLocation

der Pfad zur Apache-Ant-Installation, notwendig für das automatische Kompilieren des Projektes.

AntBuildFile

die Ant-Builddatei, über welche das Projekt kompiliert werden kann.

RunScript

das Skript, welches zum Start des Projektes genutzt werden soll.

ISchemes

eine Auflistung an InstrumentationsSchemata (als IScheme), die die variable Instrumentierung des Projektes ermöglichen. Ein IScheme besteht dabei aus dem Namen und einer Zuordnung der einzelnen Strukturen des Projektes (Datei, Klasse, Funktion) zu einem Instrumentierungslevel, sowie einer etwaigen Beschreibung.

Es folgt eine exemplarische Projektdatei für das Projekt Ziffer, welche auch ein IScheme definiert, dass die einzige Quellcodedatei nach Level 1 und ihre Methode ''werteZiffernfolgeAus'' nach Level 2 instrumentier.


         <Project>
            <Name>Ziffer</Name>
            <Language>Java</Language>
            <Prefix>asc</Prefix>
            <BackupExtension>backup</BackupExtension>
            <ProjectDir>D:\Development\workspace\Ziffer</ProjectDir>
            <ExecDir>D:\Development\workspace\Ziffer</ExecDir>
            <SourceFiles>
               <File>D:\Development\workspace\Ziffer\src\Ziffer.java</File>
            </SourceFiles>
            <ISchemes>
               <IScheme>
                  <Name>Schema F</Name>
                  <Description>Ziffer.java Lvl1, werteZiffernfolgeAus Lvl2</Description>
                  <Level1>
                     <Item>Ziffer.java</Item>
                  </Level1>
                  <Level2>
                     <Item>Ziffer.java:Ziffer::werteZiffernfolgeAus(String)</Item>
                  </Level2>
               </IScheme>
            </ISchemes>
         </Project>

5.3 Reportdatei

Es folgt ein Beispielreport für das Projekt Ziffer bei den Eingabewerten "..", ".2", "1", "1.1" und ohne Eingabewert. (Zum Programm siehe 6.1.1.)

Jede Reportdatei führt zu Beginn den Names des Projektes und den Zeitpunkt der Erstellung auf. Es folgt eine Auflistung aller Überdeckungsmaße samt den im Test erreichten Werten für dieses Projekt, sowie einzelne statische Maße. Die weiteren Tabellen der Reportdatei werden nur erstellt, wenn diese in den Präferenzen ausgewählt wurden. Die Standardeinstellung gibt alle Tabellen aus.

Wurde Show Testlogs ausgewählt, folgt eine Auflistung aller Testdateien mit dem entsprechenden IScheme, sowie ihrer Beschreibung, die für diesen Report genutzt wurden. Wurde in den Präferenzen Use all tests for report aktiviert, werden alle importierten Testlogs für den Report genutzt und hier aufgeführt.

Bei aktivierter Show Classes Option folgt eine Tabelle, die zusätzlich zum Gesamtprojekt alle Klassen des Projektes auflistet und ihnen in einer Tabelle ihre Überdecksmaße gegenüberstellt, welche je nach Wert farblich hinterlegt sein können (vgl. Präferenzen).

Ist Show Functions aktiviert, wird nach dem Punkt Detailed Coverage für jede Klasse nun eine Tabelle mit den Überdeckungsmaßen der Klasse selbst und nachfolgend aller ihrer Funktionen in die Reportdatei geschrieben. Es führt ein Link von jeder Klasse in der Tabelle Coverage of Classes zu der entsprechenden Auflistung ihrer Funktionen in dem Abschnitt Detailed Coverage.

Ein umfangreicherer Beispielreport für das Projekt HUSemOrg lieg der Benutzerdokumenation bei.

SOTA Coverage Report


Project: Ziffer

created: 2009-03-23 13:54:35

Function Entry-Exit Coverage (FEEC)

100,00%

# Files

1

Statement Coverage (C0)

100,00%

# Classes (TopLevel- + inner Classes)

1 (1 + 0)

Decision Coverage (C1)

100,00%

# Functions

2

Condition Coverage (C2)

95,00%

# Lines

35

Minimal Multiple Decision Coverage (MMDC)

93,75%

# Statements

19

Modified Condition Decision Coverage (MCDC)

50,00%

# Conditions

16

Multiple Condition Coverage (C3)

46,43%

Modified Boundary-Interior Path Coverage (ModBI)

26,09%

Boundary-Interior Path Coverage (BI)

26,09%


Tests

test ..

Level 2 instrumentation

test .2

Level 2 instrumentation

test 1

Level 2 instrumentation

test 1.1

Level 2 instrumentation

test empty

Level 2 instrumentation


Coverage of Classes


top

FEEC

C0

C1

C2

MMDC

MCDC

C3

ModBI

BI

Project Ziffer

100,00

100,00

100,00

95,00

93,75

50,00

46,43

26,09

13,95

Class Ziffer

100,00

100,00

100,00

95,00

93,75

50,00

46,43

26,09

13,95


Detailed Coverage


top

FEEC

C0

C1

C2

MMDC

MCDC

C3

ModBI

BI

Class Ziffer

100,00

100,00

100,00

95,00

93,75

50,00

46,43

26,09

13,95

- main (String[])

100,00

100,00

---

---

---

---

---

100,00

100,00

- werteZiffernfolgeAus (String)

100,00

100,00

100,00

95,00

93,75

50,00

46,43

22,73

11,90