Diplomarbeit

Fachhochschule Furtwangen 

Computer Networking 

Diplomarbeit 

Thema: 

Design und Implementierung eines 

verteilten Regressionstest-Frameworks 

Referent: 

Prof. Dr. Christoph Reich 

Fachhochschule Furtwangen 

Korreferent: 

Rudolf Strobl 

Linux Information Systems AG 

vorgelegt im: 

Sommersemester 2005 

am: 

31. August 2005 

vorgelegt von: 

Thilo Alexander Uttendorfer 

Matrikelnummer: 213164 

Bismarckstraße 23 

73257 Köngen

ii 

Ich erkläre hiermit an Eides Statt, dass ich die 

vorliegende Diplomarbeit selbständig und ohne unzulässige 

fremde Hilfe angefertigt habe. Die verwendeten Quellen und 

Hilfsmittel sind vollständig zitiert. 

München, den 29. August 2005 

Thilo Alexander Uttendorfer 

Bismarckstraße 23 

73257 Köngen

Inhaltsverzeichnis 

1 Einleitung 1 

1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

2 CoreBiz 3 

2.1 Debian GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2.2 CoreBiz Ressource-Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.3 Installation und Konfiguration von CoreBiz Systemen . . . . . . . . . . . 5 

2.3.1 Generierung von Systemen . . . . . . . . . . . . . . . . . . . . . . 6 

2.3.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.3.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.4 Qualitätssicherung des CoreBiz Ressource-Pools . . . . . . . . . . . . . . 7 

2.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

3 Software-Test 9 

3.1 Softwarequalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

3.2 Ausprägungen von Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

3.2.1 Testarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

3.2.2 Testszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3.3 Regressionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 


4 Test-Werkzeuge und Testsuites 17 

4.1 Automatisiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

4.2 Test-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

4.2.1 Vergleich von Test Management Tools . . . . . . . . . . . . . . . 20 

4.2.2 Test Environment Toolkit . . . . . . . . . . . . . . . . . . . . . . 23 

4.3 Testsuites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

4.3.1 Linux Standard Base Testsuites . . . . . . . . . . . . . . . . . . . 26 

4.3.2 CoreBiz Testsuites . . . . . . . . . . . . . . . . . . . . . . . . . . 26 


iii

iv 

Inhaltsverzeichnis 

5 CoreBiz Testsuite - Remote Tests 29 

5.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

5.2 Aufbau der Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

5.2.1 TET-Lite vs. Distributed TET . . . . . . . . . . . . . . . . . . . 29 

5.2.2 Virtualisierungssoftware . . . . . . . . . . . . . . . . . . . . . . . 31 

5.2.3 Konfiguration der Systeme . . . . . . . . . . . . . . . . . . . . . . 32 

5.3 Ablauf eines Testfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

5.4 Testarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

5.4.1 Verifikation von Konfigurationen . . . . . . . . . . . . . . . . . . 34 

5.4.2 Funktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

5.4.3 Performance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

5.5 Ein prototypischer Testfall . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.5.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.5.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.6 Problematiken bei Remote Tests . . . . . . . . . . . . . . . . . . . . . . . 38 


6 Corebiz Testsuite - Verteilte Tests 41 

6.1 Aufbau der Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

6.2 Das Test Environment Toolkit und verteilte Tests . . . . . . . . . . . . . 42 

6.2.1 Einbinden von weiteren Programmiersprachen . . . . . . . . . . . 42 

6.2.2 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

6.2.3 Installation von verteilten Tests . . . . . . . . . . . . . . . . . . . 44 

6.3 Drei prototypische Testfälle . . . . . . . . . . . . . . . . . . . . . . . . . 44 

6.3.1 LDAP Konflikttest . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

6.3.2 LDAP Performance Test . . . . . . . . . . . . . . . . . . . . . . . 47 

6.3.3 LDAP Latenztest . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

6.4 Problematiken bei verteilten Tests . . . . . . . . . . . . . . . . . . . . . . 56 


7 Conclusio 57 

7.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 

A Literaturverzeichnis 61 

B Abbildungsverzeichnis 63 

C Tabellenverzeichnis 65 

D Abkürzungsverzeichnis 67

Kapitel 1 

Einleitung 

1.1 Problemstellung 

Das Ziel dieser Diplomarbeit ist die Erarbeitung eines Konzepts für ein verteiltes Regressionstest-Framework 

und dessen prototypische Implementierung. Hintergrund dieser 

Tests ist die Qualitätssicherung der Produktreihe CoreBiz, die von der Linux Information 

Systems AG entwickelt wird. 

CoreBiz basiert auf dem Softwarearchiv von Debian GNU/Linux. Dieses Archiv wird 

in regelmäßigen Abständen aktualisiert. Das bedeutet, dass jedes Softwarepaket, für 

das eine aktuellere Version verfügbar ist, durch diese ersetzt wird. Um nach solch einer 

Aktualisierung eine Regression, also einen Rückschritt bei der Qualität zu verhindern, 

müssen verschiedene Tests durchgeführt werden. Das Regressionstest-Framework soll die 

bisherige Testumgebung integrieren und erweitern. Dabei soll untersucht werden, welche 

Arten von Tests sinnvoll eingesetzt werden können. 

Besondere Bedeutung haben die so genannten verteilten Tests. Diese unterscheiden sich 

zu normalen Tests dahingehend, dass die Komponenten eines solchen Testfalls auf verschiedenen 

Systemen eines lokalen Netzwerkes ablaufen und sich zeitlich und inhaltlich 

aufeinander beziehen. Es werden also die Interaktionen zwischen verschiedenen Systemen 

getestet. 

1.2 Vorgehensweise 

Zunächst wird die Produktreihe CoreBiz vorgestellt. Da sich das Regressionstest-Framework 

vorrangig auf die verschiedenen Produkte von CoreBiz bezieht, ist ein grundlegendes 

Verständnis über den Aufbau dieser Software nötig. Es wird gezeigt was die Software 

leistet und aus welchen Komponenten sie besteht. Aus diesem Zusammenhang heraus 

wird erläutert, warum und an welchen Punkten Softwaretests eingesetzt werden sollen. 

Anschließend wird auf das Thema Softwaretest im Allgemeinen eingegangen. Es wird 

die Notwendigkeit eines Qualitätsmanagements von Software aufgezeigt und es werden 

1

2 Kapitel 1 Einleitung 

verschiedene Testarten näher erläutert. Darauf folgt ein Überblick über Werkzeuge, die 

den Testprozess unterstützen und vereinfachen. In diesem Zusammenhang werden die 

Möglichkeiten sowie die Vor- und Nachteile der Automatisierung von Tesfällen diskutiert. 

Der praktische Teil dieser Arbeit enthält die prototypische Implementierung von Remote 

und verteilten Tests. Es wird gezeigt, wie eine Testumgebung für Testfälle dieser Art 

realisiert werden kann. Auf einige exemplarische Testfälle wird näher eingegangen und 

es werden die Probleme und Ergebnisse dieser Tests diskutiert. Zum Ende dieser Arbeit 

wird ein Fazit gezogen und ein Ausblick für die Zukunft dargestellt.

Kapitel 2 

CoreBiz 

Eine modular aufgebaute Software um Linux für unterschiedlichste Einsatzzwecke zu 

installieren und zu konfigurieren wird unter dem Namen CoreBiz von der Linux Information 

Systems AG angeboten. Als Basis wird dafür die Linux Distribution Debian 

GNU/Linux (vgl. [Deba]) benutzt. Da sich diese Arbeit an vielen Stellen immer wieder 

darauf bezieht, wird im Folgenden der Aufbau und die Funktionsweise von Core- 

Biz Systemen im Detail erläutert. In diesem Zusammenhang wird zunächst auf Debian 

GNU/Linux eingegangen. 

2.1 Debian GNU/Linux 

Debian GNU/Linux ist ein freies Betriebssystem, das unterschiedlichste Rechnerarchitekturen 

unterstützt und mehrere Tausend Softwarepakete enthält. Es wird im Gegensatz 

zu vielen anderen Linux Distributionen ausschließlich von Freiwilligen entwickelt und ist 

die am weitesten verbreitete nicht-kommerzielle Linux Distribution (vgl. [Wik]). 

Debian hat sehr strenge Richtlinien in Bezug auf Software, die in die Distribution aufgenommen 

wird. So wird ausschließlich Software zugelassen, die unter einer freien Lizenz, 

wie zum Beispiel der GNU General Public License (GPL) oder der Berkeley Software 

Distribution (BSD) License 1 , veröffentlicht wurde. Diese Richtlinien sind in den Debian 

Free Software Guidelines (DFSG) (vgl. [Debb]) geregelt. 

Debian hebt sich von anderen Linux Distributionen vor allem durch sein Paketmanagement 

ab, welches das Aktualisieren von Paketen und das Auflösen von Abhängigkeiten 

zwischen diesen Paketen zuverlässig löst. Außerdem bietet es ein sehr umfangreiches Archiv 

an Software. Dieses Archiv ist in drei 2 verschiedenen Varianten erhältlich: stable“, ” 

” testing“ und ” unstable“. Dabei enthält stable“ die jeweils letzte veröffentlichte Version 

” 

und testing“ die Kommende aber noch nicht veröffentlichte Version des Betriebssystems. 

Die Variante unstable“ enthält jeweils relativ aktuelle, meist aber ungetestete 

” 

” 

Pakete, die, wie der Name schon sagt, unstabil oder fehlerhaft sein können. 

1 Die beiden Lizenzen findet man unter [Freb] beziehungsweise unter [Unia] 

2 Es gibt noch eine vierte Variante ” 

experimental“, die aber nur für Entwickler gedacht ist. 

3

4 Kapitel 2 CoreBiz 

2.2 CoreBiz Ressource-Pool 

Größter Nachteil an Debian (zum Zeitpunkt des Schreibens dieser Arbeit) ist der sehr 

lange Releasezyklus. Tabelle 2.1 zeigt die veröffentlichten Versionen der letzten Jahre. 

Der immer größer werdende Abstand zwischen den Versionen ist unter anderem auf die 

Vielzahl der unterstützten Architekturen und der stetig steigenden Anzahl an Paketen 

zurückzuführen. Das Debian Projekt ist sich zwar diesem Problem bewußt und arbeitet 

an Lösungen, es ist jedoch nicht damit zu rechnen, dass es mittelfristig deutlich kürzere 

Releasezyklen geben wird. 

Version Name Datum 

2.0 Hamm 24. Juli 1998 

2.1 Slink 9. März 1999 

2.2 Potato 15. August 2000 

3.0 Woody 19. Juli 2002 

3.1 Sarge 6. Juni 2005 

? Etch ? 

Tabelle 2.1: Veröffentlichte Versionen von Debian (Quelle: [Deba]) 

Daraus ergibt sich, dass die stabile Variante von Debian zum Teil sehr alte Pakete 

enthält, da in diesem Archiv nur eventuelle Sicherheitslücken beseitigt werden, jedoch 

keine neuen Pakete hinzugefügt werden. Dagegen werden die Varianten testing“ und 

” 

unstable“ ständig mit neuen Paketen aktualisiert. Das führt dazu, dass sich auch grundlegende 

Teile des Systems verändern können und diese Varianten somit keine verlässliche 

” 

Lösung darstellen. 

Die Anforderungen an ein CoreBiz System sind aber einerseits die Verfügbarkeit aktueller 

Versionen von bestimmten Softwarepaketen, andererseits muß die Software stabil 

und langfristig einsetzbar sein. Um dieses Dilemma zu überwinden, wird für CoreBiz in 

regelmäßigen Abständen ein so genannter Snapshot aus ” 

testing“ gemacht. Das bedeutet, 

dass sämtliche Pakete aus dem Debian Archiv ” 

eingefroren“ werden und von diesem 

Zeitpunkt an nur noch durch Sicherheitsaktualisierungen oder Bugfixes verändert werden 

können. Dadurch sind CoreBiz basierte Server und Clients einerseits aktueller als 

entsprechende, auf Debian ” 

stable“ basierende Systeme. Andererseits wird trotzdem versucht 

die Stabilität und Qualität von Debian ” 

stable“ zu erreichen. 

Diesem regelmäßig aktualisiertem Archiv werden dann zusätzlich CoreBiz-spezifische Pakete 

hinzugefügt. Um begrifflichen Missverständnissen vorzubeugen, wird dieses Archiv 

CoreBiz Ressource-Pool“ bezeichnet. 

”

2.3 Installation und Konfiguration von CoreBiz Systemen 5 

2.3 Installation und Konfiguration von CoreBiz 

Systemen 

Die Basis jeder CoreBiz Installation ist der so genannte ” 

CoreBiz Factory Server“. Dieses 

System verfügt über alle Komponenten, die nötig sind, um weitere Systeme zu installieren 

und hat direkten Zugriff auf den CoreBiz Ressource-Pool. Hier werden sämtliche Konfigurationseinstellungen, 

Parameterisierungen und Kundenanpassungen durchgeführt, 

um daraus den so genannten ” 

CoreBiz Base Server“ zu generieren. 

Der CoreBiz Base Server wird an den Kunden ausgeliefert und ist dann in der Lage, 

weitere Systeme zu installieren. Diese Fähigkeit wird zum Beispiel genutzt, um die Installation 

von Clients direkt vor Ort beim Kunden durchzuführen. Abbildung 2.1 zeigt 

den typischen Aufbau einer CoreBiz Umgebung. 

CoreBiz Factory 

CoreBiz Base 

CoreBiz 

Ressource-Pool 

installiert 

installiert 

CoreBiz Backup 

CoreBiz Client CoreBiz Client CoreBiz Client 

Abbildung 2.1: CoreBiz Umgebung


Auf dem CoreBiz Factory Server beziehungsweise dem CoreBiz Base Server ist das Softwarepaket 

OpenLDAP (vgl. [Ope]) installiert, um Benutzerkonten und Gruppen mittels 

des Lightweight Directory Access Protocol (LDAP) zentral verwalten zu können. Außerdem 

wird der LDAP-Server genutzt, um bestimmte Server-Dienste zu parameterisieren. 

Das wird aber nur von einigen Diensten unterstützt, wie beispielsweise dem DHCP- 

Server. 

Wenn alle Kundenanpassungen und Konfigurationen für ein neues System erstellt wurden, 

werden im wesentlichen folgende Schritte durchgeführt: 

1. Generierung 

2. Installation 

3. Konfiguration 

2.3.1 Generierung von Systemen 

Wichtiger Bestandteil ist die frei erhältliche Software FAI (Fully Automatic Installation) 

(vgl.[Lan]), welche die Infrastruktur für eine komplett automatische Installation über das 

Netzwerk oder die Generierung von Installations-CDs ermöglicht. Anhand von Profilen 

und Komponenten werden die unterschiedlichen CoreBiz Systeme erstellt. Tabelle 2.2 

zeigt den Zusammenhang zwischen Profil, Komponente und Debian-Paket. Ein Profil 

stellt ein komplettes CoreBiz System dar. Eine Komponente dagegen ist ein bestimmter 

Teil eines Systems, wie zum Beispiel die KDE Umgebung, und enthält eine Liste von 

Debian-Paketen. Da die Komponenten aber unabhängig von einem Profil sind, können 

sie beliebig in anderen Profilen wiederverwendet werden. Durch diesen modularen Ansatz 

ist es möglich, auf einfache Art und Weise Kundenanpassungen durchzuführen. 

enthält 

Beispiel 

Profil Liste mit Komponenten CoreBiz Client 

Komponente Liste mit Paketen KDE Umgebung 

Paket Debian-Paket Konqueror 

Tabelle 2.2: Interner Aufbau eines CoreBiz Systems 

2.3.2 Installation 

Die Installation eines CoreBiz Systems erfolgt vollkommen automatisch entweder durch 

eine Installations-CD oder über das Netzwerk. Im Falle der Netzwerkinstallation wird 

PXE (Preboot eXecution Environment) genutzt, um ein System automatisch zu installieren. 

Als PXE-Boot-Server dient dabei der CoreBiz Factory Server beziehungsweise 

der CoreBiz Base Server.

2.4 Qualitätssicherung des CoreBiz Ressource-Pools 7 

Einem System, das über das Netzwerk installiert wird, wird mit Hilfe von DHCP (Dynamic 

Host Configuration Protocol) eine IP-Adresse zugewiesen. Daraufhin wird vom 

Server ein Kernel heruntergeladen mit dem das System in der Lage ist zu booten. 

Die Installation erfolgt dann in zwei Phasen. Während der ersten Phase werden Systeminformationen 

ausgelesen und an den Server übermittelt. Es werden dabei entsprechende 

Eintragungen im LDAP des CoreBiz Base Servers vorgenommen. Ab diesem Zeitpunkt 

ist das System registriert und es können beispielsweise Hardwareinformationen ausgelesen 

oder das zu installierende Profil geändert werden. Nach einem Neustart des Systems 

erfolgt dann die zweite Phase mit der eigentlichen Installation. 

Die Installation von CD kann unabhängig der Netzwerkumgebung durchgeführt werden. 

Von Nachteil ist allerdings die Beschränkung der Kapazität auf eine CD oder, falls ein 

entsprechendes Laufwerk vorhanden ist, auf eine DVD. Zum Beispiel kann es bei einem 

so genannten ” 

Fat Client“ sein, dass mehrere Gigabyte an Softwarepaketen installiert 

werden müssen. 

2.3.3 Konfiguration 

Ziel jeder CoreBiz Installation ist es, ohne manuellen Eingriff abzulaufen. Das setzt voraus, 

dass alle Konfigurationsparameter schon vor der Installation festgelegt werden. Des 

weiteren ist es oft wünschenswert bestimmte Konfigurationen bei produktiven Systemen 

später zu ändern. 

Um diese Anforderungen realisieren zu können, wird das Werkzeug ” 

cfengine“ (vgl. 

[Frea]) eingesetzt. Der Name ” 

cfengine“ leitet sich von ” 

configuration engine“ ab. Damit 

lassen sich unter anderem Konfigurationsdateien auf einfache und elegante Art und 

Weise modifizieren. Es bringt eine eigene Programmiersprache mit, die im Gegensatz 

zu vielen anderen Sprachen ohne die üblichen if-else-Anweisungen auskommt. Anweisungen 

werden dagegen in Abhängigkeit von bestimmten Klassen ausgeführt, die frei 

definiert werden können. Weiterhin stehen eine Vielzahl von vordefinierten Klassen zur 

Verfügung, die beispielsweise bestimmte Systemeigenschaften wie die Kernelversion repräsentieren. 

Bei einem CoreBiz System wird dieses Werkzeug genutzt, um bestimmte Systemparameter 

in Konfigurationsdateien zu setzen oder zu überprüfen. Das können beispielsweise 

grundlegende Dinge wie die Netzwerkkonfiguration sein, aber auch das Hintergrundbild 

der grafischen Oberfläche kann so verändert werden. 

2.4 Qualitätssicherung des CoreBiz Ressource-Pools 

Bei einer Aktualisierung des CoreBiz Ressource-Pools wird die Variante ” 

testing“ des 

Debian Archivs verwendet. Dabei kann nicht davon ausgegangen werden, dass alle Pa-


kete fehlerfrei sind, beziehungsweise sich alle Programme genau so verhalten wie ihre 

Vorgängerversion. Fehler können beispielsweise schon daraus entstehen, dass sich der 

Name eines Parameters einer Konfigurationsdatei ändert. Wenn dieser Parameter durch 

CoreBiz mittels ” 

cfengine“ kontrolliert wird, würde dies höchstwahrscheinlich zu einer 

fehlerhaften Konfiguration führen. Es könnten sich aber auch die Schnittstellen eines Programmes 

geändert haben oder es fehlen sogar bestimmte Pakete im Ressource-Pool. 

Das bisherige Verfahren bei einer Aktualisierung des Ressource-Pools war, das auf einer 

CoreBiz Installation Tests der Linux Standard Base (LSB) ausgeführt wurden. Diese 

Tests überprüfen verschiedene Aspekte wie zum Beispiel die POSIX-Kompatibilität oder 

die Konformität des Dateisystems zur LSB. Damit kann zwar eine gewisse Grundfunktionalität 

abgedeckt werden, aber es wäre wünschenswert weitergehende Tests durchzuführen. 

Deshalb gibt es den Ansatz, Konfigurationsdateien, die durch ” 

cfengine“ automatisch 

verwaltet werden, mit Hilfe von Tests zu verifizieren. Vorstellbar sind aber auch weitergehende 

Tests, die direkt bestimmte Funktionalitäten von CoreBiz Systemen überprüfen 

oder aber auch Performance- und Lasttests. 

Ziel aller Tests ist es, festzustellen, ob sich nach einer Aktualisierung des Ressource- 

Pools, die Funktionalität der CoreBiz Skripte, die CoreBiz Systeme an sich und das 

Zusammenspiel verschiedener CoreBiz Systeme miteinander in irgendeiner Form beeinträchtigt 

ist. Auf letzteres, also die Interaktion zwischen verschiedenen Systemen, wird 

dabei besonderen Wert gelegt. 

2.5 Zusammenfassung 

In diesem Kapitel wurden die Komponenten eines CoreBiz Systems erklärt. Neben Debian 

GNU/Linux, welches die Basis für alle CoreBiz Systeme darstellt, wurde die Generierung, 

die Installation und die Konfiguration dieser Systeme detailliert erläutert. 

Besonders interessant ist die Qualitätssicherung des Resource-Pools, der sämtliche Software 

enthält, die bei CoreBiz Systemen verwendet wird. Es wurde gezeigt, dass bei 

CoreBiz Systemen unterschiedliche Software integriert wird und diese Systeme im Netzwerk 

zusammenarbeiten und voneinander abhängig sind. Um Fehler in einem CoreBiz 

System, aber auch in der vollständigen CoreBiz Umgebung zu verhindern, müssen gewisse 

Tests durchgeführt werden. Es ist also nötig ein Konzept für die Qualitätssicherung 

dieser Systeme zu entwickeln und zu realisieren.

Kapitel 3 

Software-Test 

Testing is the process of executing a program with the intent of finding errors.“ 

[Mye79, Seite 

” 

5] 

In diesem Kapitel wird auf die Notwendigkeit des Qualitätsmanagements von Software 

eingegangen. Es soll einen Überblick über die grundlegenden Termini und Themen 

aus dem Gebiet der Softwaretests im Hinblick auf die CoreBiz Testumgebung geben. 

Besondere Beachtung wird den verschiedenen Testausprägungen geschenkt. 

3.1 Softwarequalität 

Definition von Definition 

1 Philip B. Crosby Qualität ist die Erfüllung von Anforderungen 

2 DATEV Qualität ist Kundenzufriedenheit 

3 Thaller Qualität ist Fehlerfreiheit 

4 Weinberg Qualität heißt, die Anforderungen eines Menschen zu erfüllen 

Tabelle 3.1: Verschiedene Definitionen von Qualität (Quelle: [Tha97]) 

Tabelle 3.1 zeigt verschiedene Definitionen von Qualität. Wenn Qualität mit Fehlerfreiheit 

definiert wird, stellt sich zunächst die Frage, wie es überhaupt dazu kommt, dass 

Fehler entstehen: Fehler entstehen prinzipiell in jeder Phase eines Softwareprojekts, beim 

Aufnehmen der Anforderungen, beim Erstellen des Designs und bei der Kodierung der 

Software (vgl. [OU87, Seite 5]). Problematisch dabei ist, dass Fehler in einer frühen Phase 

in der Regel zu Folgefehlern in den darauf folgenden Phasen führen. Wie empirische 

Untersuchungen gezeigt haben, sind solche Fehler, die in späten Phasen der Software- 

Entwicklung oder sogar erst im Betrieb gefunden werden, sehr teuer (vgl. [Sch83, Seite 

61f]). 

Es ist also notwendig, in allen Phasen eines Projekts zu testen und Fehler möglichst 

früh zu erkennen und zu beheben. Das führt aber dazu, dass das Testen einen nicht 

unbeachtlichen Teil am Gesamtaufwand eines Projekts einnimmt und somit zu einem 

9

10 Kapitel 3 Software-Test 

aufwändigen und kostspieligen Prozess wird. Thaller schreibt von 30 bis 50 Prozent des 

Gesamtaufwands, welches das Testen eines Softwareprojekts an Ressourcen verschlingen 

kann (vgl. [Tha02, Seite 49]). 

Die Erfahrungen in der Softwareentwicklung haben gezeigt, dass es praktisch unmöglich 

ist, fehlerfreie Software zu schreiben. Thaller stellte eine interressante Rechnung an, die 

das verdeutlicht: Er nimmt relativ optimistische Fehlerraten an und berechnet damit die 

Anzahl der nicht erkannten schwerwiegenden Fehlern von verschiedenen Softwareprojekten. 

Ein Beispiel ist die Software für das Navigationssystem des Space Shuttles. Obwohl 

die NASA eine der niedrigsten Fehlerraten der Industrie aufweist, muß trotzdem mit 100 

schwerwiegenden Fehlern gerechnet werden, die nicht erkannt werden. Es muß beachtet 

werden, dass dies die Anzahl der Fehler ist, die nach dem Test der Software verbleibt 

(vgl. [Tha02, Seite 17]). 

Für die Qualitätssicherung von Software bedeutet das, dass auch hier ständig Fortschritte 

und Verbesserungen erzielt werden müssen. Nur so kann bei immer größer werdenden 

Softwareprojekten die Qualität sichergestellt werden. Trotzdem muß auch die Wirtschaftlichkeit 

des Testens im Auge behalten werden. Es macht einen Unterschied, ob von 

einer Software Menschenleben abhängen oder ob durch einen Softwarefehler ” 

nur“ Daten 

verloren gehen, die mit etwas Aufwand wiederhergestellt werden können. Entsprechend 

muß der Aufwand abgeschätzt werden, der in das Testen der Software investiert wird. 

3.2 Ausprägungen von Tests 

Softwaretests haben das Ziel, bestimmte Systemparameter zu erzeugen und zu ermitteln. 

Diese Systemparameter werden je nach Ausprägung des Tests auf unterschiedliche Art 

und Weise erzeugt. Sie werden dann mit den eigentlich korrekten Parametern verglichen 

und entsprechend bewertet. Die erwarteten Systemparameter müssen daher eindeutig 

ermittelt werden können (vgl. [Rät04, Seite 34]). Nachfolgend werden verschiedene Arten 

von Tests erläutert und dann mögliche Testszenarien vorgestellt. 

3.2.1 Testarten 

Im folgenden wird auf verschiedene Arten von Tests eingegangen, die für das Qualitätsmanagement 

von CoreBiz sinnvoll erscheinen. 

Verifikation von Konfigurationen 

Diese Art des Tests darf nicht mit Konfigurationstests verwechselt werden, bei denen 

es in der Regel um das Zusammenspiel einer Software mit unterschiedlichen Hardwarekonfigurationen 

geht. Bei der Verifikation von Konfigurationen handelt es sich um

3.2 Ausprägungen von Tests 11 

Tests, die bestimmte Werte in Konfigurationsdateien verifizieren, welche automatisch, 

zum Beispiel durch ein Skript, verändert werden. Für den Test bedeutet das, dass ein 

Programm oder Skript ausführt wird, welches bestimmte Parameter in einer Konfigurationsdatei 

auf einen vorher festgelegten Wert setzt. Dann wird diese Konfigurationsdatei 

beziehungsweise die einzelnen Parameter mit dem erwartetem Ergebnis verglichen. 

Die Tests sind nötig, da sich beispielsweise der Aufbau einer Konfigurationsdatei oder der 

Name eines Parameters ändern kann. Ein Skript, das diese Datei verändern will, würde 

dann eine fehlerhafte Konfiguration hinterlassen. Als Nebeneffekt lassen sich damit auch 

Fehler im Skript selbst aufdecken. 

Funktionstest 

Funktionstests überprüfen das Ergebnis eines Aufrufs eines Programms (vgl. [Tha02, 

Seite 122ff]). Sie setzen die korrekte Konfiguration aller Programme, die am Test beteiligt 

sind, vorraus. Eine korrekte Konfiguration ist aber noch kein Garant für einen 

erfolgreichen Funktionstest. Der Test führt ein Programm aus und vergleicht dessen 

Rückgabewert mit dem erwartetem Ergebnis. Vor der eigentlichen Überprüfung des 

Rückgabewertes werden in der Regel andere Programme oder Skripte ausgeführt, die 

diesen Rückgabewert beeinflussen. 

Stress- und Lasttest 

Wie Boris Beizer bemerkt, werden diese beiden Begriffe sehr oft falsch benutzt und als 

Synonyme verwendet (vgl. [Riv]). Nachfolgend wird versucht, die Unterschiede dieser 

beiden Testarten aufzuzeigen. 

Bei einem Stresstest wird versucht das zu testende Programm extrem zu belasten. Es 

wird dabei keinesfalls erwartet, dass das Programm unter dieser Belastung korrekt weiterarbeitet. 

Das Programm sollte aber zum Beispiel mit einer entsprechenden Fehlermeldung 

abbrechen. Das ist oftmals aber nicht der Fall und das Programm kann abstürzen 

oder Daten beschädigen. 

Beim Lasttest dagegen wird das Programm gleichmäßig über einen längeren Zeitraum 

unter Last gesetzt. Es sollen also die Auswirkungen getestet werden, wenn eine Funktion 

nicht nur einmal ausgeführt wird, sondern über eine bestimmte Dauer ständig 

wiederholt wird. Wenn ein Programm zum Beispiel für eine Funktion Speicher reserviert, 

aber aufgrund eines Fehlers nicht mehr freigibt, dann fällt das beim einmaligen 

Ausführen möglicherweise nicht weiter auf. Durch das ständige Wiederholen würde 

höchstwahrscheinlich aber auch solch ein Fehler erkannt.


Performance Test 

Performance Tests sollen die Geschwindigkeit bestimmter Funktionen des Systems messen. 

Das Besondere an diesem Test ist, dass kein Fehler auftreten muß, sondern nur 

verschiedene Messwerte zurückgeliefert werden. Diese müssen dann entsprechend interpretiert 

werden und zum Beispiel mit Referenzwerten verglichen werden. So kann 

beispielsweise die Performance-Verbesserung zwischen zwei Programmversionen gemessen 

werden. Aber auch die Unterschiede in Bezug auf die Performance beim Einsatz 

verschiedener Hardwarekonfigurationen können so bestimmt werden. 

Weiterhin lassen sich Performance Tests mit Lasttests kombinieren. Es wird also die 

Performance eines Programmes oder einer Funktion unter verschieden großen Lasten 

gemessen. 

3.2.2 Testszenarien 

Tests können auf unterschiedliche Weise durchgeführt werden. Im folgenden wird auf 

diese Szenarien näher eingegangen: 

• Lokaler Test 

• Remote Test 

• Verteilter Test 

Lokaler Test 

Ein lokaler Test wird direkt auf dem Testsystem ausgeführt, die Systemparameter werden 

dort ermittelt und verglichen. Es kann für den Test selbst aber nötig sein, dass 

weitere Systeme im Netzwerk verfügbar sind. Diese Systeme werden allerdings nicht 

vom Testframework kontrolliert oder beeinflusst. 

Lokale Tests haben den Vorteil, dass sie in der Regel auf einem beliebigen System installiert 

und ausgeführt werden können. Im Vergleich zu Remote und verteilten Tests ist 

der Konfigurationsaufwand minimal. Die Ergebnisse können auf dem Testsystem selbst 

ausgewertet werden. Problematisch wird dieser Ansatz, wenn auf mehreren Systemen 

Tests ausgeführt werden sollen. Der Aufwand, um die Ergebnisse auszuwerten steigt in 

diesem Fall deutlich an.

3.2 Ausprägungen von Tests 13 

Remote Test 

Ein Remote Test ist im Prinzip ein lokaler Test, welcher aber von einem zentralen System 

aus gesteuert wird. Dieses System kann auf einem oder mehreren entfernten Systemen die 

Tests ausführen. Die Ergebnisse jedes einzelnen Systems werden dann ebenfalls zentral 

auf diesem System erfasst. Es kann außerdem selbst eines der Systeme sein, auf dem 

Tests ausgeführt werden. Abbildung 3.1 zeigt eine mögliche Testumgebung. 

Server 

Tests 

ausführen 

LAN 

Testsystem 

Testsystem 

Testsystem 

Abbildung 3.1: Remote Test 

Mit diesem Ansatz ist es möglich, einen Test auf unterschiedlichen Systemen gleichzeitig 

auszuführen oder aber auch unterschiedliche Tests auf viele, eventuell sogar identische, 

Systeme zu verteilen. Der größte Vorteil gegenüber lokalen Tests ist die Tatsache, dass 

es nur noch eine zentrale Datei mit Ergebnissen sämtlicher Tests gibt. Allerdings ist der 

Konfigurationsaufwand etwas höher als bei lokalen Tests. Durch Automatisierung kann 

aber dieser Aufwand auf ein Minimum reduziert werden. 

Verteilter Test 

Bei verteilten Tests geht es nicht darum, Tests durch ein Lastverteilungsverfahren auf 

mehrere parallel arbeitende Systeme zu verteilen, um so eine schnellere Durchführung 

der Tests zu ermöglichen. Das ist schon mit Hilfe der Remote Tests möglich. Das Wort 

verteilt“ bezieht sich vielmehr auf den Testfall, der über mindestens zwei Systeme 

” 

verteilt ist. Diese Systeme sind über ein Netzwerk verbunden und können miteinander 

kommunizieren.


Die einzelnen Schritte eines solchen Tests, also die Erzeugung und Ermittlung von Systemparametern, 

müssen zeitlich und inhaltlich aufeinander abgestimmt sein. Das bedeutet, 

dass jeder Schritt vom vorherigen abhängig ist und erst gestartet werden darf, 

wenn dieser abgeschlossen ist. Um diesen zeitlichen Ablauf zu kontrollieren, werden sogenannte 

Synchronisationspunkte verwendet. Die Testsysteme warten dann gegenseitig 

aufeinander, bis jeder an diesem Synchronisationspunkt angelangt ist und fahren erst 

dann mit den weiteren Testschritten fort. Abbildung 3.2 zeigt eine mögliche Testumgebung. 

Server 

Tests 

ausführen 

LAN 

Aktion 1 

Aktion 2 

Testsystem 

Testsystem 

Abbildung 3.2: Verteilter Test 

Verteilte Tests werden benötigt, wenn bestimmte Interaktionen zwischen den Testsystemen 

getestet werden sollen. Damit sind auf den Testsystemen stattfindende Aktionen 

gemeint, die die Interaktion der Systeme beeinflussen. Für die Erzeugung und Ermittlung 

von Systemparametern auf einem System ist es also nötig, dass auf einem anderen 

System in zeitlich koordinierter Abfolge bestimmte Aktionen durchgeführt werden. 

Weiterhin ist es möglich, Nachrichten zwischen den Testsystemen auszutauschen. Das 

heißt, dass es zur Laufzeit des Tests möglich ist, die einzelnen Testschritte zu beeinflussen. 

Es werden also nicht nur die jeweilgen Testschritte nach einem vorgegebenen 

Schema auf den beteiligten Systemen ausgeführt, sondern jeder Testschritt kann vom 

vorherigen beeinflusst werden und darauf reagieren.

3.3 Regressionstest 15 

3.3 Regressionstest 

Regressionstests werden eingesetzt, um eine Regression, also einen Rückschritt beziehungsweise 

eine Verschlechterung einer Software zu erkennen. Das heißt, dass Funktionalitäten 

getestet werden, die in einer älteren Version fehlerfrei waren. Außerdem soll 

verhindert werden, dass alte, eventuell schon behobene Fehler wieder in der Software 

auftauchen. Dazu bietet es sich an, alte Tesfälle zu wiederholen und die Ergebnisse mit 

den früheren Ergebnissen zu vergleichen. 

Die verschiedenen Testarten, die unter Punkt 3.2.1 beschrieben wurden, können prinzipiell 

alle für einen Regressionstest eingesetzt werden. Damit der Aufwand nicht zu groß 

wird, macht es Sinn, sämtliche Tests so weit wie möglich zu automatisieren. Dann ist es 

auch möglich, die Tests regelmäßig, insbesondere vor einem neuen Release, auszuführen. 

Der Aufwand für die Automatisierung darf aber keinesfalls unterschätzt werden (vgl. 

[Rät04, Seite 171]). 

Bei CoreBiz ist der Einsatz von Regressionstests besonders wichtig. Da bei einem CoreBiz 

System unterschiedlichste Software integriert wird, auf die keinen oder nur geringen 

Einfluss ausgeübt werden kann, darf nicht davon ausgegangen werden, dass sich die 

Software absolut gleich wie ihre Vorgängerversion verhält. Durch das Wiederholen von 

Testfällen kann auch diese Software getestet werden und somit läßt sich sicherstellen, 

dass sich diese Software weiterhin wie gewohnt in das System integrieren läßt. 


In diesem Kapitel wurde gezeigt, dass die Qualität von Software eine äußerst wichtige 

Rolle spielt, die nicht unterschätzt werden darf. Diese zu sichern ist die Aufgabe von 

Softwaretests, auf deren verschiedenen Ausprägungen eingegangen wurde. Speziell die 

verteilten Tests stellen dabei ein äußerst interessantes Gebiet dar. Als eine besondere 

Testart sind die Regressionstests zu verstehen. Damit werden zwar kaum neue Fehler 

gefunden, allerdings kann damit die Abwesenheit von Fehlern gezeigt werden. In diesem 

Zusammenhang ist die Automatisierung von Testfällen besonders wichtig. Darauf wird 

detailliert im nächsten Kapitel eingegangen.

16 Kapitel 3 Software-Test

Kapitel 4 

Test-Werkzeuge und Testsuites 

Es gibt sehr viele verschiedene freie und kommerzielle Werkzeuge, die das Testen von 

Software unterstützen. Im Folgenden werden einige dieser Werkzeuge vorgestellt und 

deren Nutzen diskutiert. Besonderes Augenmerk wird auf das Test Environment Toolkit 

gerichtet, welches die Basis für die CoreBiz Testumgebung darstellt. 

4.1 Automatisiertes Testen 

Das Automatisieren von Tests wurde schon im vorherigen Kapitel im Zusammenhang 

mit Regressionstests angesprochen. Es dient in erster Linie dazu, Tests auf einfache Art 

und Weise zu wiederholen, was natürlich gerade bei einem Regressionstest interessant 

ist. Es stellt sich also die Frage, was bei einem Testfall sinnvoll automatisiert werden 

kann und welche Werkzeuge dafür eingesetzt werden können. Dazu muß der Ablauf eines 

Tests betrachtet werden (vgl. [Tha02, Seite 228]): 

• Entwurf der Testfälle 

• Testumgebung vorbereiten 

• Für jeden Testfall folgende Schritte durchführen: 

– Testdaten zur Verfügung stellen 

– Test ausführen 

– Ergebnisse vergleichen und dokumentieren 

– Umgebung wiederherstellen 

• Ergebnisse zusammenfassen 

• Analysieren der Ergebnisse 

17

18 Kapitel 4 Test-Werkzeuge und Testsuites 

Die beiden hervorgehobenen Punkte, der Entwurf von Testfällen und das Analysieren 

der Ergebnisse, sind anspruchsvolle Aufgaben, die in der Regel von einem Menschen 

erledigt werden. Sie lassen sich daher nur bedingt automatisieren. Die anderen Punkte 

eignen sich dagegen sehr gut für die Automatisierung. 

Generell bieten sich Skriptsprachen an, um verschiedene Aufgaben, wie zum Beispiel das 

Zusammenfassen von Ergebnissen, zu erledigen. Speziell unter Unix/Linux ist hier der 

Einsatz von Werkzeugen wie ” 

awk“ , ” 

sed“ , ” 

diff“ etc. sinnvoll. Das Verwenden eines 

Test Management Tools hilft dabei, vor allem die Schritte eines einzelnen Testfalls zu 

automatisieren. Darauf wird später in diesem Kapitel noch detailliert eingegangen. 

Um das Vorbereiten der Testumgebung zu automatisieren, können zum Beispiel Werkzeuge 

zum Klonen von Festplatten einsetzt werden. Mit deren Hilfe kann ein bestimmter 

Zustand eines Testsystems ” 

eingefroren“ und absolut identisch wiederhergestellt werden. 

Eine weitere Möglichkeit ist der Einsatz einer Virtualisierungssoftware. Diese simuliert 

einen kompletten Computer und bietet in der Regel ebenfalls Funktionen an, um einen 

bestimmten Zustand zu speichern und wiederherzustellen. Mit einer Virtualisierungssoftware 

können außerdem Funktionen automatisiert werden, die mit einem realen Computer 

manuell erledigt werden müßten. Dazu gehört zum Beispiel das Einschalten eines Computers. 

Werden diese Möglichkeiten mit Skripten kombiniert, ist es möglich ein System 

auf schnelle und einfache Weise in einen Zustand zu bringen, in dem getestet werden 

kann. 

Trotz diesen Möglichkeiten muß jedoch klar sein, dass sich eine hunderprozentige Automatisierung 

von Tests einerseits nur schwer und mit größtem Aufwand erreichen läßt, 

andererseits aber oft auch nicht sinnvoll ist. Automatisierte Tests bergen verschiedene 

Probleme in sich (vgl. [Tha02, Seite 230] und [Kan02, Seite 102]): 

• Der Aufwand für die Automatisierung ist sehr hoch. 

• Es werden nur wenige neue Fehler entdeckt, da diese schon durch die manuellen 

Tests gefunden werden. 

• Die Wartung der automatischen Tests kann so aufwendig werden, dass ein manueller 

Test sinnvoller ist. 

• Fehler in Tests können in einer automatisierten Umgebung unbeachtet bleiben. 

• Ausführen von veralteten Tests, die zwar in einer älteren Version der Software Sinn 

machten, aber in der aktuellen Version nur Ressourcen und Zeit verschlingen. 

• Konzentration auf Testfälle, die sich leicht in die automatisierte Testumgebung 

einbinden lassen. Die Auswirkung ist eine geringe Testabdeckung.

4.2 Test-Werkzeuge 19 

Rob Savoye, Projektleiter und Entwickler des Test-Frameworks DejaGnu, schreibt in 

einem Usenet-Artikel: 

The higher level code that we used to automate all the testing was never part 

” 

of DejaGnu, and was pretty heavily customized for our own particular setup. 

It worked pretty good, but once we had a few dozen systems, maintaining it 

became close to a full-time job.“ [Savc] 

Er spricht damit genau die Problematik an, die eine Automatisierung von Tests mit sich 

bringen kann. Solange die Testumgebung statisch ist, lassen sich die Testfälle problemlos 

ausführen und wiederholen. Sobald sich aber Systeme verändern oder neue Systeme zur 

Testumgebung hinzugefügt werden, steigt der Aufwand stark an, um die automatisierten 

Tests der neuen Umgebung anzupassen. 

Andere Erfahrungen aus der Praxis zeigen jedoch, dass es sich in den meisten Fällen 

lohnt, Tests zumindest teilweise zu automatisieren (vgl. [Tha02, Seite 239ff]). Das Ziel 

sollte jedoch nicht das Finden von möglichst vielen neuen Fehlern sein, sondern vielmehr 

die Abwesenheit von Fehlern zu zeigen. Wie zu Beginn schon erwähnt, macht die Automatisierung 

von Tests insbesondere im Zusammenhang mit einem Regressionstest Sinn. 

Damit läßt sich dann mit minimalem Aufwand die wichtigsten Funktionalitäten einer 

Software überprüfen. 

4.2 Test-Werkzeuge 

Test-Werkzeuge sind Programme oder Bibliotheken, die bestimmte Funktionalitäten zur 

Verfügung stellen, um den Testprozess zu vereinfachen. Viele dieser Werkzeuge sind 

auf eine bestimmte Aufgabe spezialisiert. Beispielsweise sind GUI Test Tools darauf 

ausgelegt, grafische Benutzerobeflächen zu testen. Unit Test Tools setzen dagegen auf 

einer unteren Ebene an und sind für Komponententests geeignet. 

Unter [Fau] gibt es eine Übersicht über verschiedene Test Werkzeuge, kategorisiert nach 

der Art des Werkzeugs. Speziell für Open Source Werkzeuge gibt es eine Übersicht unter 

[Abe]. 

In der CoreBiz-Testumgebung werden unterschiedliche Arten von Tests ausgeführt. Um 

einen Regressionstest für diese verschiedenen Tests zu realisieren, müssen sie ohne großen 

Aufwand wiederholt werden können. Daher wird ein so genanntes Test Management Tool 

benötigt. Dieses Werkzeug bietet ein Framework, um die Erstellung, das Ausführen und 

die Auswertung von unterschiedlichen Testarten in einer homogenen Art und Weise zu 

ermöglichen. Außerdem hilf es, einen beachtlichen Teil eines Tests zu automatisieren.


4.2.1 Vergleich von Test Management Tools 

Im Folgenden werden einige Test Management Tools untersucht und verglichen. Kriterium 

für die Auswahl war primär die Verfügbarkeit der Software unter Linux. Bei der 

Recherche nach geeigneter Software zeigte sich, dass es für Linux relativ wenig Software 

in diesem Bereich gibt und speziell kommerzielle Software fast überhaupt nicht vorhanden 

ist. Im Gegensatz dazu gibt es für Microsoft Windows eine Vielzahl kommerzieller 

Test-Werkzeuge. Eine Erklärung dafür könnte die Tatsache sein, dass die überwiegende 

Mehrheit an kommerzieller Software unter Windows und für Windows entwickelt wird. 

Dagegen wird Software für Linux meistens von Freiwilligen entwickelt, die kein Geld für 

Testwerkzeuge ausgeben wollen oder können. Daher macht es für die Anbieter kommerzieller 

Test Management Tools wenig Sinn ihre Software für Linux zu entwickeln oder 

zu portieren. 

Nachfolgend wird auf drei verschiedene Test Management Tools näher eingegangen: 

• DejaGnu (vgl. [Sava]) 

• Software Testing Automation Framework (STAF) (vgl. [STA]) 

• Test Environment Toolkit (TET) (vgl. [Theb]) 

DejaGnu 

DejaGnu ist das Test-Framework der Free Software Foundation und ist unter der GNU 

General Public License erhältlich. Entwickelt wird es maßgeblich von Rob Savoye. Entstanden 

ist dieses Projekt durch die Tatsache, dass sein damaliger Arbeitgeber Cygnus 

Solutions ein Test-Framework mit folgenden Eigenschaften benötigte (vgl. [Savb]): 

• Automatisches ausführen von vielen Tests 

• Pattformübergreifend 

• Testen von interaktiven Programmen 

• Testen von batch-orientierten Programmen 

DejaGnu ist in ” 

Expect“ entwickelt, welches wiederum ” 

Tcl“ benutzt. Weiterhin ist es 

speziell darauf ausgelegt, auf so genannten Einplatinenrechnern Tests auszuführen. Diese 

haben oft sehr unterschiedliche Kommunikationsschnittstellen. Deshalb unterstützt 

DejaGnu rsh, rlogin, telnet, tip, kermit und mondfe für die Kommunikation mit entfernten 

Testsystemen. 

Zusammen mit TET ist DejaGnu das einzigste Framework, das den POSIX-Standard 

1003.3 unterstützt (vgl. [Savb]). Diese Spezifikationen definieren, welche Funktionalitäten 

ein Framework aufweisen muß, um POSIX-Konformitätstests durchführen zu 

können. Diese Eigenschaften können aber auch für andere Testfälle genutzt werden.


Software Testing Automation Framework 

Das Software Testing Automation Framework, kurz STAF, wird maßgeblich von IBM 

entwickelt und ist unter der Common Public License (CPL) lizenziert. Es wird viel Wert 

darauf gelegt, dass es nur minimale Leistungsanforderungen sowohl an die Hardware als 

auch an die Software stellt. 

Sämtliche Funktionalitäten sind bei STAF in so genannten Services ausgelagert. Neben 

einer großen Anzahl von Standard-Services, die beispielsweise das Logging durchführen, 

können beliebige weitere Services erstellt werden. Dadurch läßt sich STAF sehr einfach 

erweitern. 

Interessant ist auch das Konzept der so genannten ” 

Trust Levels“ von STAF. Mit ihnen 

lassen sich bestimmte Rechte auf den Testsystemen definieren. So kann zum Beispiel 

verhindert werden, dass Dateien auf einem bestimmten System gelöscht werden oder das 

System heruntergefahren wird. Die Einstellungen können per System oder per Benutzer 

durchgeführt werden. 

Test Environment Toolkit 

Das Test Environment Toolkit, kurz TET, ist ein plattformunabhängiges Test-Framework 

von ” 

The Open Group“. ” 

The Open Group“ ist ein herstellerunabhängiges Konsortium, 

dem beispielsweise Unternehmen wie Hewlett-Packard, IBM oder Sun Microsystems angehören. 

Dieses Konsortium war unter anderem auch an der Entwicklung der POSIX- 

Spezifikationen und des Lightweight Directory Access Protocol beteiligt. 

Das Test Environment Toolkit bietet Schnittstellen zu einer Vielzahl von Programmiersprachen 

und ist sowohl in einer freien, als auch in einer kommerziellen Version verfügbar. 

Ein besonderes Merkmal ist die Möglichkeit verteilte Tests durchzuführen. 

Neben der kommerziellen Version ” 

TETware“ ist das Test Environment Toolkit in zwei 

Varianten unter der ” 

Artistic License“ verfügbar. Zum Zeitpunkt des Schreibens dieser 

Arbeit wurden folgende Versionen veröffentlicht: 

• ” 

TET-Lite“ in der Version 3.6 

• Ein sogenanntes ” 

full source release“, das sowohl ” 

TET-Lite“ als auch ” 

Distributed 

TET“ in der Version 3.3 enthält 

Der Unterschied zwischen diesen beiden Versionen besteht im wesentlichen in der Einschränkung, 

Remote oder verteilte Tests in der Lite Version durchzuführen.


Features STAF Dejagnu TET 

Open Source ja ja ja 

Lizenz CPL GPL Artistic 

Gleiches Front-End für alle Tests ja ja ja 

Einheitliches Format für Ergebnisse ja ja ja 

Testfälle können X mal wiederholt werden nein nein ja 

Testfälle können eine bestimmte Zeit lang wiederholt 

nein nein ja 

werden 

Testfälle können zufällig ausgewählt werden nein nein ja 

Remote Tests ja ja ja 

Verteilte Tests nein nein ja 

Plattformübergreifend ja ja ja 

POSIX TM 1003.3 konform nein ja ja 

Logging Eigenschaften ja ja ja 

Debugging Eigenschaften ja ja ja 

Datenbank für Ergebnisse nein nein nein 

Dateien über das Netzwerk kopieren ja ja nein 

Security Eigenschaften ja nein nein 

Rückgabe von komplexen Datenstrukturen (Marshalling) 

ja nein nein 

Tabelle 4.1: Vergleich von Test Management Tools 

Fazit 

Die Tabelle 4.1 zeigt einen Überblick über die Features dieser Werkzeuge (vgl [Lin]). 

Alle drei Werkzeuge verfügen über die nötigen Funktionen, mit denen es prinzipiell 

möglich ist, eine größere Anzahl von Tests, auch auf entfernten Systemen, durchzuführen. 

STAF kann besonders durch die einfach erweiterbaren Services beeindrucken, was das 

Framework sehr flexibel macht. Die Entscheidung fiel schließlich aber zugunsten des Test 

Environment Toolkit aus. Die Gründe dafür waren: 

• Verteilte Tests sind möglich. 

• Das Framework wird bereits seit September 1989 von ” 

The Open Group“ entwickelt 

und gilt als sehr stabil und ausgereift. 

• Innerhalb des Unternehmens gibt es schon Erfahrungen mit TET. 

• Die Testsuites der Linux Standard Base basieren ebenfalls auf TET 

Nachfolgend wird noch einmal detailliert auf das Test Environment Toolkit eingegangen.


4.2.2 Test Environment Toolkit 

Im folgenden werden allgemein die Funktionen und Besonderheiten von Distributed TET 

erläutert. Dennoch sollte es abgesehen von der Einschränkung, Remote oder verteilte 

Tests durchzuführen, keine wesentlichen Unterschiede zu TET-Lite geben. 

Überblick 

Testsystem 1 Testsystem 2 

Testsystem 3 

Test Case Controller 

Test Case 

Controller Daemon 

Test Case 


Test Case 


Test Case 

Manager 

Test Case 

Manager 

Test Case 

Manager 

Abbildung 4.1: Die Komponenten von TET 

Ein Test wird immer durch das Programm ” 

tcc“, dem Test Case Controller ausgelöst. Es 

gibt drei verschiedene Modi: ” 

Build“, ” 

Execute“ und ” 

Clean“. Der Test Case Controller 

verteilt diesen Auftrag an den Test Case Controller Daemon ( ” 

tccd“) aller beteiligten 

Systeme. Der Test Case Manager (TCM) wird implizit durch das Benutzen einer der 

TET-APIs eingebunden und kümmert sich um den Ablauf der Test Cases (Testfälle). 

Abbildung 4.1 zeigt, wie ein Test in der TET-Umgebung gestartet wird. Interessant 

dabei ist, dass nahezu beliebig viele weitere Testsysteme hinzugefügt werden können. 

Das System, auf dem der Test Case Controller gestartet wird, muß nicht zwingend den 

Test selbst ausführen. 

Aufbau eines Testfalls 

Ein Test Case besteht aus einem oder mehreren so genannter Invocable Components 

(IC). Diese wiederum bestehen aus einem oder mehreren Test Purposes (TP). Abbildung 

4.2 zeigt den Aufbau eines Testfalls.


Test Case 

Invocable 

Component 1 

Invocable 

Component 2 

Test Purpose 1 


Test Purpose ... 



Test Purpose ... 

Abbildung 4.2: Aufbau eines Testfalls im TET 

Direktiven 

Neben dem simplen Ausführen eines Tests bietet das Test Environment Toolkit so genannte 

Direktiven an. Teilweise können diese miteinander kombiniert werden. So ist es 

zum Beispiel möglich einen zufällig ausgewählten Test auf einem bestimmten entfernten 

System genau acht mal zu wiederholen. In der Konfigurationsdatei ” 

tet scen“ werden 

diese Direktiven zusammen mit den Testfällen aufgelistet. Die wichtigsten Direktiven 

sind: 

• :repeat: - Einen Test eine bestimmte Anzahl lang wiederholen 

• :timed loop: - Einen Test eine bestimmte Zeit lang wiederholen 

• :random: - Einen zufälligen Test ausführen 

• :parallel: - Tests parallel (gleichzeitig) ausführen 

• :remote: - Tests auf entfernten Systemen durchführen 

• :distributed: - Verteilte Tests auf entfernten Systemen durchführen 

Die Direktiven :remote: und :distributed: benötigen als Parameter eine dreistellige System 

ID. Jedem System auf dem Tests ausgeführt werden können, ist solch eine ID zuge-


wiesen. Der Test Case Controller kann diese ID dann mit Hilfe der Konfigurationsdatei 

systems“ zu einer entsprechenden IP-Adresse eines Testsystems auflösen. 

” 

Die nachfolgende Szenario-Datei beschreibt einen verteilten Test, der auf zwei Testsystemen 

(001 und 002) ausgeführt wird. 

all 

"starting LDAP tests" 

:distributed,001,002: 

:repeat,1000:@/ldap-latenz/ldap-latenz 

:/ldap-performance/ldap-performance 

:timed_loop,3600:@/ldap-konflikt/ldap-konflikt 

:enddistributed: 

"LDAP tests finished" 

Das Journal 

Nachdem ein Testfall abgeschlossen ist, werden die Ergebnisse in der Datei ” 

journal“ 

abgespeichert. Diese Datei ist unabhängig vom Test immer gleichartig aufgebaut und 

kann dadurch einfach, zum Beispiel durch Skripte, weiter bearbeitet werden. Nachfolgend 

ein kleiner Ausschnitt eines Journals: 

10|4 /ldap-latenz/ldap-latenz 16:48:17|TC Start, scenario ref 5-1 

15|4 3.3 1|TCM Start 

400|4 1 1 16:48:17|IC Start 

200|4 1 16:48:17|TP Start 

520|4 1 00226816 1 1|sync 1 OK (client) 

520|4 1 00128614 1 2|sync 1 OK (base) 

520|4 1 00226816 1 4|delay = 7055 microseconds = 7 milliseconds 

220|4 1 0 16:48:17|PASS 

410|4 1 1 16:48:17|IC End 

80|4 0 16:48:18|TC End, scenario ref 5-1 

Die Zeilen, die beispielsweise mit 520 beginnen, sind Meldungen, die die Test Purposes 

auf den verschiedenen Systemen selbst ausgeben können. Die Nummer 220 bedeutet 

dagegen, dass diese Zeile das Ergebnis des Test Purpose enthält. Es kann also jede Zeile 

auf einfache Weise interpretiert werden. Eine ausführliche Beschreibung des Aufbaus 

eines Journals können in der TETware User Guide beziehungsweise in der TETware 

Programmers Guide gefunden werden (vgl. [Thed] und [Thec]).


4.3 Testsuites 

Eine Testsuite ist eine Sammlung von Testfällen. Es ist möglich, dass die einzelnen 

Tesfälle einer Testsuite aufeinander aufbauen. Obwohl eine Testsuite immer aus einzelnen 

Tesfällen besteht, kann diese dann nur im Verbund ausführt werden. Diese Abhängigkeit 

sollte aber so weit wie möglich verhindert werden, um jeden Testfall auch individuell 

ausführen zu können (vgl. [Rät04, Site 193]). 

Nachfolgend werden die Testsuites der Linux Standard Base und die für CoreBiz geplanten 

Testsuites vorgestellt. 

4.3.1 Linux Standard Base Testsuites 

Das Linux Standard Base Project (vgl. [Frec]) definiert verschiedene Spezifikationen 

mit dem Ziel, die verschiedenen Linux Distributionen hinsichtlich der Dateisystemstruktur 

und der Basisbibliotheken zu vereinheitlichen, um eine zu starke Zersplitterung 

zu vermeiden. Die Spezifikationen beinhalten teilweise auch POSIX-Spezifikationen. 

Um diese Spezifikationen zu überprüfen, stellt das Projekt folgende Testsuites frei zur 

Verfügung: 

• Filesystem Hierarchy Specification Tests 

• POSIX.1 Conformance Tests 

• POSIX thread (pthread) Conformance Tests 

• Linux Operating System Calls Test 

Die Tests bauen auf das Framework VSXgen auf, welches wiederum auf TET-Lite basiert. 

VSXgen ist ein Framework, das Betriebssystemfunktionen abstrahiert und in verschiedenen 

Bibliotheken zur Verfügung stellt. 97% dieser Tests wurden von ” 

The Open Group“ 

entwickelt (vgl. [Thea]). Das ist damit zu erklären, dass ” 

The Open Group“ schon sehr 

lang Testsuites für die POSIX Konformität anbietet. Diese Testsuites waren ehemals 

nur gegen sehr teure Lizenzgebühren erhältlich. Heute werden sie aber unter einer freien 

Lizenz zur Verfügung gestellt. 

4.3.2 CoreBiz Testsuites 

Eine kleinere Testsuite mit verschiedenen lokalen Tests existiert bereits. Diese wurden 

wie die Tests der LSB mit Hilfe von TET-Lite entwickelt. 

Geplant ist eine weitere Testsuite, die mit Hilfe von Distributed TET auf beliebig vielen 

entfernten Testsystemen ausführbar ist. Es ist denkbar, dass diese Testsuite die bereits 

existierende Testsuite integriert. Interessant ist die Frage, ob es eine Möglichkeit gibt,

4.4 Zusammenfassung 27 

auch die LSB Testsuites zu integrieren. Dieser Ansatz wird im Kapitel ” 

CoreBiz Testsuite 

- Remote Tests“ diskutiert. 

Speziell für die verteilten Tests wird eine weitere Testsuite erstellt. Diese enthält Testfälle, 

die in der Regel auf zwei Systemen, einem CoreBiz Base Server und einem CoreBiz Client 

ablaufen. Im Kapitel ” 

CoreBiz Testsuite - Verteilte Tests“ wird detailliert auf dieses 

Thema eingegangen. 


In diesem Kapitel wurde auf Möglichkeiten der Automatisierung von Tests eingegangen. 

Das führt zu der Erkenntnis, dass Testwerkzeuge benötigt werden, um dies realisieren 

zu können. Testwerkzeuge bieten aber noch eine ganze Reihe weiterer Vorteile, wie zum 

Beispiel die einheitliche Darstellung von Testergebnissen. Für die CoreBiz-Testumgebung 

werden für die Regressionstests einerseits Werkzeuge für die Automatisierung benötigt, 

andererseits aber vor allem ein Test Management Tool, um verschiedenste Tests in einem 

homogenen Rahmen durchzuführen. Dafür wurde das Test Environment Toolkit gewählt, 

welches sich vor allem durch die Möglichkeit verteilte Tests durchzuführen von anderen 

Frameworks hervorhebt.

28 Kapitel 4 Test-Werkzeuge und Testsuites

Kapitel 5 

CoreBiz Testsuite - Remote Tests 

In diesem Kapitel wird auf die Implementierung des Test-Frameworks eingegangen. Es 

wird diskutiert, ob und wie die schon vorhandenen Tests der Linux Information Systems 

AG und die Testsuites der Linux Standard Base integriert werden können. Weiterhin wird 

der Aufbau einer Testumgebung erläutert, die es erlaubt Remote Tests auszuführen. Die 

prototypische Implementierung eines Testfalls veranschaulicht die Thematik. 

5.1 Ausgangssituation 

Für die Qualitätssicherung von CoreBiz wurden bisher die Testsuites der Linux Standard 

Base eingesetzt. Diese Tests basieren auf den Frameworks TET-Lite und VSXgen. 

Zusätzlich sind selbst entwickelte Tests vorhanden, die allerdings wie die Testsuites der 

LSB nur lokal auf einem Testsystem ausgeführt wurden. Diese Tests sind ebenfalls mit 

Hilfe von TET-Lite implementiert. 

5.2 Aufbau der Testumgebung 

Nachfolgend werden die Komponenten vorgestellt, die für den Aufbau der Testumgebung 

benötigt werden. 

5.2.1 TET-Lite vs. Distributed TET 

Für das Design der Testumgebung mit Hilfe des Test Environment Toolkits können im 

Prinzip zwei Möglichkeiten in Erwägung gezogen werden. Damit verknüpft ist allerdings 

auch die Frage, ob und wie die bisherigen CoreBiz-spezifischen Testfälle und die Testsuites 

der LSB integriert werden können. Hier muß sich noch einmal klar gemacht werden, 

dass mit TET-Lite ausschließlich lokale Tests möglich sind. Distributed TET dagegen 

erlaubt das Ausführen von Remote Tests und verteilten Tests. 

29

30 Kapitel 5 CoreBiz Testsuite - Remote Tests 

Die erste Variante würde die Erweiterung der bisherigen Testsuite bedeuten. Testfälle 

würden also mit Hilfe des Frameworks TET-Lite und optional VSXgen implementiert 

werden. Das hätte den Vorteil, dass diese Testsuite und die Testsuites der LSB sich in der 

gleichen Testumgebung ausführen lassen würden. Es müßte also die bisherige Testumgebung 

nicht verändert werden. Der Nachteil ist allerdings, dass so auf die Möglichkeiten 

von Distributed TET verzichtet wird. Um Tests auf entfernten Systemen durchführen 

zu können, müßte ein weiteres Framework entwickelt werden. Beispielsweise wäre vorstellbar, 

dass Tests mit Hilfe von ssh (Secure Shell) gestartet werden und die Ergebnisse 

mittels scp (Secure Copy) oder NFS (Network File System) an eine zentrale Stelle kopiert 

werden. 

Die zweite Variante, die schließlich auch implementiert wurde, setzt dagegen auf Distributed 

TET auf. Der größte Vorteil ist sicherlich, dass damit ein Framework zur 

Verfügung steht, dass Tests auf beliebig vielen entfernten Systemen grundsätzlich zuläßt. 

Weiterhin ist so auch gewährleistet, dass verteilte Tests in dieser Umgebung implementiert 

werden können. Allerdings muß hier die Frage gestellt werden, ob und wie die schon 

vorhandenen Testsuites in die neue Umgebung integriert werden können. 

Als problematisch stellt sich dabei das Framework VSXgen heraus, welches nur für TET- 

Lite verfügbar ist. Für die CoreBiz-spezifische Testfälle ist das nicht von Bedeutung, 

da die Funktionalitäten dieses Frameworks bisher nicht genutzt wurden. Da VSXgen 

hauptsächlich grundlegende Betriebssystemfunktionen in einer abstrahierten Form zur 

Verfügung stellt, ist es im Hinblick auf die Zukunft eher unwahrscheinlich, dass diese 

Funktionen von Testfällen aus den CoreBiz Testsuites benötigt werden. 

Die Testsuites der LSB sind jedoch ohne VSXgen nicht ausführbar. Für die Integration 

der LSB-Testsuites wäre also die Portierung dieses Frameworks auf Distributed TET 

nötig. Das wäre zwar mit etwas Aufwand durchaus möglich, dennoch ist dieser Schritt 

und der damit verbundene Aufwand nicht unbedingt notwendig. Die Testsuites der LSB 

haben ein ganz anderes Ziel als die CoreBiz Testsuites. Mit ihnen werden keine neuen 

Fehler in Produkten gefunden. Es kann damit aber gezeigt werden, dass CoreBiz-Systeme 

gewisse Standards und Spezifikationen einhalten. Während es bei CoreBiz-spezifischen 

Tests je nach Testart Sinn macht, diese möglichst oft und regelmäßig durchzuführen, ist 

es bei den Tests der LSB ausreichend, diese zum Beispiel vor einem neuen Release durchzuführen. 

Sie werden also nicht direkt für die Produktentwicklung benötigt und müssen 

deshalb auch nicht so häufig ausgeführt werden. Weiterhin werden die Testsuites der 

LSB nicht von der Linux Information Systems AG entwickelt. Es darf daher nicht davon 

ausgegangen werden, dass zukünftige Versionen der Testsuites kompatibel zur jetzigen 

Testumgebung sind. Von diesen Gesichtspunkten aus betrachtet, ist es vertretbar und 

sinnvoll, die LSB und CoreBiz Testsuites weitestgehend unabhängig voneinander auszuführen. 

Im Vordergrund sollten die Anforderungen für die CoreBiz Testsuites stehen 

und das Framework sollte maßgeblich danach ausgerichtet sein.

5.2 Aufbau der Testumgebung 31 

5.2.2 Virtualisierungssoftware 

Basis der Testumgebung ist der CoreBiz Factory Server. Auf diesem System werden dann 

mit Hilfe der Software ” 

VMware Workstation“ ein oder mehrere Testsysteme ” 

virtuell“ 

aufgesetzt. Dieser Ansatz bringt verschiedene Vorteile mit sich: 

• Es muß keine weitere Hardware für Testssysteme angeschafft werden 

• Es können beliebig viele weitere Systeme hinzugefügt werden 

• Mit Hilfe so genannter Snapshots kann ein bestimmter Zustand eines Systems 

eingefroren werden 

• Systeme können schnell und einfach dupliziert werden 

• Verschiedene Aktionen wie zum Beispiel das Einschalten eines Rechners, die normalerweise 

manuell durchgeführt werden müßten, können automatisiert werden. 

Abbildung 5.1 zeigt den Aufbau einer Testumgebung für Remote Tests, die mit Hilfe 

von VMware und Distributed TET realisiert wurde. Die Testumgebung ist im Prinzip 

frei skalierbar. Eine Einschränkung setzen nur die TET System IDs, die von 000 bis 

999 vergeben werden können und natürlich die Leistungsfähigkeit der Hardware, auf der 

VMware installiert ist. 


Test Case 

Control Daemon 

VMware 

LAN 

Test Case 


Test Case 


Test Case 


Testsystem 1 

(Bsp.: CoreBiz Base) 

Testsystem 2, optional 

(Bsp.: CoreBiz Client) 

Weitere Testsysteme, 

optional 

Abbildung 5.1: Aufbau der CoreBiz Testumgebung für Remote Tests


Eine Virtualisierungssoftware bringt allerdings auch Probleme mit sich. Auf diese wird im 

Zusammenhang mit verteilten Tests im nächsten Kapitel noch detailliert eingegangen. 

5.2.3 Konfiguration der Systeme 

Das Test Environment Toolkit installiert sich standardmäßig in das Verzeichnis 

/home/tet. Da bei einem CoreBiz System die Benutzerverzeichnisse in der Regel per 

NFS über das Netzwerk bezogen werden, würde das zu Problemen führen. Damit sichergestellt 

werden kann, dass sich TET auf einer lokalen Festplatte befindet, wird es in 

das Verzeichnis /opt/tet-full installiert. Dazu wurde ein entsprechendes Debian-Paket 

erstellt, das neben den Programmen und den Bibliotheken von TET außerdem ein Startskript 

für den Test Case Controller Daemon enthält. Bei der Installation dieses Pakets 

werden automatisch der Benutzer und die Gruppe ” 

tet“ angelegt. Um das Test Environment 

Toolkit einsetzen zu können, muß nur noch die Datei ” 

systems.equiv“ auf 

dem Testsystem beziehungsweise die Datei ” 

systems“ auf dem CoreBiz Factory Server 

angepaßt werden. 

Für jede Testsuite gibt es ebenfalls ein eigenes Debian-Paket. Dieses installiert die zugehörigen 

Testfälle unterhalb des Verzeichnisses /opt/tests//. 

Da es bestimmte Tests geben kann, die nicht auf allen CoreBiz Systemen ausgeführt 

werden können, ist es notwendig, innerhalb der Testumgebung standardisierte TET-ID- 

Nummern zu vergeben. Dann kann die Szenario-Datei schon beim Erstellen des Tests 

entsprechend konfiguriert werden, so dass der Test nur auf bestimmten Systemen gestartet 

wird. Wichtig wird dieser Punkt auch im Hinblick auf verteilte Tests. 

ID CoreBiz System 

000 CoreBiz Factory 

001 CoreBiz Base 

002 CoreBiz Client 

003 

bis 

009 CoreBiz Backup) 

ab 

010 

reserviert für bestimmte 

CoreBiz Systeme (Beispiel: 

für beliebig weitere Testsysteme 

nutzbar 

Tabelle 5.1: Zuweisung von TET-IDs zu CoreBiz Systemen 

Tabelle 5.1 zeigt die Zuweisung von IDs zu den jeweiligen CoreBiz Systemen. ID 000 ist 

immer für den CoreBiz Factory Server reserviert, von dem aus sämtliche Tests gestartet 

werden, auf dem selbst aber in der Regel keine Tests ablaufen. ID 001 und 002 werden 

für den CoreBiz Base Server beziehungsweise den CoreBiz Client reserviert. Die IDs 

003 bis 009 werden vorerst für Systeme wie zum Beispiel dem CoreBiz Backup Server

5.3 Ablauf eines Testfalls 33 

reserviert, für die zur Zeit aber noch keine speziellen Testfälle existieren. Alle weiteren 

IDs können beliebig für zusätzliche Testsysteme benutzt werden. 

Ein weiteres Problem ist die Notwendigkeit bestimmte Programme mir root-Rechten 

auszuführen. Der Test Case Control Daemon und damit auch die Tests werden aber 

standardmäßig als Benutzer ” 

tet“ ausgeführt. Das Problem kann am einfachsten mit 

Hilfe des Programms ” 

sudo“ gelöst werden. Durch den Eintrag der Zeile 

tet ALL = NOPASSWD: ALL 

in /etc/sudoers können alle Programme als Benutzer root ausgeführt werden. 

5.3 Ablauf eines Testfalls 

Der Testprozess läßt sich in drei Phasen beschreiben: 

• Phase 1 - Installation: 

Die Testsysteme werden weitestgehend automatisch über das Netzwerk installiert. 

In der Regel wird ein CoreBiz Base Server und ein CoreBiz Client als Testsystem 

dienen, aber es können natürlich prinzipiell alle CoreBiz Systeme verwendet werden. 

Dannach muß TET und die CoreBiz Testsuite installiert werden und unter 

Umständen die Konfiguration von TET angepaßt werden. Dieser Schritt kann in 

Zukunft sicherlich auch relativ einfach automatisiert werden. Aus den verschiedenen 

CoreBiz Profilen könnte jeweils ein entsprechendes Testprofil generiert werden, 

das eine zusätzliche Komponente mit TET, den CoreBiz Testsuites und eventuell 

sogar eine passende Konfiguration enthält. 

• Phase 2 - Testing: 

Nach der Installation sollte auf allen Testsystemen der Test Case Controller Daemon 

aktiv sein. Nun kann festgelegt werden, auf welchen Testsystemen überhaupt getestet 

werden soll beziehungsweise welche Testfälle auf den verschiedenen Testsystemen 

ausgeführt werden sollen. Dazu kann die Szenario-Datei angepaßt werden. 

Standardmäßig wird die vollständige Testsuite ausgeführt. Die Testfälle werden 

dann vom CoreBiz Factory Server aus mit Hilfe des Test Case Controllers gestartet. 

Die Tests selbst werden automatisch ausgeführt und die Ergebnisse zentral 

auf dem Server abgelegt. 

• Phase 3 - Reporting: 

Für die Auswertung der Journale kann beispielsweise das Perl-Skript ” 

tetreport.pl“ 

benutzt werden, das von TET mitgeliefert wird. Dieses Skript erstellt einen kurzen 

Report über die erfolgreichen und fehlgeschlagenen Testfälle. Für bestimmte Tests, 

etwa einen Performance Test, muß das Journal aber weitergehend ausgewertet 

werden. Es müssen zum Beispiel bestimmte Werte extrahiert und Berechnungen


durchgeführt werden. Das kann in der Regel durch kleine SHELL-Skripte erledigt 

werden. 

5.4 Testarten 

Nachfolgend wird erläutert, wie verschiedene Testarten in dieser Umgebung realisiert 

werden können. Die theoretischen Hintergründe dazu sind im Kapitel ” 

Softwaretest“ 

unter Punkt 3.2.1 zu finden. 

Remote Tests unterscheiden sich prinzipiell nicht von lokalen Tests. Zu Remote Tests 

werden sie allein durch das Benutzen der Direktive ” 

:remote:“ (vgl. 4.2.2). Die Tests 

selbst enthalten also keinen Quellcode, der darauf hinweist, dass die Tests auf entfernten 

Systemen ausgeführt werden können. Alle Testfälle sollten daher auch problemlos lokal 

ausgeführt werden können. Selbst das Verwenden von TET-Lite anstatt Distributed 

TET sollte möglich sein. 

5.4.1 Verifikation von Konfigurationen 

Diese Tests haben das Ziel, bestimmte Konfigurationsdateien zu verifizieren. Dabei geht 

es speziell um solche Konfigurationsdateien, die von den cfengine-Skripten verändert 

werden. Es wurden schon einige Tests dieser Art in der bisherigen Testumgebung unter 

Verwendung von TET-Lite erstellt. Der Aufwand für das Portieren der Tests sollte relativ 

gering sein, da Distributed TET alle Funktionalitäten von TET-Lite besitzt. 

Bei dieser Art von Testfall wird zuerst cfengine mit der Standardumgebung ausgeführt, 

um sicherzustellen, dass das System keinen undefinierten Zustand hat. Die entsprechenden 

Konfigurationsdateien werden geprüft und cfengine dann mit der Testumgebung 

ausgeführt. Wieder werden die Konfigurationsdateien geprüft. Danach wird die Standardumgebung 

wiederhergestellt. Wenn nach allen drei Durchläufen von cfengine die 

Konfigurationsdateien dem erwartetem Ergebnis entsprechen, gilt der Test als erfolgreich 

bestanden (PASS). 

Das Überprüfen der Konfigurationsdateien läßt sich mit Hilfe des Werkzeugs ” 

diff“ realisieren. 

Es muß dazu eine Datei mit dem erwartetem Ergebnis existieren. Diese wird 

dann mit der veränderten Konfigurationsdatei verglichen. Gibt es keine Unterschiede, 

dann ist der Testschritt bestanden. 

Die Verifikation einer Konfigurationsdatei läuft im wesentlichen nach folgendem Schema 

ab: 

• cfengine mit der Parameterisierung für die Standardumgebung ausführen 

• Konfigurationsdatei(en) mit dem erwartetem Ergebnis vergleichen 

• cfengine mit der Parameterisierung für die Testumgebung ausführen

5.4 Testarten 35 




• Testergebnis: PASS / FAIL 

5.4.2 Funktionstests 

Die Verifikation von Konfigurationsdateien sind einerseits sehr nützlich, um eine korrekte 

Manipulation von Konfigurationsdateien durch cfengine-Skripte sicherzustellen. Andererseits 

stoßen diese Tests schnell an ihre Grenzen. So kann es durchaus sein, dass es 

mehrere cfengine-Skripte gibt, die dieselbe Konfigurationsdatei verändern. Je nachdem 

welche Komponente installiert ist, kann das Ergebnis dann unterschiedlich ausfallen. 

Der weitaus größte Nachteil dieser Tests ist jedoch, dass korrekte Konfigurationsdateien 

nicht automatisch zu einem korrekt funktionierendem System führen. Um die Funktionalität 

bestimmter Dienste oder Programme zu gewährleisten, müssen diese selbst getestet 

werden. 

Bei den Funktionstests kann generell zwischen zwei Varianten unterschieden werden. 

Die einfachere Variante sind Tests, die eine Funktion oder ein Programm aufrufen und 

ein bestimmtes, statisches Ergebnis erwarten. Das könnten zum Beispiel Tests sein, die 

nach der Installation eines Systems verschiedene Basisfunktionalitäten überprüfen. Auf 

einem CoreBiz Base Server könnte beispielsweise getestet werden, ob alle notwendigen 

Administrationswerkzeuge auf dem System installiert sind. 

Konfigurationsunabhängige Funktionstests laufen nach folgendem Schema ab: 

• Funktion/Programm ausführen 

• Ergebnis mit erwartetem Ergebnis vergleichen 


Die zweite Variante geht davon aus, dass sich das Ergebnis eines Funktions- oder Programmaufrufs 

verändert, wenn bestimmte Konfigurationsparameter verändert werden. 

So ist es möglich, dass das Ergebnis eines Programmaufrufs von verschiedenen korrekt 

parameterisierten Konfigurationsdateien abhängt. Durch den Aufruf von cfengine mit einer 

entsprechenden Testumgebung kann dieses Ergebnis beeinflusst werden. Der Aufruf 

eines Programms kann also vorraussetzen, dass eine ganze Reihe von anderen Programmen 

oder Diensten korrekt konfiguriert sein muß. Hier zeigt sich dann der große Vorteil 

gegenüber der Verifikation von Konfigurationen. Es müßten unzählige Testfälle erstellt 

werden, um sämtliche Konfigurationsdateien zu überprüfen.


Der Ablauf von konfigurationsabhängigen Funktionstests ist dem Ablauf der Verifikation 

von Konfigurationen sehr ähnlich. Er sieht folgendermaßen aus: 


• Funktion/Programm ausführen, Ergebnis speichern 

• cfengine mit der Parameterisierung für die Testumgebung ausführen 

• Funktion/Programm ausführen 

• Ergebnis mit erwartetem Ergebnis vergleichen 


• Funktion/Programm ausführen und mit dem gespeicherten Ergebnis vergleichen 


5.4.3 Performance Tests 

Neben der Verifikation von Konfigurationen und den Funktionstests, die sicherlich am 

häufigsten eingesetzt werden, können auch Performance Tests sinnvoll angewendet werden. 

Vorstellbar wäre hier der Test von verschiedenen Diensten wie zum Beispiel der 

Zugriff auf Dateien via NFS. Es könnten in diesem Zusammenhang aber auch grundlegende 

Systemeigenschaften wie die Performance der Festplatte oder des Netzwerks 

getestet werden. Um Funktionen oder Programme unter Last zu testen bietet sich die 

Direktive ” 

:parallel:“ an. Damit lassen sich zwei Tests auf einem System gleichzeitig starten. 

Weiterhin ist es in vielen Fällen interessant die Performance eines Programms mit 

unterschiedlichen Konfigurationen zu testen. In diesem Fall muß der Test entsprechend 

vorbereitet werden und Konfigurationsdateien angepaßt werden. Performance Tests laufen 

nach folgendem Schema ab: 

• Umgebung vorbereiten (falls nötig) 

• Messung starten 

• Funktionen oder Programme ausführen 

• Messung stoppen 

• Umgebung wiederherstellen 

• Journal auswerten 

Eine Besonderheit von Performance Tests ist die Auswertung des Journals. Testfälle 

liefern in der Regel nicht das übliche PASS oder FAIL zurück, sondern verschiedene 

Messwerte. Diese müssen dann, zum Beispiel mit SHELL-Skripten, aus den Journalen 

extrahiert und mit Referenzwerten verglichen werden.

5.5 Ein prototypischer Testfall 37 

5.5 Ein prototypischer Testfall 

Dieser prototypisch implementierte Testfall soll die Möglichkeiten des Test Environment 

Toolkit zeigen. Er wurde mit Hilfe der SHELL-API von TET erstellt. 

5.5.1 Ziel 

Bei diesem Testfall soll überprüft werden, ob der Hostname eines CoreBiz Systems korrekt 

durch die cfengine-Skripte verändert wird. Dieser wird bei einem CoreBiz System in 

einer CoreBiz-eigenen Konfigurationsdatei durch den Parameter ” 

hostName“ definiert. 

Der Hostname soll mit Hilfe des Programms ” 

hostname“ überprüft werden. Es handelt 

sich also um einen konfigurationsabhängigen Funktionstest. 

5.5.2 Implementierung 

Um einen definierten Zustand des Systems zu erhalten wird zu allererst ein Aufruf von 

cfengine mit der Standardkonfiguration durchgeführt. Dann wird der aktuelle Hostname 

des Systems abgespeichert und cfengine mit einer Testkonfiguration aufgerufen. Diese 

Konfiguration ist bis auf den Parameter ” 

hostName“ identisch mit der Standardkonfiguration. 

Es wird nun erwartet, dass nach dem Durchlauf von cfengine der Befehl ” 

hostname“ 

den entsprechenden Wert der Testkonfiguration zurückliefert. Danach wird wieder 

die Standardkonfiguration aktiviert und der Hostname des Systems mit dem am Anfang 

des Tests abgespeicherten Wert verglichen. Abbildung 5.2 zeigt ein Flussdiagramm, dass 

den Ablauf veranschaulicht. 

Bei der Implementierung des Tests zeigte sich, dass es einige Funktionen gibt, die wahrscheinlich 

in gleicher oder ähnlicher Form in anderen Testfällen ebenfalls benötigt werden. 

Dazu gehört zum Beispiel das Aufrufen von cfenigne mit der Testkonfiguration 

beziehungsweise der Standardkonfiguration. Daher wurde begonnen eine Bibliothek für 

diese wiederverwendbaren Funktionen zu erstellen. Allerdings muß auch beachtet werden, 

dass solche Bibliotheken problematisch werden können. Kaner, Bach und Pettichord 

schreiben dazu, dass Bibliotheken für das Testen besonders gut durchdacht sein müssen 

und Quellcode im Zweifelsfall besser in den einzelnen Testfällen wiederholt werden sollte. 

Sonst kann es passieren, dass unterschiedlichste Funktionen in einer Bibliothek zusammengefaßt 

werden. Es gestaltet sich dann schwer den Quellcode von Tests, die Funktionen 

aus dieser Bibliothek benutzen, zu lesen oder Fehler darin zu suchen (vgl. [Kan02, 

Seite 113f]).


 

cfengine mit 

Standardkonfiguration 

aufrufen 

cfengine mit 

Testkonfiguration 

aufrufen 

cfengine mit 

Standardkonfiguration 

aufrufen 

Hostname 

überprüfen 

Hostname 

überprüfen 

Hostname 

überprüfen 

 

Abbildung 5.2: Flussdiagramm Hostname-Test 

5.6 Problematiken bei Remote Tests 

Das Ausführen eines Tests auf einem oder mehreren entfernten Systemen bringt neben 

allen Vorteilen auch einige Schwierigkeiten mit sich. Dazu gehören: 

• Ein funktionstüchtiges Netzwerk ist für die Kommunikation der Test Case Controller 

Daemons unbedingt notwendig. Daher können Testfälle, welche die Konfiguration 

des Netzwerks betreffen, nicht ausgeführt werden. Eine zweite Netzwerkkarte 

in den Testsystemen kann hier teilweise Abhilfe schaffen. 

• TET selbst bietet keine Unterstützung für das Kopieren von Tests auf die Testsysteme. 

Daher muß die Entwicklung von Tests auf den Testsystemen selbst durchgeführt 

werden. Soll in dieser Phase der Test auf einem weiteren System ausgeführt 

werden, muß er manuell auf dieses System kopiert werden. 

• In einer Testumgebung mit VMware muß darauf geachtet werden, dass beim Duplizieren 

von Systemen die MAC-Adresse der Netzwerkkarte verändert wird, da es 

ansonsten einen Konflikt geben würde.

5.7 Zusammenfassung 39 


Dieses Kapitel zeigte wie eine Testumgebung aufgebaut werden kann, um verschiedene 

Testarten auf beliebig vielen entfernten Systemen auszuführen. Es wurde erläutert 

wie die Vorteile einer Virtualisierungssoftware wie VMware genutzt werden können und 

warum schließlich Distributed TET als Basis für das Testframework gewählt wurde. 

Weiterhin wurde auf verschiedene Testarten eingegangen, die sich in dieser Umgebung 

sinnvoll implementieren lassen. Um die Thematik zu veranschaulichen wurde exemplarisch 

ein Funktionstest implementiert. Das Potenzial des Test Environment Toolkits 

wird aber erst voll ausgespielt werden können, wenn eine größere Anzahl von Testfällen 

implementiert ist.

40 Kapitel 5 CoreBiz Testsuite - Remote Tests

Kapitel 6 

Corebiz Testsuite - Verteilte Tests 

In diesem Kapitel wird auf die Besonderheiten der verteilten Tests und deren Umsetzung 

mit Hilfe des Test Environment Toolkits eingegangen. Darauf aufbauend werden einige 

prototypische Implementierungen von Teställen vorgestellt, die verschiedene Aspekte 

eines LDAP-Servers testen. Zu beachten ist, dass auf grundsätzliche Sachverhalte, die 

im vorherigen Kapitel detailliert behandelt wurden, nicht nocheinmal eingegangen wird. 

Dieses Kapitel beschränkt sich darauf, die Unterschiede der beiden Testsuites hervorzuheben. 

6.1 Aufbau der Testumgebung 

Bei verteilten Tests müssen alle beteiligten Testsysteme mit einem Netzwerk verbunden 

sein. Da dies schon eine Voraussetzung bei der Testumgebung für Remote Tests war, 

sollte prinzipiell das Verwenden der gleichen Testumgebung möglich sein. Es spricht 

nichts dagegen, sowohl Remote als auch verteilte Tests in der gleichen Umgebung auszuführen. 

Je nach Art des Tests muß aber beachtet werden, dass das Netzwerk nicht ausschließlich 

für die Kommunikation zwischen den Testsystemen genutzt wird, sondern mindestens 

auch für die Kommunikation zwischen den Testsystemen und dem CoreBiz Factory Server. 

Deshalb kann es zum Beispiel bei einem Performance-Test Sinn machen, die Testsysteme 

mit einer zweiten Netzwerkkarte auszustatten, damit die Testsyteme ein eigenes 

dediziertes Netzwerk benutzen können. Weiterhin ist so sichergestellt, dass verschiedene 

Dienste, wie zum Beispiel DHCP, die unter Umständen auf dem CoreBiz Factory Server 

aktiviert sind, keinen ungewollten Einfluss auf die Testsysteme nehmen können. 

Abbildung 6.1 zeigt den Aufbau einer solchen Testumgebung mit einem CoreBiz Base 

Server und einem CoreBiz Client innerhalb einer VMware-Umgebung. Ein Netzwerkinterface 

wird dabei für die Kommunikation mit dem CoreBiz Factory Server verwendet, 

das andere für die Kommunikation der Testsysteme untereinander. Die folgenden Tests 

wurden genau in solch einer Testumgebung durchgeführt. Ein zweites, unabhängiges 

Netzwerk ist aber nicht zwingend notwendig. 

41

42 Kapitel 6 Corebiz Testsuite - Verteilte Tests 


Test Case 


VMware 

Test Case 


Test Case 


Virtuelles 

Netzwerk 

CoreBiz Base 

CoreBiz Client 

Abbildung 6.1: Aufbau der CoreBiz Testumgebung für verteilte Tests 

6.2 Das Test Environment Toolkit und verteilte Tests 

Verteilte Tests sind im Test Environment Toolkit daran zu erkennen, dass die Tests in 

der Szenario-Datei unter der Direktive ” 

:distributed:“ aufgeführt sind (vgl. 4.2.2). Bei 

den Tests selbst ist zu beachten, dass die Funktionen für die Synchronisierung beziehungsweise 

für das Austauschen von Nachrichten nur in der C- und C++-API von TET 

integriert sind. Im Gegensatz zu den Remote Tests ist es also nicht möglich, Tests mit 

Hilfe der SHELL- oder Perl-API zu erstellen. 

6.2.1 Einbinden von weiteren Programmiersprachen 

Oftmals liegen relativ einfache Testfälle vor, die mit deutlich weniger Aufwand in einer 

Skriptsprache zu realisieren sind. Daher wurden Möglichkeiten gesucht, wie verteilte 

Tests auch in diesen Sprachen entwickelt werden können. Der erste Ansatz war, einen 

Wrapper zu erstellen, der aus einer Konfigurationsdatei ein C-Programm generiert, das 

die auszuführenden Skripte in der richtigen Reihenfolge aufruft und zu den entsprechenden 

Zeitpunkten synchronisiert. Es wurde aber schnell klar, dass dieser Ansatz zu 

komplex und zu unflexibel werden würde. Es ist in den meisten Fällen einfacher, selbst 

ein C-Programm zu schreiben und daraus andere Skripte aufzurufen. Das C-Programm

6.2 Das Test Environment Toolkit und verteilte Tests 43 

wird dann hauptsächlich für die Synchronisation der Tests benutzt, während die Skripte 

die anderen Aufgaben erledigen. 

Ein Ansatz, der für die jeweilige Skriptsprache Funktionen für die Synchronisation implementiert, 

wäre natürlich wünschenswert. Diese müßten dann zum Beispiel auf die 

entsprechenden C-Funktionen zurückgreifen oder vollständig neu implementiert werden. 

Es bleibt allerdings fraglich, ob dieser Aufwand gerechtfertigt ist. Falls sich verteilte 

Tests in Zukunft bewähren sollten und eine größere Anzahl von Testfällen implementiert 

werden muß, sollte diese Option noch einmal geprüft werden. 

6.2.2 Synchronisation 

Eine Synchronisation zwischen zwei oder mehreren Testsystemen wird mit Hilfe von 

TET durch den Aufruf der Funktion ” 

tet remsync()“ erreicht. Diese Funktion kann auf 

drei verschiedenen Varianten benutzt werden: 

• Einfache Synchronisation 

• Synchronisation + Nachricht senden 

• Synchronisation + Nachricht empfangen 

Das nachfolgende Listing zeigt eine Funktion zum Synchronisieren und Senden einer 

Nachricht. Diese wird so oder in ähnlicher Form in den LDAP-Tests benutzt. 

int snd_msg(char *str) { 

int sys[] = { 2 }; /* system IDs to sync with */ 

struct tet_synmsg msg; 

msg.tsm_flags = TET_SMSNDMSG; 

msg.tsm_dlen = strlen(str)+1; 

msg.tsm_data = str; 

} 

if (tet_remsync(sync_nr, sys, 1, 

TIMEOUT, TET_SV_YES, &msg) != 0) { 

tet_printf("sync %d failed", sync_nr++); 

return 1; 

} 

else { 

tet_printf("sync %d OK", sync_nr++); 

return 0; 

}


6.2.3 Installation von verteilten Tests 

Damit verteilte Tests problemlos auf einem CoreBiz-System installiert werden können, 

müssen alle notwendigen Dateien in einem Debian-Paket bereitgestellt werden. Das Problem 

im Zusammenhang mit TET ist dabei, dass der Name eines Tests und das Verzeichnis 

in dem er liegt auf allen Testsystemen gleich sein muß. Ein Debian-Paket kann 

aber verständlicher Weise nur eine Datei mit dem selben Namen in das gleich Verzeichnis 

installieren. 

Ein Ansatz wäre nun, zwei Debianpakete zu erstellen: Eines mit den Tests für das erste 

Testsystem und eines mit dem Test für das zweite Testsystem. Es wäre allerdings viel 

sinnvoller alle Tests in einem einzigen Paket unterzubringen. Es müßte dann nur ein 

einziges Debian-Paket gepflegt werden und es kann nicht passieren, dass die falsche 

Version auf einem Testsystem installiert wird. Weiterhin könnte es in Zukunft auch 

Tests mit mehr als zwei Testsystemen geben. Für jedes weitere System müßte dann 

entsprechend ein weiteres Debian-Paket erstellt werden. 

Eine flexiblere Lösung bietet die Option ” 

TET REMXXX TET TSROOT“ der TET- 

Konfigurationsdatei ” 

tetdist.cfg“. Damit kann das Verzeichnis festgelegt werden, in der 

die Tests liegen. XXX steht dabei für die System ID. Es wurden vorerst zwei Verzeichnisse 

definiert: ” 

base“ und ” 

client“, entsprechend der System IDs des CoreBiz Base Servers 

beziehungsweise des CoreBiz Clients. Falls in Zukunft Verzeichnisse für weitere Systeme 

benötigt werden, sollten sie sich an den festgelegten System IDs orientieren. Für die 

implementierten Tests wurde folgende ” 

tetdist.cfg“ benutzt: 

TET_ROOT=/opt/tet-full 

TET_REM001_TET_TSROOT=/opt/tests/distributed_tests/base 

TET_REM002_TET_TSROOT=/opt/tests/distributed_tests/client 

Zusammengefaßt heißt das, dass in einem Debian-Paket immer vollständige Tests enthalten 

sind. Die Entscheidung, welcher Teil eines Tests auf einem bestimmten System 

ausgeführt wird, trifft der Test Case Controller anhand der Konfigurationsdatei tetdist.cfg“. 

Diese muß für alle am Test beteiligten Systemen den Parameter ” 

TET REMXXX TET TSROOT“ definieren. Neben der Direktive ist dies der einzigste 

” 

Konfigurationsparameter, der eine Testumgebung für verteilte Tests von einer Testumgebung 

für Remote Tests unterscheidet. 

6.3 Drei prototypische Testfälle 

Im Folgenden werden drei prototypische Implementierungen von Testfällen beschrieben. 

Diese Tests beziehen sich auf den LDAP-Server, dessen Verhalten auf unterschiedliche 

Weise getestet wird. Alle Tests sind in der Programmiersprache C implementiert und es 

werden die entsprechenden APIs von TET und OpenLDAP verwendet.

6.3 Drei prototypische Testfälle 45 

Synchrone und asynchrone LDAP-Funktionen 

Das Lightweight Directory Access Protocol ist ein asynchrones Protokoll. Das heißt, dass 

mehrere LDAP-Anfragen gleichzeitig an den Server geschickt werden können und es dem 

Server überlassen ist, in welcher Reihenfolge er die Anfragen abarbeitet. 

Aus diesem Grund gibt es die meisten LDAP-Funktionen in einer synchronen und einer 

asynchronen Variante. Während synchrone LDAP-Funktionen auf die Antwort des 

LDAP-Servers warten und in dieser Zeit das Programm blockieren, können mit asynchronen 

LDAP-Funktionen in dieser Wartezeit andere Aufgaben erledigt werden oder 

auch weitere LDAP-Funktionen aufgerufen werden. 

Timing-Probleme mit VMware 

Nach ersten Versuchen wurde deutlich, dass das Verwenden von VMware problematisch 

im Hinblick auf eine exakte Zeitmessung sein kann. Die interne Uhr von Systemen 

innerhalb einer VMware-Instanz laufen meistens nicht synchron zu den Uhren realer 

Systeme. Daher wird die Zeit dieser Systeme in bestimmten Abständen durch VMware 

synchronisiert. 

Für die Zeitmessung bedeutet das, dass es ab und zu größere Zeitsprünge geben kann, 

nämlich genau dann, wenn die Uhr durch VMware synchronisiert wird. Außerdem ist 

die absolute Zeit ebenfalls sehr ungenau, da wie schon erwähnt, die Uhr zu schnell oder 

zu langsam laufen kann. Bei den Tests kommt es aber hauptsächlich auf die Zeitdifferenz 

an. Es sollten daher die eigentlich relevanten Messungen und Auswertungen nicht 

beeinträchtigt werden. 

6.3.1 LDAP Konflikttest 

Ziel 

Es soll getestet werden, was passiert, wenn zwei Systeme gleichzeitig versuchen einen 

identischen LDAP Eintrag zu ändern, neu anzulegen oder zu löschen. Interessant wird 

dieser Test in Kombination mit einem Lasttest. Der Testfall wird also über einen längeren 

Zeitraum ständig wiederholt. 

Implementierung 

Sowohl Server als auch Client versuchen gleichzeitig einen LDAP-Eintrag anzulegen, 

zu ändern und wieder zu löschen. Nach jeder Operation wird dem anderen System eine 

Nachricht mit dem Ergebnis geschickt. Für die Operationen Eintrag anlegen“ und 

” 

Eintrag löschen“ wird erwartet, dass die Operation bei einem Testsystem erfolgreich 

” 

ausgeführt wird und entsprechend beim anderen Testsystem eine Fehlermeldung erzeugt. 

Bei der Operation Eintrag modifizieren“ wird erwartet, dass beide Testsysteme die 

”


Funktion fehlerfrei ausführen können. Hier ist dann besonders interessant, welcher Eintrag 

nach dem Test in der Datenbank steht. Abbildung 6.2 beschreibt den Ablauf des 

LDAP Konflikttests. 

Server 

LDAP 

Client 

Sync 

Sync 

ldap operation 


ok/fail 

ok/fail 

send result 

send result 

Abbildung 6.2: Sequenzdiagramm LDAP Konflikttest 

Es werden sowohl die synchronen als auch asynchronen Varianten der LDAP-Funktionen 

benutzt. Daher gibt es zwei Test Purposes (vgl. 4.2.2). Test Purpose 1 führt die synchronen, 

Test Purpose 2 die asynchronen LDAP-Funktionen aus. Der Testfall wird mit 

der Standardkonfiguration des LDAP-Servers ausgeführt und insgesamt 8 Stunden lang 

wiederholt. 

Analyse der Ergebnisse 

Die Ergebnisse bestätigen die Vermutungen, die beim Erstellen des Testfalls gemacht 

wurden: Der LDAP-Server kam mit allen Funktionsaufrufen zurecht, es traten nur die 

erwarteten Fehler auf. Jeder erfolgreiche Versuch eines Testsystems einen neuen Eintrag 

im LDAP anzulegen oder zu löschen, erzeugte einen Fehlversuch auf dem jeweils anderen 

Testsystem. In den 8 Stunden wurde der Testfall insgesamt 54130 mal wiederholt. Tabelle 

6.1 zeigt die Anzahl der erfolgreich ausgeführten Funktionen bei den Operationen


” add“ und delete“ und die Anzahl der zuerst ausgeführten Anfragen bei der Operation 

” 

” modify“. 

Es zeigt sich, dass der CoreBiz Base Server deutlich öfter erfolgreich“ war, als der 

” 

CoreBiz Client. Das läßt sich dadurch erklären, dass der OpenLDAP-Server auf dem 

CoreBiz Base Server läuft und damit die Anfrage nicht wie beim Client zuerst über das 

Netzwerk geschickt werden muß. Zwischen den synchronen und asynchronen Funktionen 

gibt es in diesem Testfall keine wesentlichen Unterschiede. Interessant ist aber, dass 

nicht 100% der Anfragen des Servers erfolgreich waren und der Client bei einem nicht 

unerheblichen Teil trotz der Netzwerkverzögerung schneller war. 

synchron 

asynchron 

add modify delete add modify delete 

Server 22798 22222 19355 24149 22118 18670 

Client 4267 4843 7710 2916 4947 8395 

Tabelle 6.1: Ergebnis des LDAP Konflikttests 

Eine interessante Erweiterung dieses Testfalls wäre das Hinzufügen von weiteren Testsystemen. 

Beispielsweise könnten zehn Clients gleichzeitig versuchen Änderungen am 

LDAP-Server vorzunehmen. Da alle Clients nahezu die gleiche Verzögerung durch das 

Netzwerk haben, wäre es interessant zu wissen, wie die erfolgreichen Anfragen verteilt 

sind. Weiterhin könnte getestet werden, wieviel gleichzeitige Anfragen der LDAP-Server 

überhaupt verkraftet oder ob nur die Bandbreite des Netzwerks eine Grenze darstellt. 

6.3.2 LDAP Performance Test 

Ziel 

Es soll gemessen werden, wie sich die Performance des LDAP Servers bei stetig größer 

werdender Datenbank verhält. Dabei gilt es zu klären, von welchen Parametern die 

Performance maßgeblich abhängt. 

Der Test ermöglicht es, den Leistungsbedarf eines LDAP Servers zu ermitteln. Das ist 

zum Beispiel nötig, um Kunden eine realistische Einschätzung geben zu können, ob ihr 

bisheriger Server mit 20000 Benutzern umgehen kann, oder ob neue, leistungsstärkere 

Hardware angeschafft werden muß. 

Weiterhin lassen sich so auch Änderungen der Performance des LDAP-Servers selbst 

feststellen. Beispielsweise können folgende Systemparameter die Performance beeinflussen: 

• Neue oder andere Version des OpenLDAP Servers 

• Verwenden eines anderen Datenbank-Backends für den LDAP-Server


• Veränderung bestimmter Konfigurationsparameter des LDAP-Servers 


Der Test läuft wieder in der üblichen Testumgebung ab, einem CoreBiz Base Server und 

einem CoreBiz Client. Auf dem CoreBiz Base Server werden nach und nach immer mehr 

LDAP-Einträge hinzugefügt. Der CoreBiz Client misst dann die Laufzeit bestimmter 

LDAP-Operationen. Abbildung 6.3 zeigt ein Sequenzdiagramm, das den Ablauf des Tests 

beschreibt. 

Server 

LDAP 

Client 

ldap_add 

Sync 1 

Sync 1 

Sync 2 


ldap operation ok 

delay 

Sync 2 

loop 

loop 

Abbildung 6.3: Sequenzdiagramm LDAP Performance Test 

Der Testfall besteht aus zwei Test Purposes. Der erste Test Purpose benutzt die synchronen 

LDAP Funktionen, um die Laufzeit folgender Operationen zu messen: 

• ldap search auf alle Einträge im LDAP 

• ldap add von 100 Einträgen 

• ldap modify von 100 Einträgen 

• ldap search mit Filter, der 100 Einträge zurückliefert 

• ldap delete von 100 Einträgen


Der zweite Test Purpose führt die gleichen Operationen mit Hilfe der asynchronen Varianten 

durch. Es werden jeweils 100 Einträge hinzugefügt, modifiziert oder gelöscht, 

um eine sinnvolle Zeitspanne messen zu können. Zusätzlich wird jede Operation 10 mal 

ausgeführt, um Abweichungen durch verschiedene Einflüsse erkennen zu können. 


Anzahl Einträge im LDAP 

LDAP Operation 1000 3000 7000 15000 30000 

add 1738 2110 2245 2158 2448 

modify 446 504 507 529 484 

delete 1988 2510 2899 3969 4743 

search1 1901 11314 30887 88226 254950 

search2 300 336 306 407 362 

Tabelle 6.2: Ergebnisse des LDAP Performance Tests (synchron) 

Anzahl Einträge im LDAP 

LDAP Operation 1000 3000 7000 15000 30000 

add 1395 2610 186 763 168 

modify 397 302 155 128 149 

delete 5442 2385 3635 6054 8655 

search1 9034 25243 50367 99711 343316 

search2 423 15 15 14 21 

Tabelle 6.3: Ergebnisse des LDAP Performance Tests (asynchron) 

Die Tabelle 6.2 und das dazugehörige Diagramm 6.4 zeigen die Ergebnisse der synchronen 

LDAP-Operationen (Test Purpose 1). Die Tabelle 6.3 und das dazugehörige Diagramm 

6.5 zeigen dagegen die Ergebnisse der asynchronen LDAP-Operationen (Test Purpose 

1). 

Zu jeder LDAP-Operation werden pro Vergrößerung der LDAP-Datenbank 10 Werte 

gemessen. Die zwei größten beziehungsweise zwei kleinsten Werte werden nicht weiter 

ausgewertet. Von den übrigen 6 Werten wird jeweils der Durchschnitt gebildet. Die in 

den Tabellen 6.2 und 6.3 unter ” 

search1“ aufgelisteten Werte stellen die Suche auf alle 

Einträge im LDAP dar, während die unter ” 

search2“ aufgelisteten Werte die Suche mit 

der Rückgabe von 100 Einträgen darstellt. Zu beachten ist die logarithmische Darstellung 

der Y-Achse in den Diagrammen. 

Während die Operationen ” 

add“ und ” 

delete“ mit größer werdender Datenbank etwas 

mehr Zeit benötigen, bleiben die Werte der Operationen ” 

modify“ und ” 

search2 “ praktisch 

konstant. Die Operation ” 

search2“ benötigt erwartungsgemäß immer mehr Zeit.


1000000 

100000 

Millisekunden 

10000 

1000 

add 

modify 

delete 

search1 

search2 

100 

1000 3000 7000 15000 30000 

Anzahl Einträge 

Abbildung 6.4: Ergebnisse des LDAP Performance Tests (synchron)


1000000 

100000 

Millisekunden 

10000 

1000 

100 

add 

modify 

delete 

search1 

search2 

10 

1000 3000 7000 15000 30000 

Anzahl Einträge 

Abbildung 6.5: Ergebnisse des LDAP Performance Tests (asynchron)


Interessant ist aber, dass sich diese Zeiten mit steigender Anzahl von Datenbankeinträgen 

um ein Vielfaches erhöht. Beispielhaft können die Werte von 15000 und 30000 

Einträgen betrachtet werden. Während sich die Einträge in der LDAP-Datenbank verdoppelt 

haben, hat sich die Zeit für das Auslesen nahezu verdreifacht. 

Auffällig bei den asynchronen Funktionsaufrufen ist zu allererst, dass die Zeiten im 

Gegensatz zu den synchronen Varianten sehr viel mehr Schwanken können. Abgesehen 

von den Timing-Problemen der VMware könnte eine andere Abarbeitungsmethode der 

einzelnen Anfragen im OpenLDAP-Server eine Erklärung dafür sein. Bei synchronen 

Funktionsaufrufen wird genau eine Anfrage an den Server geschickt und erst nach dem 

Erhalt des Ergebnisses die nächste Anfrage an den LDAP-Server gesendet. Bei den 

asynchronen Funktionsaufrufen werden dagegen alle Anfragen auf einmal an den Server 

übertragen. Dieser kann dann selbst entscheiden wann und in welcher Reihenfolge die 

Anfragen abgearbeitet werden. 

Einen direkten Vergleich zwischen den synchronen und asynchronen Funktionen machen 

diese teilweise heftigen Schwankungen schwer. Obwohl die Zahlen schon Durchschnittswerte 

darstellen, müßten viele weitere Testläufe gemacht werden, um wirklich 

verwendbare Durchschnittswerte zu erhalten. Auffällig ist aber, dass ” 

search1“ in der 

asynchronen Variante langsamer ist, während ” 

search2“ fast immer deutlich schneller 

als die synchrone Variante ist. 

An dieser Stelle muß noch einmal erwähnt werden, dass bei diesem Testfall ausschließlich 

mit der C-API gearbeitet wird. Es soll also das Verhalten und die Leistung des Servers 

selbst getestet werden. Damit können aber keine Aussagen über Programme getroffen 

werden, die in irgendeiner Form mit dem LDAP-Server kommunizieren. Beispielsweise 

werden bei allen Testfällen jeweils nur zu Beginn beziehungsweise zum Ende des Tests 

die Funktionen ldap init, ldap bind und ldap unbind aufgerufen. Während des ganzen 

Tests wird also mit der gleichen Verbindung gearbeitet. Bei diversen Programmen liegt 

es aber nahe, dass dies jeweils beim Ausführen des Programms geschieht. Um das Verhalten 

und die Performance von LDAP-basierter Software korrekt zu Testen, müssen die 

Funktionsaufrufe so gut wie möglich nachgebildet werden. Ein anderer Ansatz wäre die 

zu testenden Programme direkt aufzurufen. 

Probleme mit dem Datenbank-Backend ” 

ldbm“ 

Bei einem Performance Test wie diesem, bei dem sehr große Mengen an Daten geschrieben 

und gelesen werden, handelt es sich natürlich auch um eine Art Stresstest. Dieser 

Nebeneffekt führte dazu, dass folgender Fehler entdeckt wurde: Wenn als Datenbank- 

Backend ” 

ldbm“ verwendet wird und in Größenordnungen von mehreren 10000 LDAP- 

Einträge gearbeitet wird, dann läßt sich die zuvor angelegte ” 

Organizational Unit“, unterhalb 

der die LDAP-Einträge angelegt werden, nicht mehr löschen. Der LDAP-Server 

anwortet mit der Fehlermeldung: 

Delete Result: Operation not allowed on non-leaf (66) 

Additional info: subtree delete not supported


Der Fehler deutet eigentlich darauf hin, dass es noch weitere Einträge unterhalb dieses 

Knoten gibt. Es waren aber offensichtlich keine weiteren Einträge vorhanden. Um 

eine korrekte LDAP-Datenbank wiederhezustellen, mußte die Datenbank gelöscht und 

neu aufgebaut werden. Da in den aktuellen CoreBiz Servern ausschließlich ” 

bdb“ als 

Backend verwendet wird, wurde der Ursache dieses Fehlers nicht weiter nachgegangen. 

Beim Verwenden des Datenbank-Backends ” 

bdb“ tritt dieser Fehler nicht auf. 

6.3.3 LDAP Latenztest 

Ziel 

Es soll die Verzögerung gemessen werden, wie lange es dauert, bis ein neuer Eintrag oder 

eine Änderung eines vorhandenen LDAP-Eintrags bei einem Client, der diesen Eintrag 

ausliest, sichtbar wird. Dabei werden verschiedene Konfigurationsparameter verändert, 

von denen erwartet wird, dass sie diese Verzögerung beeinflussen. Auch wenn dieser 

Testfall Latenztest genannt wird, um ihn von den anderen Testfällen zu unterscheiden, 

handelt es sich um einen Performance Test. 


Zuerst synchronisieren sich Server und Client. Nun ändert der Server ein bestimmtes 

LDAP-Attribut auf einen Testwert, den er zuvor während der Synchronisation dem 

Client mitgeteilt hatte. Der Client versucht dann, dieses geänderte Attribut auszulesen. 

Gemessen wird die Zeit ab der Synchronisation bis zum erfolgreichen Auslesen des 

geänderten LDAP-Attributs. Abbildung 6.6 beschreibt den Ablauf des LDAP Latenz 

Tests. Sowohl Server als auch Client verwenden synchrone LDAP-Funktionen. 

Neben der Standard-Konfiguration des LDAP-Servers werden zusätzlich Testläufe durchgeführt, 

bei denen folgende Konfigurationsparameter verändert werden: 

• ” 

dirtyread“ - Lesen von modifizierten Einträgen, auf die aber noch kein commit 

folgte 

• ” 

dbnosync“ - Daten im Speicher werden nicht sofort auf die Festplatte synchronisiert 

• Verwenden des Datenbank-Backends ” 

ldbm“ anstatt ” 

bdb“ 

Vor jedem Durchlauf wird die LDAP-Datenbank gelöscht und neu initialisiert, damit 

exakt die gleichen Ausgangsbedingungen geschaffen werden.


Server 

LDAP 

Client 

Sync 1 Sync 1 

ldap_modify 

ldap_search 

old value 

delay 

ldap_search 

modified value 

Abbildung 6.6: Sequenzdiagramm LDAP Latenztest 


Jeder Testlauf wurde 1000 mal durchgeführt, um einen möglichst guten Durchschnittswert 

zu erhalten. Die 100 höchsten und 100 niedrigsten Messwerte werden nicht in die 

Auswertung mit einbezogen, da es durch die Problematik mit der VMware teilweise extrem 

abweichende Werte geben kann. Es bleiben also noch 800 Messwerte, aus denen 

die durchschnittliche Verzögerung berechnet wird. Zusätzlich wurde jede Konfiguration 

drei mal wiederholt. Tabelle 6.4 zeigt das Ergebnis. 

Die geänderten Konfigurationsparameter haben also Auswirkungen auf die Performance 

des LDAP-Servers. Allerdings fällt diese Verbesserung relativ gering aus, so dass es 

kaum Sinn machen würde, deswegen das Risiko von inkonsistenzen Daten oder sogar 

der Verlust von Daten deutlich zu erhöhen. Es gibt natürlich noch viele weitere Konfigurationsparameter, 

die verändert und getestet werden können. Besonders interessant 

für weitere Tests sind neue Versionen des OpenLDAP-Servers oder auch des Datenbank- 

Backends. 

Was aus der Tabelle 6.4 nicht ersichtlich ist, sind die einzeln gemessenen Werte. Diese


bdb standard 

bdb + dirtyread 

bdb + dbnosync 

bdb + dirtyread 

+ 

dbnosync 

DL 1 in ms 7,69 7,02 7,29 6,25 8,99 

DL 2 in ms 7,75 7,24 7,35 6,35 8,86 

DL 3 in ms 7,38 6,88 5,83 6,25 9,49 

Durchschnitt 7,61 7,05 6,82 6,28 9,11 

Prozentualer 

Unterschied 

ldbm standard 

0 7,95 11,48 21,06 -16,53 

Tabelle 6.4: Ergebnis des LDAP Latenztests 

schwanken im Bereich von 2 bis 21 Millisekunden, obwohl die am stärksten abweichenden 

Werte nicht mit einberechnet wurden. Erklären läßt sich das mit der Tatsache, dass 

LDAP ein asynchrones Protokoll ist und der Server nicht zwingend sofort antworten 

muß. Auffällig ist, dass die schnellsten Zeiten unabhängig von der Konfiguration immer 

2 Millisekunden betrugen. Die verschiedenen Konfigurationen wirken sich also nur auf 

die langsamsten Zeiten und damit auch auf die Durchschnittszeiten aus. Interessant 

wäre die Durchführung dieses Testfalls auf realen Systemen, damit der Test nicht von 

den Timing Problemen der VMware beeinflusst wird. Diese Probleme führen auch dazu, 

dass die Ergebnisse dieses Tests praktisch wertlos für den Vergleich mit zukünftigen Tests 

sind. Nur die prozentualen Unterschiede lassen sich unter Umständen weiter nutzen. 

Bei diesem Testfall wurde wenig Zeit für die Automatisierung aufgewendet. Das machte 

sich dadurch bemerkbar, dass das Vorbereiten der Testumgebung und insbesondere 

die Auswertung der Tests noch manuell gemacht werden muß. Das Vorbeiten der Testumgebung, 

also vor allem das Initialisieren des LDAP-Servers kann relativ einfach 

durch ein Skript automatisiert werden. Allerdings stellt sich hier die Frage, wie sinnvoll 

eine Automatisierung wäre. Das interessante an diesem Test sind die Auswirkungen 

der veränderten Konfigurationsparameter. Wenn neue Parameter getestet werden sollen, 

müssen diese ohnehin manuell eingestellt werden. Bei einer Automatisierung würde das 

bedeuten, dass jedes mal der Testfall angepasst werden müßte. Dagegen wäre das automatisierte 

Auswerten der Testergebnisse, also das Extrahieren der relevanten Messdaten, 

durchaus sinnvoll. Problematisch ist hier hauptsächlich die Tatsache, dass dies außerhalb 

des Testframeworks gemacht werden muß, da das Journal des Testfalls die Messwerte 

enthält. Bei diesem Test wurde das mit Hilfe einiger SHELL-Befehlen manuell realisiert. 

Die Zahlen wurden dann in eine Tabellenkalkulation eingefügt und entsprechend 

aufbereitet.


6.4 Problematiken bei verteilten Tests 

Die Probleme, die eine Virtualisierungssoftware mit sich bringt, wurden schon in den 

vorherigen Abschnitten erwähnt. Speziell Performance Tests, bei denen man bestimmte 

Zeiten messen will, sollten daher auf realen Systemen durchgeführt werden. 

Allgemein ist das Erstellen von verteilten Tests deutlich aufwändiger, als von Remote 

beziehungsweise lokalen Tests. Das liegt allein schon an der Tatsache, dass die Tests 

auf den einzelnen Systemen unterschiedlich aufgebaut sind. Die Entwicklung eines Tests 

verkompliziert sich in Folge dessen. Die Problematik dabei ist, dass ein verteilter Test nur 

ausgeführt werden kann, wenn auf allen beteiligten Testsystemen, der Test vorhanden 

ist. Für die Entwicklung bedeutet das, dass zuerst alle Komponenten eines Tests erstellt 

werden müssen, bevor der Test selbst getestet werden kann. Die Fehlersuche gestaltet 

sich dann ähnlich schwierig, da es oftmals nicht offensichtlich ist, auf welchem Testsystem 

der Fehler verursacht wurde. 

Darin liegt auch der größte Nachteil von verteilten Tests gegenüber Remote Tests. Deshalb 

sollte vor der Entwicklung eines Testfalls immer geprüft werden, ob mit einem 

Remote Test nicht das gleiche Ergebnis erzielt werden kann. Wenn doch ein verteilter 

Test entwickelt werden muß, sollte der Testfall gut durchdacht und geplant sein. Das 

Design ist hier deutlich wichtiger als bei Remote Tests. 

Ein weiteres Problem ist das Senden von Daten an ein anderes Testsystem. Hier ist 

TET auf einfache Zeichenketten beschränkt. Es gibt keine Marshalling-Funktionalität, 

um auch komplexere Datentypen zu übertragen. In bestimmten Testfällen wäre es aber 

wünschenswert, beispielsweise einen Array an das andere Testsystem zu übertragen. 

Lösen könnte man dieses Problem, indem man Funktionen implementiert, die diese Datentypen 

auf der Senderseite in eine Zeichenkette umwandeln und auf der Empfängerseite 

diese wieder in den entsprechenden Datentyp umwandeln. 


Dieses Kapitel erklärte den Aufbau, die Möglichkeiten, aber auch die Schwierigkeiten einer 

Testumgebung in der verteilte Tests ausgeführt werden können. Interessant dabei ist, 

dass sich die Umgebung nur minimal von der Testumgebung für Remote Tests unterscheidet. 

Die prototypisch implementierten Testfälle demonstrieren, wie sich verteilte Tests 

einsetzen lassen können. Die Vorteile liegen speziell in einer Client-Server-Umgebung auf 

der Hand: Es können zeitlich exakt abgestimmte Interaktionen zwischen diesen Systemen 

getestet werden. Allerdings ist der Aufwand für das Erstellen solcher Tests deutlich 

höher im Vergleich zu Remote Tests.

Kapitel 7 

Conclusio 

Im letzten Kapitel dieser Arbeit wird noch einmal ein Fazit gezogen und ein Ausblick 

für die Zukunft gegeben. 

7.1 Fazit 

Das Testen von Software ist ein äußerst interessantes, aber auch sehr komplexes Themengebiet. 

Leider wird es oftmals von vielen Softwareentwicklern, aber auch Projektleitern 

und dem Management nur stiefmütterlich behandelt. Das kann sich in verschiedener 

Hinsicht in einem Softwareprojekt auswirken. Das Management stellt ein zu geringes 

Budget für das Testen bereit, der Projektleiter plant zu wenig Zeit dafür ein und die 

Entwickler haben kaum Wissen und Erfahrung in diesem Themengebiet. 

Dieser Umgang mit dem Thema Software führt dazu, dass die Qualität der Software 

leidet. Um dem entgegen zu wirken, muß zuerst ein geeigneter Rahmen geschaffen werden. 

Dazu gehört, dass von Anfang an genügend Mittel und Zeit für den Test in einem 

Softwareprojekt eingeplant werden. Es werden geschulte Mitarbeiter benötigt, die zumindest 

über ein Basiswissen im Themengebiet Softwaretest verfügen. Weiterhin ist es 

notwendig, dass es standardisierte Verfahren gibt, wie Software zu testen ist. Dazu muß 

auch ein einheitliches Test-Framework vorhanden sein. 

Die Erarbeitung eines Konzepts für ein solches Test-Framework war die Zielsetzung dieser 

Arbeit. Besondere Bedeutung hatten dabei einerseits die Regressionstests und die 

damit verbundene Automatisierung von Tests, und andererseits die verteilten Tests. 

Um diese Anforderungen zu realisieren, wurde eine Testumgebung mit Hilfe des Test 

Environment Toolkits entwickelt. Es wurden so die Voraussetzungen geschaffen, Tests 

auf entfernten Systemen und verteilte Tests durchzuführen. Einige prototypische Implementierungen 

von Testfällen veranschaulichten die Funktionsweise des Test-Frameworks, 

zeigten aber auch die Schwierigkeiten und Problematiken auf. 

57

58 Kapitel 7 Conclusio 

Das Test Environment Toolkit zeigte sich dabei als ein sehr ausgereiftes und gut durchdachtes 

Test-Framework. So enstehen Probleme meist dann, wenn außerhalb dieses Frameworks 

Aktionen durchgeführt werden müssen. Als Beispiel können hier die Performance 

Tests dienen, bei denen in der Regel verschiedene Messwerte aus einem Journal 

extrahiert werden müssen. Diese Aufgabe selbst ist zwar einfach zu realisieren, aber 

da sie außerhalb des TET-Frameworks abläuft, verkompliziert sich der Testfall dadurch 

deutlich. 

Besonders interessante Testfälle in einer Client-Server-Umgebung können durch verteilte 

Tests realisiert werden. Das Test-Framework ermöglicht dies dadurch, dass Funktionen 

bereitgestellt werden, die eine Synchronisation sowie das Senden und Empfangen von 

Nachrichten zwischen mehreren Testsystemen erlauben. Im Hinblick auf CoreBiz Systeme, 

die sehr stark von der Client-Server-Kommunikation abhängen, wurden diesen Tests 

besondere Aufmerksamkeit geschenkt. Die implementierten Testfälle zeigten verschiedene 

Szenarien, wie solche Tests eingesetzt werden können. Allerdings wurde daraus auch 

ersichtlich, dass der Aufwand für die Implementierung von verteilten Tests im Vergleich 

zu Remote Tests deutlich höher ist. 

Zusammenfassend kann gesagt werden, dass für die meisten Testfälle, Remote Tests 

ausreichend sind und mit weitaus geringerem Aufwand zu realisieren sind. Hier kommen 

hauptsächlich die Verifikation von Konfigurationen und Funktionstests in Frage. Verteilte 

Tests sollten dagegen für besondere Tesfälle eingesetzt werden, für die zeitlich exakt 

abgestimmte Interaktionen zwischen Server und Client notwendig sind. Beispiele wären 

Funktionstests die bestimmte Konfliktsituationen testen, aber auch Performance, Lastund 

Stresstests. 

Das ganze Potenzial dieses Test-Frameworks, mit dem sowohl Remote als auch verteilte 

Tests realisiert werden können, wird sich aber erst in Zukunft zeigen, wenn eine größere 

Anzahl von Testfällen implementiert ist. 

7.2 Ausblick 

Mit dieser Arbeit ist nun ein Rahmen für das Erstellen von Testfällen gegeben. Es stellt 

sich nun abschließend die Frage, wie dieses Projekt in Zukunft weitergeführt werden 

kann. 

Der wahrscheinlich wichtigste Schritt wird nun das Erstellen von möglichst vielen Testfällen 

sein. So können Erfahrungen auf diesem Gebiet gesammelt werden und das Test- 

Framework selbst auf seine Praxistauglichkeit getestet werden. In diesem Zusammenhang 

ist es sicherlich sinnvoll, häufig benutzte Funktionen in Bibliotheken zusammenzufassen. 

So kann das Erstellen von Tests vereinfacht und die Entwicklungszeit verkürzt werden. 

Wenn eine gewisse Anzahl an Testfällen existiert, können diese in verschiedenen Testsuites 

zusammengefaßt werden. Vorstellbar wäre beispielsweise eine Testsuite, die auf allen

7.2 Ausblick 59 

CoreBiz Systemen sinnvoll ausgeführt werden kann und jeweils eine weitere Testsuite für 

bestimmte CoreBiz Systeme wie zum Beispiel der CoreBiz Base Server und der CoreBiz 

Client. In diesem Zusammenhang sollte auch die Automatisierung der Tests noch einmal 

untersucht werden. Zwar wurden einige Konzepte in dieser Arbeit vorgestellt und auch 

umgesetzt, für das effektive Durchführen von Regressionstests muß die Automatisierung 

aber weiter verbessert werden. 

Weiterhin könnten neue Testarten evaluiert werden. Naheliegend wären zum Beispiel 

GUI-Tests, die bestimmte Aspekte der grafischen Benutzeroberfläche auf einem CoreBiz 

Client überprüfen. 

In der Praxis werden CoreBiz Systeme oft in heterogenen Netzwerkumgebungen eingesetzt. 

Daher wäre es durchaus vorstellbar, dass auch Windows-Clients im Zusammenspiel 

mit einem CoreBiz Base Server getestet werden. Ein sinnvoller Testfall wäre zum 

Beispiel die Überprüfung, ob auf einem Windows-Client ein bestimmtes Netzlaufwerk 

eingebunden werden kann, das der CoreBiz Base Server mit Hilfe der Software ” 

samba“ 

zur Verfügung stellt. 

Ein weiterer Ansatz, um den Testprozess zu vereinfachen, wäre die Entwicklung einer 

GUI oder eines Web-Interfaces. Dieses Interface sollte auf einfache Art und Weise das 

Ausführen von Testfällen erlauben und die Ergebnisse grafisch aufbereiten. So könnte 

auch technisch nicht versierten Mitarbeitern die Möglichkeit gegeben werden, Testfälle 

auszuführen und die Ergebnisse zu überprüfen. 

Die Problematiken der Virtualisierungssoftware VMware wurde in den vorherigen Kapiteln 

schon angesprochen. Deshalb könnten Alternativen evaluiert werden. In diesem 

Zusammenhang sollten Xen (vgl. [Unib]) und User Mode Linux (vgl. [Dik]) untersucht 

werden. Neben den Performance Vorteilen, die sich eventuell ergeben könnten, wäre dies 

auch der Schritt zu einer ausschließlich auf freier Software basierenden Testumgebung. 

Sowohl Xen als auch User Mode Linux sind unter der GNU GPL freigegeben. 

Bei näherer Betrachtung des Debian Projekts kann festgestellt werden, dass es nur wenige 

Ansätze für die Qualitätssicherung durch Softwaretests gibt. Daher könnte geprüft 

werden, ob aus dem CoreBiz Regressionstest-Framework bestimmte Teile dem Debian 

Projekt zur Verfügung gestellt werden können. Das können verständlicher Weise nur 

Teile sein, die nicht CoreBiz-spezifisch sind. So würde einerseits der Open Source Gedanken 

weitergeführt werden und andererseits erhofft werden, dass die Qualität von 

Debian weiter verbessert wird. Das würde langfristig auch den CoreBiz Produkten zu 

Gute kommen.

60 Kapitel 7 Conclusio

Anhang A 

Literaturverzeichnis 

[Abe] Aberdour, Mark. Open source tools for software testing professionals. 

http://opensourcetesting.org/ (Stand: 28.08.2005) 

[Deba] Debian. Debian Project Homepage. http://www.debian.org/ (Stand: 

28.08.2005) 

[Debb] 

Debian. Debian-Richtlinien für Freie Software (DFSG). http://www.debian. 

org/social_contract#guidelines (Stand: 28.08.2005) 

[Dik] Dike, Jeff. The User-mode Linux Kernel Home Page. 

http://user-mode-linux.sourceforge.net/ (Stand: 28.08.2005) 

[Fau] 

[Frea] 

[Freb] 

Faught, Danny. testingfaqs.org - An information resource for software testers. 

http://www.testingfaqs.org/ (Stand: 28.08.2005) 

Free Software Foundation. cfengine. http://www.gnu.org/software/ 

cfengine/cfengine.html (Stand: 28.08.2005) 

Free Software Foundation. GNU General Public License. http://www. 

gnu.org/licenses/gpl.html (Stand: 28.08.2005) 

[Frec] Free Standards Group. Linux Standard Base Project. http://www. 

linuxbase.org/ (Stand: 28.08.2005) 

[Kan02] Kaner, Bach, Pettichord: Lessons Learned in Software Testing. Wiley, 

New York, 2002 

[Lan] Lange, Thomas. Fully Automatic Installation (FAI). http://www. 

informatik.uni-koeln.de/fai/ (Stand: 28.08.2005) 

[Lin] 

Linux Test Project. Test Plan. http://ltp.sourceforge.net/testPlan. 

php (Stand: 28.08.2005) 

[Mye79] Myers, Glenford J.: The Art of Software Testing. John Wiley & Sons, 1979 

[Ope] 

OpenLDAP Foundation. OpenLDAP. http://www.openldap.org/ (Stand: 

28.08.2005) 

61

62 Literaturverzeichnis 

[OU87] 

Ould, Martyn A. ; Unwin, Charles: Testing in Software Development (British 

Computer Society Monographs in Informatics). Cambridge University Press, 

1987 

[Rät04] Rätzmann, Manfred: Software-Testing - Rapid Application Testing, Softwaretest, 

Agiles Qualitätsmanagement. Galileo Press, 2004 

[Riv] Rivest, Raymond. comp.software.testing Frequently Asked Questions. 

http://www.faqs.org/faqs/software-eng/testing-faq/ (Stand: 

28.08.2005) 

[Sava] 

[Savb] 

[Savc] 

Savoye, Rob. DejaGnu. http://www.gnu.org/software/dejagnu/ (Stand: 

28.08.2005) 

Savoye, Rob. DejaGnu. http://www.gnu.org/software/dejagnu/manual/ 

x47.html (Stand: 28.08.2005) 

Savoye, Rob. Re: Using DejaGnu in a regression farm. http://lists.gnu. 

org/archive/html/dejagnu/2005-08/msg00006.html (Stand: 28.08.2005) 

[Sch83] Schmitz, Bons, van Megen: Software-Qualitätssicherung - Testen im 

Software-Lebenszyklus. Vieweg, Wiesbaden, 1983 

[STA] STAF Core Team. Software Testing Automation Framework. 

http://staf.sourceforge.net/ (Stand: 28.08.2005) 

[Tha97] Thaller, Georg E.: Der individuelle Software-Prozess. Bhv, 1997 

[Tha02] Thaller, Georg E.: Software-Test - Verifikation und Validation. H. Heise 

Vlg., Hann., 2002 

[Thea] The Open Group. Testing. http://www.opengroup.org/testing/ 

downloads.html (Stand: 28.08.2005) 

[Theb] 

[Thec] 

[Thed] 

The Open Group. TETware and the Open Source Test Environment Toolkit. 

http://tetworks.opengroup.org/ (Stand: 28.08.2005) 

The Open Group: TETware Programmers Guide. : The Open Group 

The Open Group: TETware User Guide. : The Open Group 

[Unia] University of California. Berkeley Software Distribution License. 

http://www.opensource.org/licenses/bsd-license.php (Stand: 

28.08.2005) 

[Unib] University of Cambridge. The Xen virtual machine monitor. 

http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ (Stand: 28.08.2005) 

[Wik] Wikipedia. Debian. http://de.wikipedia.org/wiki/Debian (Stand: 

28.08.2005)

Anhang B 

Abbildungsverzeichnis 

2.1 CoreBiz Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

3.1 Remote Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

3.2 Verteilter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

4.1 Die Komponenten von TET . . . . . . . . . . . . . . . . . . . . . . . . . 23 

4.2 Aufbau eines Testfalls im TET . . . . . . . . . . . . . . . . . . . . . . . . 24 

5.1 Aufbau der CoreBiz Testumgebung für Remote Tests . . . . . . . . . . . 31 

5.2 Flussdiagramm Hostname-Test . . . . . . . . . . . . . . . . . . . . . . . 38 

6.1 Aufbau der CoreBiz Testumgebung für verteilte Tests . . . . . . . . . . . 42 

6.2 Sequenzdiagramm LDAP Konflikttest . . . . . . . . . . . . . . . . . . . . 46 

6.3 Sequenzdiagramm LDAP Performance Test . . . . . . . . . . . . . . . . . 48 

6.4 Ergebnisse des LDAP Performance Tests (synchron) . . . . . . . . . . . . 50 

6.5 Ergebnisse des LDAP Performance Tests (asynchron) . . . . . . . . . . . 51 

6.6 Sequenzdiagramm LDAP Latenztest . . . . . . . . . . . . . . . . . . . . 54 

63

64 Abbildungsverzeichnis

Anhang C 

Tabellenverzeichnis 

2.1 Veröffentlichte Versionen von Debian . . . . . . . . . . . . . . . . . . . . 4 

2.2 Interner Aufbau eines CoreBiz Systems . . . . . . . . . . . . . . . . . . . 6 

3.1 Verschiedene Definitionen von Qualität . . . . . . . . . . . . . . . . . . . 9 

4.1 Vergleich von Test Management Tools . . . . . . . . . . . . . . . . . . . . 22 

5.1 Zuweisung von TET-IDs zu CoreBiz Systemen . . . . . . . . . . . . . . . 32 

6.1 Ergebnis des LDAP Konflikttests . . . . . . . . . . . . . . . . . . . . . . 47 

6.2 Ergebnisse des LDAP Performance Tests (synchron) . . . . . . . . . . . . 49 

6.3 Ergebnisse des LDAP Performance Tests (asynchron) . . . . . . . . . . . 49 

6.4 Ergebnis des LDAP Latenztests . . . . . . . . . . . . . . . . . . . . . . . 55 

65

66 Tabellenverzeichnis

Anhang D 

Abkürzungsverzeichnis 

BSD 

CPL 

DFSG 

DHCP 

FAI 

GNU 

GNU GPL 

GUI 

IC 

KDE 

LDAP 

LSB 

POSIX 

PXE 

scp 

ssh 

STAF 

tcc 

tccd 

TCM 

TET 

TP 

Berkeley Software Distribution 

Common Public License 

Debian Free Software Guidelines 

Dynamic Host Configuration Protocol 

Fully Automatic Installation 

GNU’s Not Unix 

GNU General Public License 

Graphical User Interface 

Invocable Component 

K Desktop Environment 

Lightweight Directory Access Protocol 

Linux Standard Base 

Portable Operating System Interface 

Preboot eXecution Environment 

Secure Shell 

Secure Copy 

Software Testing Automation Framework 

Test Case Controller 

Test Case Controller Daemon 

Test Case Manager 

Test Environment Toolkit 

Test Purposes 

67

Diplomarbeit

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?