Diplomarbeit
Diplomarbeit
Diplomarbeit
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Fachhochschule Furtwangen<br />
Computer Networking<br />
<strong>Diplomarbeit</strong><br />
Thema:<br />
Design und Implementierung eines<br />
verteilten Regressionstest-Frameworks<br />
Referent:<br />
Prof. Dr. Christoph Reich<br />
Fachhochschule Furtwangen<br />
Korreferent:<br />
Rudolf Strobl<br />
Linux Information Systems AG<br />
vorgelegt im:<br />
Sommersemester 2005<br />
am:<br />
31. August 2005<br />
vorgelegt von:<br />
Thilo Alexander Uttendorfer<br />
Matrikelnummer: 213164<br />
Bismarckstraße 23<br />
73257 Köngen
ii<br />
Ich erkläre hiermit an Eides Statt, dass ich die<br />
vorliegende <strong>Diplomarbeit</strong> selbständig und ohne unzulässige<br />
fremde Hilfe angefertigt habe. Die verwendeten Quellen und<br />
Hilfsmittel sind vollständig zitiert.<br />
München, den 29. August 2005<br />
Thilo Alexander Uttendorfer<br />
Bismarckstraße 23<br />
73257 Köngen
Inhaltsverzeichnis<br />
1 Einleitung 1<br />
1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.2 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
2 CoreBiz 3<br />
2.1 Debian GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
2.2 CoreBiz Ressource-Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
2.3 Installation und Konfiguration von CoreBiz Systemen . . . . . . . . . . . 5<br />
2.3.1 Generierung von Systemen . . . . . . . . . . . . . . . . . . . . . . 6<br />
2.3.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
2.3.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.4 Qualitätssicherung des CoreBiz Ressource-Pools . . . . . . . . . . . . . . 7<br />
2.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
3 Software-Test 9<br />
3.1 Softwarequalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
3.2 Ausprägungen von Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
3.2.1 Testarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
3.2.2 Testszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
3.3 Regressionstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
3.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
4 Test-Werkzeuge und Testsuites 17<br />
4.1 Automatisiertes Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
4.2 Test-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
4.2.1 Vergleich von Test Management Tools . . . . . . . . . . . . . . . 20<br />
4.2.2 Test Environment Toolkit . . . . . . . . . . . . . . . . . . . . . . 23<br />
4.3 Testsuites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
4.3.1 Linux Standard Base Testsuites . . . . . . . . . . . . . . . . . . . 26<br />
4.3.2 CoreBiz Testsuites . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
iii
iv<br />
Inhaltsverzeichnis<br />
5 CoreBiz Testsuite - Remote Tests 29<br />
5.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
5.2 Aufbau der Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
5.2.1 TET-Lite vs. Distributed TET . . . . . . . . . . . . . . . . . . . 29<br />
5.2.2 Virtualisierungssoftware . . . . . . . . . . . . . . . . . . . . . . . 31<br />
5.2.3 Konfiguration der Systeme . . . . . . . . . . . . . . . . . . . . . . 32<br />
5.3 Ablauf eines Testfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
5.4 Testarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
5.4.1 Verifikation von Konfigurationen . . . . . . . . . . . . . . . . . . 34<br />
5.4.2 Funktionstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
5.4.3 Performance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
5.5 Ein prototypischer Testfall . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
5.5.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
5.5.2 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
5.6 Problematiken bei Remote Tests . . . . . . . . . . . . . . . . . . . . . . . 38<br />
5.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
6 Corebiz Testsuite - Verteilte Tests 41<br />
6.1 Aufbau der Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
6.2 Das Test Environment Toolkit und verteilte Tests . . . . . . . . . . . . . 42<br />
6.2.1 Einbinden von weiteren Programmiersprachen . . . . . . . . . . . 42<br />
6.2.2 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43<br />
6.2.3 Installation von verteilten Tests . . . . . . . . . . . . . . . . . . . 44<br />
6.3 Drei prototypische Testfälle . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
6.3.1 LDAP Konflikttest . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
6.3.2 LDAP Performance Test . . . . . . . . . . . . . . . . . . . . . . . 47<br />
6.3.3 LDAP Latenztest . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
6.4 Problematiken bei verteilten Tests . . . . . . . . . . . . . . . . . . . . . . 56<br />
6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
7 Conclusio 57<br />
7.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57<br />
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
A Literaturverzeichnis 61<br />
B Abbildungsverzeichnis 63<br />
C Tabellenverzeichnis 65<br />
D Abkürzungsverzeichnis 67
Kapitel 1<br />
Einleitung<br />
1.1 Problemstellung<br />
Das Ziel dieser <strong>Diplomarbeit</strong> ist die Erarbeitung eines Konzepts für ein verteiltes Regressionstest-Framework<br />
und dessen prototypische Implementierung. Hintergrund dieser<br />
Tests ist die Qualitätssicherung der Produktreihe CoreBiz, die von der Linux Information<br />
Systems AG entwickelt wird.<br />
CoreBiz basiert auf dem Softwarearchiv von Debian GNU/Linux. Dieses Archiv wird<br />
in regelmäßigen Abständen aktualisiert. Das bedeutet, dass jedes Softwarepaket, für<br />
das eine aktuellere Version verfügbar ist, durch diese ersetzt wird. Um nach solch einer<br />
Aktualisierung eine Regression, also einen Rückschritt bei der Qualität zu verhindern,<br />
müssen verschiedene Tests durchgeführt werden. Das Regressionstest-Framework soll die<br />
bisherige Testumgebung integrieren und erweitern. Dabei soll untersucht werden, welche<br />
Arten von Tests sinnvoll eingesetzt werden können.<br />
Besondere Bedeutung haben die so genannten verteilten Tests. Diese unterscheiden sich<br />
zu normalen Tests dahingehend, dass die Komponenten eines solchen Testfalls auf verschiedenen<br />
Systemen eines lokalen Netzwerkes ablaufen und sich zeitlich und inhaltlich<br />
aufeinander beziehen. Es werden also die Interaktionen zwischen verschiedenen Systemen<br />
getestet.<br />
1.2 Vorgehensweise<br />
Zunächst wird die Produktreihe CoreBiz vorgestellt. Da sich das Regressionstest-Framework<br />
vorrangig auf die verschiedenen Produkte von CoreBiz bezieht, ist ein grundlegendes<br />
Verständnis über den Aufbau dieser Software nötig. Es wird gezeigt was die Software<br />
leistet und aus welchen Komponenten sie besteht. Aus diesem Zusammenhang heraus<br />
wird erläutert, warum und an welchen Punkten Softwaretests eingesetzt werden sollen.<br />
Anschließend wird auf das Thema Softwaretest im Allgemeinen eingegangen. Es wird<br />
die Notwendigkeit eines Qualitätsmanagements von Software aufgezeigt und es werden<br />
1
2 Kapitel 1 Einleitung<br />
verschiedene Testarten näher erläutert. Darauf folgt ein Überblick über Werkzeuge, die<br />
den Testprozess unterstützen und vereinfachen. In diesem Zusammenhang werden die<br />
Möglichkeiten sowie die Vor- und Nachteile der Automatisierung von Tesfällen diskutiert.<br />
Der praktische Teil dieser Arbeit enthält die prototypische Implementierung von Remote<br />
und verteilten Tests. Es wird gezeigt, wie eine Testumgebung für Testfälle dieser Art<br />
realisiert werden kann. Auf einige exemplarische Testfälle wird näher eingegangen und<br />
es werden die Probleme und Ergebnisse dieser Tests diskutiert. Zum Ende dieser Arbeit<br />
wird ein Fazit gezogen und ein Ausblick für die Zukunft dargestellt.
Kapitel 2<br />
CoreBiz<br />
Eine modular aufgebaute Software um Linux für unterschiedlichste Einsatzzwecke zu<br />
installieren und zu konfigurieren wird unter dem Namen CoreBiz von der Linux Information<br />
Systems AG angeboten. Als Basis wird dafür die Linux Distribution Debian<br />
GNU/Linux (vgl. [Deba]) benutzt. Da sich diese Arbeit an vielen Stellen immer wieder<br />
darauf bezieht, wird im Folgenden der Aufbau und die Funktionsweise von Core-<br />
Biz Systemen im Detail erläutert. In diesem Zusammenhang wird zunächst auf Debian<br />
GNU/Linux eingegangen.<br />
2.1 Debian GNU/Linux<br />
Debian GNU/Linux ist ein freies Betriebssystem, das unterschiedlichste Rechnerarchitekturen<br />
unterstützt und mehrere Tausend Softwarepakete enthält. Es wird im Gegensatz<br />
zu vielen anderen Linux Distributionen ausschließlich von Freiwilligen entwickelt und ist<br />
die am weitesten verbreitete nicht-kommerzielle Linux Distribution (vgl. [Wik]).<br />
Debian hat sehr strenge Richtlinien in Bezug auf Software, die in die Distribution aufgenommen<br />
wird. So wird ausschließlich Software zugelassen, die unter einer freien Lizenz,<br />
wie zum Beispiel der GNU General Public License (GPL) oder der Berkeley Software<br />
Distribution (BSD) License 1 , veröffentlicht wurde. Diese Richtlinien sind in den Debian<br />
Free Software Guidelines (DFSG) (vgl. [Debb]) geregelt.<br />
Debian hebt sich von anderen Linux Distributionen vor allem durch sein Paketmanagement<br />
ab, welches das Aktualisieren von Paketen und das Auflösen von Abhängigkeiten<br />
zwischen diesen Paketen zuverlässig löst. Außerdem bietet es ein sehr umfangreiches Archiv<br />
an Software. Dieses Archiv ist in drei 2 verschiedenen Varianten erhältlich: stable“, ”<br />
” testing“ und ” unstable“. Dabei enthält stable“ die jeweils letzte veröffentlichte Version<br />
”<br />
und testing“ die Kommende aber noch nicht veröffentlichte Version des Betriebssystems.<br />
Die Variante unstable“ enthält jeweils relativ aktuelle, meist aber ungetestete<br />
”<br />
”<br />
Pakete, die, wie der Name schon sagt, unstabil oder fehlerhaft sein können.<br />
1 Die beiden Lizenzen findet man unter [Freb] beziehungsweise unter [Unia]<br />
2 Es gibt noch eine vierte Variante ”<br />
experimental“, die aber nur für Entwickler gedacht ist.<br />
3
4 Kapitel 2 CoreBiz<br />
2.2 CoreBiz Ressource-Pool<br />
Größter Nachteil an Debian (zum Zeitpunkt des Schreibens dieser Arbeit) ist der sehr<br />
lange Releasezyklus. Tabelle 2.1 zeigt die veröffentlichten Versionen der letzten Jahre.<br />
Der immer größer werdende Abstand zwischen den Versionen ist unter anderem auf die<br />
Vielzahl der unterstützten Architekturen und der stetig steigenden Anzahl an Paketen<br />
zurückzuführen. Das Debian Projekt ist sich zwar diesem Problem bewußt und arbeitet<br />
an Lösungen, es ist jedoch nicht damit zu rechnen, dass es mittelfristig deutlich kürzere<br />
Releasezyklen geben wird.<br />
Version Name Datum<br />
2.0 Hamm 24. Juli 1998<br />
2.1 Slink 9. März 1999<br />
2.2 Potato 15. August 2000<br />
3.0 Woody 19. Juli 2002<br />
3.1 Sarge 6. Juni 2005<br />
? Etch ?<br />
Tabelle 2.1: Veröffentlichte Versionen von Debian (Quelle: [Deba])<br />
Daraus ergibt sich, dass die stabile Variante von Debian zum Teil sehr alte Pakete<br />
enthält, da in diesem Archiv nur eventuelle Sicherheitslücken beseitigt werden, jedoch<br />
keine neuen Pakete hinzugefügt werden. Dagegen werden die Varianten testing“ und<br />
”<br />
unstable“ ständig mit neuen Paketen aktualisiert. Das führt dazu, dass sich auch grundlegende<br />
Teile des Systems verändern können und diese Varianten somit keine verlässliche<br />
”<br />
Lösung darstellen.<br />
Die Anforderungen an ein CoreBiz System sind aber einerseits die Verfügbarkeit aktueller<br />
Versionen von bestimmten Softwarepaketen, andererseits muß die Software stabil<br />
und langfristig einsetzbar sein. Um dieses Dilemma zu überwinden, wird für CoreBiz in<br />
regelmäßigen Abständen ein so genannter Snapshot aus ”<br />
testing“ gemacht. Das bedeutet,<br />
dass sämtliche Pakete aus dem Debian Archiv ”<br />
eingefroren“ werden und von diesem<br />
Zeitpunkt an nur noch durch Sicherheitsaktualisierungen oder Bugfixes verändert werden<br />
können. Dadurch sind CoreBiz basierte Server und Clients einerseits aktueller als<br />
entsprechende, auf Debian ”<br />
stable“ basierende Systeme. Andererseits wird trotzdem versucht<br />
die Stabilität und Qualität von Debian ”<br />
stable“ zu erreichen.<br />
Diesem regelmäßig aktualisiertem Archiv werden dann zusätzlich CoreBiz-spezifische Pakete<br />
hinzugefügt. Um begrifflichen Missverständnissen vorzubeugen, wird dieses Archiv<br />
CoreBiz Ressource-Pool“ bezeichnet.<br />
”
2.3 Installation und Konfiguration von CoreBiz Systemen 5<br />
2.3 Installation und Konfiguration von CoreBiz<br />
Systemen<br />
Die Basis jeder CoreBiz Installation ist der so genannte ”<br />
CoreBiz Factory Server“. Dieses<br />
System verfügt über alle Komponenten, die nötig sind, um weitere Systeme zu installieren<br />
und hat direkten Zugriff auf den CoreBiz Ressource-Pool. Hier werden sämtliche Konfigurationseinstellungen,<br />
Parameterisierungen und Kundenanpassungen durchgeführt,<br />
um daraus den so genannten ”<br />
CoreBiz Base Server“ zu generieren.<br />
Der CoreBiz Base Server wird an den Kunden ausgeliefert und ist dann in der Lage,<br />
weitere Systeme zu installieren. Diese Fähigkeit wird zum Beispiel genutzt, um die Installation<br />
von Clients direkt vor Ort beim Kunden durchzuführen. Abbildung 2.1 zeigt<br />
den typischen Aufbau einer CoreBiz Umgebung.<br />
CoreBiz Factory<br />
CoreBiz Base<br />
CoreBiz<br />
Ressource-Pool<br />
installiert<br />
installiert<br />
CoreBiz Backup<br />
CoreBiz Client CoreBiz Client CoreBiz Client<br />
Abbildung 2.1: CoreBiz Umgebung
6 Kapitel 2 CoreBiz<br />
Auf dem CoreBiz Factory Server beziehungsweise dem CoreBiz Base Server ist das Softwarepaket<br />
OpenLDAP (vgl. [Ope]) installiert, um Benutzerkonten und Gruppen mittels<br />
des Lightweight Directory Access Protocol (LDAP) zentral verwalten zu können. Außerdem<br />
wird der LDAP-Server genutzt, um bestimmte Server-Dienste zu parameterisieren.<br />
Das wird aber nur von einigen Diensten unterstützt, wie beispielsweise dem DHCP-<br />
Server.<br />
Wenn alle Kundenanpassungen und Konfigurationen für ein neues System erstellt wurden,<br />
werden im wesentlichen folgende Schritte durchgeführt:<br />
1. Generierung<br />
2. Installation<br />
3. Konfiguration<br />
2.3.1 Generierung von Systemen<br />
Wichtiger Bestandteil ist die frei erhältliche Software FAI (Fully Automatic Installation)<br />
(vgl.[Lan]), welche die Infrastruktur für eine komplett automatische Installation über das<br />
Netzwerk oder die Generierung von Installations-CDs ermöglicht. Anhand von Profilen<br />
und Komponenten werden die unterschiedlichen CoreBiz Systeme erstellt. Tabelle 2.2<br />
zeigt den Zusammenhang zwischen Profil, Komponente und Debian-Paket. Ein Profil<br />
stellt ein komplettes CoreBiz System dar. Eine Komponente dagegen ist ein bestimmter<br />
Teil eines Systems, wie zum Beispiel die KDE Umgebung, und enthält eine Liste von<br />
Debian-Paketen. Da die Komponenten aber unabhängig von einem Profil sind, können<br />
sie beliebig in anderen Profilen wiederverwendet werden. Durch diesen modularen Ansatz<br />
ist es möglich, auf einfache Art und Weise Kundenanpassungen durchzuführen.<br />
enthält<br />
Beispiel<br />
Profil Liste mit Komponenten CoreBiz Client<br />
Komponente Liste mit Paketen KDE Umgebung<br />
Paket Debian-Paket Konqueror<br />
Tabelle 2.2: Interner Aufbau eines CoreBiz Systems<br />
2.3.2 Installation<br />
Die Installation eines CoreBiz Systems erfolgt vollkommen automatisch entweder durch<br />
eine Installations-CD oder über das Netzwerk. Im Falle der Netzwerkinstallation wird<br />
PXE (Preboot eXecution Environment) genutzt, um ein System automatisch zu installieren.<br />
Als PXE-Boot-Server dient dabei der CoreBiz Factory Server beziehungsweise<br />
der CoreBiz Base Server.
2.4 Qualitätssicherung des CoreBiz Ressource-Pools 7<br />
Einem System, das über das Netzwerk installiert wird, wird mit Hilfe von DHCP (Dynamic<br />
Host Configuration Protocol) eine IP-Adresse zugewiesen. Daraufhin wird vom<br />
Server ein Kernel heruntergeladen mit dem das System in der Lage ist zu booten.<br />
Die Installation erfolgt dann in zwei Phasen. Während der ersten Phase werden Systeminformationen<br />
ausgelesen und an den Server übermittelt. Es werden dabei entsprechende<br />
Eintragungen im LDAP des CoreBiz Base Servers vorgenommen. Ab diesem Zeitpunkt<br />
ist das System registriert und es können beispielsweise Hardwareinformationen ausgelesen<br />
oder das zu installierende Profil geändert werden. Nach einem Neustart des Systems<br />
erfolgt dann die zweite Phase mit der eigentlichen Installation.<br />
Die Installation von CD kann unabhängig der Netzwerkumgebung durchgeführt werden.<br />
Von Nachteil ist allerdings die Beschränkung der Kapazität auf eine CD oder, falls ein<br />
entsprechendes Laufwerk vorhanden ist, auf eine DVD. Zum Beispiel kann es bei einem<br />
so genannten ”<br />
Fat Client“ sein, dass mehrere Gigabyte an Softwarepaketen installiert<br />
werden müssen.<br />
2.3.3 Konfiguration<br />
Ziel jeder CoreBiz Installation ist es, ohne manuellen Eingriff abzulaufen. Das setzt voraus,<br />
dass alle Konfigurationsparameter schon vor der Installation festgelegt werden. Des<br />
weiteren ist es oft wünschenswert bestimmte Konfigurationen bei produktiven Systemen<br />
später zu ändern.<br />
Um diese Anforderungen realisieren zu können, wird das Werkzeug ”<br />
cfengine“ (vgl.<br />
[Frea]) eingesetzt. Der Name ”<br />
cfengine“ leitet sich von ”<br />
configuration engine“ ab. Damit<br />
lassen sich unter anderem Konfigurationsdateien auf einfache und elegante Art und<br />
Weise modifizieren. Es bringt eine eigene Programmiersprache mit, die im Gegensatz<br />
zu vielen anderen Sprachen ohne die üblichen if-else-Anweisungen auskommt. Anweisungen<br />
werden dagegen in Abhängigkeit von bestimmten Klassen ausgeführt, die frei<br />
definiert werden können. Weiterhin stehen eine Vielzahl von vordefinierten Klassen zur<br />
Verfügung, die beispielsweise bestimmte Systemeigenschaften wie die Kernelversion repräsentieren.<br />
Bei einem CoreBiz System wird dieses Werkzeug genutzt, um bestimmte Systemparameter<br />
in Konfigurationsdateien zu setzen oder zu überprüfen. Das können beispielsweise<br />
grundlegende Dinge wie die Netzwerkkonfiguration sein, aber auch das Hintergrundbild<br />
der grafischen Oberfläche kann so verändert werden.<br />
2.4 Qualitätssicherung des CoreBiz Ressource-Pools<br />
Bei einer Aktualisierung des CoreBiz Ressource-Pools wird die Variante ”<br />
testing“ des<br />
Debian Archivs verwendet. Dabei kann nicht davon ausgegangen werden, dass alle Pa-
8 Kapitel 2 CoreBiz<br />
kete fehlerfrei sind, beziehungsweise sich alle Programme genau so verhalten wie ihre<br />
Vorgängerversion. Fehler können beispielsweise schon daraus entstehen, dass sich der<br />
Name eines Parameters einer Konfigurationsdatei ändert. Wenn dieser Parameter durch<br />
CoreBiz mittels ”<br />
cfengine“ kontrolliert wird, würde dies höchstwahrscheinlich zu einer<br />
fehlerhaften Konfiguration führen. Es könnten sich aber auch die Schnittstellen eines Programmes<br />
geändert haben oder es fehlen sogar bestimmte Pakete im Ressource-Pool.<br />
Das bisherige Verfahren bei einer Aktualisierung des Ressource-Pools war, das auf einer<br />
CoreBiz Installation Tests der Linux Standard Base (LSB) ausgeführt wurden. Diese<br />
Tests überprüfen verschiedene Aspekte wie zum Beispiel die POSIX-Kompatibilität oder<br />
die Konformität des Dateisystems zur LSB. Damit kann zwar eine gewisse Grundfunktionalität<br />
abgedeckt werden, aber es wäre wünschenswert weitergehende Tests durchzuführen.<br />
Deshalb gibt es den Ansatz, Konfigurationsdateien, die durch ”<br />
cfengine“ automatisch<br />
verwaltet werden, mit Hilfe von Tests zu verifizieren. Vorstellbar sind aber auch weitergehende<br />
Tests, die direkt bestimmte Funktionalitäten von CoreBiz Systemen überprüfen<br />
oder aber auch Performance- und Lasttests.<br />
Ziel aller Tests ist es, festzustellen, ob sich nach einer Aktualisierung des Ressource-<br />
Pools, die Funktionalität der CoreBiz Skripte, die CoreBiz Systeme an sich und das<br />
Zusammenspiel verschiedener CoreBiz Systeme miteinander in irgendeiner Form beeinträchtigt<br />
ist. Auf letzteres, also die Interaktion zwischen verschiedenen Systemen, wird<br />
dabei besonderen Wert gelegt.<br />
2.5 Zusammenfassung<br />
In diesem Kapitel wurden die Komponenten eines CoreBiz Systems erklärt. Neben Debian<br />
GNU/Linux, welches die Basis für alle CoreBiz Systeme darstellt, wurde die Generierung,<br />
die Installation und die Konfiguration dieser Systeme detailliert erläutert.<br />
Besonders interessant ist die Qualitätssicherung des Resource-Pools, der sämtliche Software<br />
enthält, die bei CoreBiz Systemen verwendet wird. Es wurde gezeigt, dass bei<br />
CoreBiz Systemen unterschiedliche Software integriert wird und diese Systeme im Netzwerk<br />
zusammenarbeiten und voneinander abhängig sind. Um Fehler in einem CoreBiz<br />
System, aber auch in der vollständigen CoreBiz Umgebung zu verhindern, müssen gewisse<br />
Tests durchgeführt werden. Es ist also nötig ein Konzept für die Qualitätssicherung<br />
dieser Systeme zu entwickeln und zu realisieren.
Kapitel 3<br />
Software-Test<br />
Testing is the process of executing a program with the intent of finding errors.“<br />
[Mye79, Seite<br />
”<br />
5]<br />
In diesem Kapitel wird auf die Notwendigkeit des Qualitätsmanagements von Software<br />
eingegangen. Es soll einen Überblick über die grundlegenden Termini und Themen<br />
aus dem Gebiet der Softwaretests im Hinblick auf die CoreBiz Testumgebung geben.<br />
Besondere Beachtung wird den verschiedenen Testausprägungen geschenkt.<br />
3.1 Softwarequalität<br />
Definition von Definition<br />
1 Philip B. Crosby Qualität ist die Erfüllung von Anforderungen<br />
2 DATEV Qualität ist Kundenzufriedenheit<br />
3 Thaller Qualität ist Fehlerfreiheit<br />
4 Weinberg Qualität heißt, die Anforderungen eines Menschen zu erfüllen<br />
Tabelle 3.1: Verschiedene Definitionen von Qualität (Quelle: [Tha97])<br />
Tabelle 3.1 zeigt verschiedene Definitionen von Qualität. Wenn Qualität mit Fehlerfreiheit<br />
definiert wird, stellt sich zunächst die Frage, wie es überhaupt dazu kommt, dass<br />
Fehler entstehen: Fehler entstehen prinzipiell in jeder Phase eines Softwareprojekts, beim<br />
Aufnehmen der Anforderungen, beim Erstellen des Designs und bei der Kodierung der<br />
Software (vgl. [OU87, Seite 5]). Problematisch dabei ist, dass Fehler in einer frühen Phase<br />
in der Regel zu Folgefehlern in den darauf folgenden Phasen führen. Wie empirische<br />
Untersuchungen gezeigt haben, sind solche Fehler, die in späten Phasen der Software-<br />
Entwicklung oder sogar erst im Betrieb gefunden werden, sehr teuer (vgl. [Sch83, Seite<br />
61f]).<br />
Es ist also notwendig, in allen Phasen eines Projekts zu testen und Fehler möglichst<br />
früh zu erkennen und zu beheben. Das führt aber dazu, dass das Testen einen nicht<br />
unbeachtlichen Teil am Gesamtaufwand eines Projekts einnimmt und somit zu einem<br />
9
10 Kapitel 3 Software-Test<br />
aufwändigen und kostspieligen Prozess wird. Thaller schreibt von 30 bis 50 Prozent des<br />
Gesamtaufwands, welches das Testen eines Softwareprojekts an Ressourcen verschlingen<br />
kann (vgl. [Tha02, Seite 49]).<br />
Die Erfahrungen in der Softwareentwicklung haben gezeigt, dass es praktisch unmöglich<br />
ist, fehlerfreie Software zu schreiben. Thaller stellte eine interressante Rechnung an, die<br />
das verdeutlicht: Er nimmt relativ optimistische Fehlerraten an und berechnet damit die<br />
Anzahl der nicht erkannten schwerwiegenden Fehlern von verschiedenen Softwareprojekten.<br />
Ein Beispiel ist die Software für das Navigationssystem des Space Shuttles. Obwohl<br />
die NASA eine der niedrigsten Fehlerraten der Industrie aufweist, muß trotzdem mit 100<br />
schwerwiegenden Fehlern gerechnet werden, die nicht erkannt werden. Es muß beachtet<br />
werden, dass dies die Anzahl der Fehler ist, die nach dem Test der Software verbleibt<br />
(vgl. [Tha02, Seite 17]).<br />
Für die Qualitätssicherung von Software bedeutet das, dass auch hier ständig Fortschritte<br />
und Verbesserungen erzielt werden müssen. Nur so kann bei immer größer werdenden<br />
Softwareprojekten die Qualität sichergestellt werden. Trotzdem muß auch die Wirtschaftlichkeit<br />
des Testens im Auge behalten werden. Es macht einen Unterschied, ob von<br />
einer Software Menschenleben abhängen oder ob durch einen Softwarefehler ”<br />
nur“ Daten<br />
verloren gehen, die mit etwas Aufwand wiederhergestellt werden können. Entsprechend<br />
muß der Aufwand abgeschätzt werden, der in das Testen der Software investiert wird.<br />
3.2 Ausprägungen von Tests<br />
Softwaretests haben das Ziel, bestimmte Systemparameter zu erzeugen und zu ermitteln.<br />
Diese Systemparameter werden je nach Ausprägung des Tests auf unterschiedliche Art<br />
und Weise erzeugt. Sie werden dann mit den eigentlich korrekten Parametern verglichen<br />
und entsprechend bewertet. Die erwarteten Systemparameter müssen daher eindeutig<br />
ermittelt werden können (vgl. [Rät04, Seite 34]). Nachfolgend werden verschiedene Arten<br />
von Tests erläutert und dann mögliche Testszenarien vorgestellt.<br />
3.2.1 Testarten<br />
Im folgenden wird auf verschiedene Arten von Tests eingegangen, die für das Qualitätsmanagement<br />
von CoreBiz sinnvoll erscheinen.<br />
Verifikation von Konfigurationen<br />
Diese Art des Tests darf nicht mit Konfigurationstests verwechselt werden, bei denen<br />
es in der Regel um das Zusammenspiel einer Software mit unterschiedlichen Hardwarekonfigurationen<br />
geht. Bei der Verifikation von Konfigurationen handelt es sich um
3.2 Ausprägungen von Tests 11<br />
Tests, die bestimmte Werte in Konfigurationsdateien verifizieren, welche automatisch,<br />
zum Beispiel durch ein Skript, verändert werden. Für den Test bedeutet das, dass ein<br />
Programm oder Skript ausführt wird, welches bestimmte Parameter in einer Konfigurationsdatei<br />
auf einen vorher festgelegten Wert setzt. Dann wird diese Konfigurationsdatei<br />
beziehungsweise die einzelnen Parameter mit dem erwartetem Ergebnis verglichen.<br />
Die Tests sind nötig, da sich beispielsweise der Aufbau einer Konfigurationsdatei oder der<br />
Name eines Parameters ändern kann. Ein Skript, das diese Datei verändern will, würde<br />
dann eine fehlerhafte Konfiguration hinterlassen. Als Nebeneffekt lassen sich damit auch<br />
Fehler im Skript selbst aufdecken.<br />
Funktionstest<br />
Funktionstests überprüfen das Ergebnis eines Aufrufs eines Programms (vgl. [Tha02,<br />
Seite 122ff]). Sie setzen die korrekte Konfiguration aller Programme, die am Test beteiligt<br />
sind, vorraus. Eine korrekte Konfiguration ist aber noch kein Garant für einen<br />
erfolgreichen Funktionstest. Der Test führt ein Programm aus und vergleicht dessen<br />
Rückgabewert mit dem erwartetem Ergebnis. Vor der eigentlichen Überprüfung des<br />
Rückgabewertes werden in der Regel andere Programme oder Skripte ausgeführt, die<br />
diesen Rückgabewert beeinflussen.<br />
Stress- und Lasttest<br />
Wie Boris Beizer bemerkt, werden diese beiden Begriffe sehr oft falsch benutzt und als<br />
Synonyme verwendet (vgl. [Riv]). Nachfolgend wird versucht, die Unterschiede dieser<br />
beiden Testarten aufzuzeigen.<br />
Bei einem Stresstest wird versucht das zu testende Programm extrem zu belasten. Es<br />
wird dabei keinesfalls erwartet, dass das Programm unter dieser Belastung korrekt weiterarbeitet.<br />
Das Programm sollte aber zum Beispiel mit einer entsprechenden Fehlermeldung<br />
abbrechen. Das ist oftmals aber nicht der Fall und das Programm kann abstürzen<br />
oder Daten beschädigen.<br />
Beim Lasttest dagegen wird das Programm gleichmäßig über einen längeren Zeitraum<br />
unter Last gesetzt. Es sollen also die Auswirkungen getestet werden, wenn eine Funktion<br />
nicht nur einmal ausgeführt wird, sondern über eine bestimmte Dauer ständig<br />
wiederholt wird. Wenn ein Programm zum Beispiel für eine Funktion Speicher reserviert,<br />
aber aufgrund eines Fehlers nicht mehr freigibt, dann fällt das beim einmaligen<br />
Ausführen möglicherweise nicht weiter auf. Durch das ständige Wiederholen würde<br />
höchstwahrscheinlich aber auch solch ein Fehler erkannt.
12 Kapitel 3 Software-Test<br />
Performance Test<br />
Performance Tests sollen die Geschwindigkeit bestimmter Funktionen des Systems messen.<br />
Das Besondere an diesem Test ist, dass kein Fehler auftreten muß, sondern nur<br />
verschiedene Messwerte zurückgeliefert werden. Diese müssen dann entsprechend interpretiert<br />
werden und zum Beispiel mit Referenzwerten verglichen werden. So kann<br />
beispielsweise die Performance-Verbesserung zwischen zwei Programmversionen gemessen<br />
werden. Aber auch die Unterschiede in Bezug auf die Performance beim Einsatz<br />
verschiedener Hardwarekonfigurationen können so bestimmt werden.<br />
Weiterhin lassen sich Performance Tests mit Lasttests kombinieren. Es wird also die<br />
Performance eines Programmes oder einer Funktion unter verschieden großen Lasten<br />
gemessen.<br />
3.2.2 Testszenarien<br />
Tests können auf unterschiedliche Weise durchgeführt werden. Im folgenden wird auf<br />
diese Szenarien näher eingegangen:<br />
• Lokaler Test<br />
• Remote Test<br />
• Verteilter Test<br />
Lokaler Test<br />
Ein lokaler Test wird direkt auf dem Testsystem ausgeführt, die Systemparameter werden<br />
dort ermittelt und verglichen. Es kann für den Test selbst aber nötig sein, dass<br />
weitere Systeme im Netzwerk verfügbar sind. Diese Systeme werden allerdings nicht<br />
vom Testframework kontrolliert oder beeinflusst.<br />
Lokale Tests haben den Vorteil, dass sie in der Regel auf einem beliebigen System installiert<br />
und ausgeführt werden können. Im Vergleich zu Remote und verteilten Tests ist<br />
der Konfigurationsaufwand minimal. Die Ergebnisse können auf dem Testsystem selbst<br />
ausgewertet werden. Problematisch wird dieser Ansatz, wenn auf mehreren Systemen<br />
Tests ausgeführt werden sollen. Der Aufwand, um die Ergebnisse auszuwerten steigt in<br />
diesem Fall deutlich an.
3.2 Ausprägungen von Tests 13<br />
Remote Test<br />
Ein Remote Test ist im Prinzip ein lokaler Test, welcher aber von einem zentralen System<br />
aus gesteuert wird. Dieses System kann auf einem oder mehreren entfernten Systemen die<br />
Tests ausführen. Die Ergebnisse jedes einzelnen Systems werden dann ebenfalls zentral<br />
auf diesem System erfasst. Es kann außerdem selbst eines der Systeme sein, auf dem<br />
Tests ausgeführt werden. Abbildung 3.1 zeigt eine mögliche Testumgebung.<br />
Server<br />
Tests<br />
ausführen<br />
LAN<br />
Testsystem<br />
Testsystem<br />
Testsystem<br />
Abbildung 3.1: Remote Test<br />
Mit diesem Ansatz ist es möglich, einen Test auf unterschiedlichen Systemen gleichzeitig<br />
auszuführen oder aber auch unterschiedliche Tests auf viele, eventuell sogar identische,<br />
Systeme zu verteilen. Der größte Vorteil gegenüber lokalen Tests ist die Tatsache, dass<br />
es nur noch eine zentrale Datei mit Ergebnissen sämtlicher Tests gibt. Allerdings ist der<br />
Konfigurationsaufwand etwas höher als bei lokalen Tests. Durch Automatisierung kann<br />
aber dieser Aufwand auf ein Minimum reduziert werden.<br />
Verteilter Test<br />
Bei verteilten Tests geht es nicht darum, Tests durch ein Lastverteilungsverfahren auf<br />
mehrere parallel arbeitende Systeme zu verteilen, um so eine schnellere Durchführung<br />
der Tests zu ermöglichen. Das ist schon mit Hilfe der Remote Tests möglich. Das Wort<br />
verteilt“ bezieht sich vielmehr auf den Testfall, der über mindestens zwei Systeme<br />
”<br />
verteilt ist. Diese Systeme sind über ein Netzwerk verbunden und können miteinander<br />
kommunizieren.
14 Kapitel 3 Software-Test<br />
Die einzelnen Schritte eines solchen Tests, also die Erzeugung und Ermittlung von Systemparametern,<br />
müssen zeitlich und inhaltlich aufeinander abgestimmt sein. Das bedeutet,<br />
dass jeder Schritt vom vorherigen abhängig ist und erst gestartet werden darf,<br />
wenn dieser abgeschlossen ist. Um diesen zeitlichen Ablauf zu kontrollieren, werden sogenannte<br />
Synchronisationspunkte verwendet. Die Testsysteme warten dann gegenseitig<br />
aufeinander, bis jeder an diesem Synchronisationspunkt angelangt ist und fahren erst<br />
dann mit den weiteren Testschritten fort. Abbildung 3.2 zeigt eine mögliche Testumgebung.<br />
Server<br />
Tests<br />
ausführen<br />
LAN<br />
Aktion 1<br />
Aktion 2<br />
Testsystem<br />
Testsystem<br />
Abbildung 3.2: Verteilter Test<br />
Verteilte Tests werden benötigt, wenn bestimmte Interaktionen zwischen den Testsystemen<br />
getestet werden sollen. Damit sind auf den Testsystemen stattfindende Aktionen<br />
gemeint, die die Interaktion der Systeme beeinflussen. Für die Erzeugung und Ermittlung<br />
von Systemparametern auf einem System ist es also nötig, dass auf einem anderen<br />
System in zeitlich koordinierter Abfolge bestimmte Aktionen durchgeführt werden.<br />
Weiterhin ist es möglich, Nachrichten zwischen den Testsystemen auszutauschen. Das<br />
heißt, dass es zur Laufzeit des Tests möglich ist, die einzelnen Testschritte zu beeinflussen.<br />
Es werden also nicht nur die jeweilgen Testschritte nach einem vorgegebenen<br />
Schema auf den beteiligten Systemen ausgeführt, sondern jeder Testschritt kann vom<br />
vorherigen beeinflusst werden und darauf reagieren.
3.3 Regressionstest 15<br />
3.3 Regressionstest<br />
Regressionstests werden eingesetzt, um eine Regression, also einen Rückschritt beziehungsweise<br />
eine Verschlechterung einer Software zu erkennen. Das heißt, dass Funktionalitäten<br />
getestet werden, die in einer älteren Version fehlerfrei waren. Außerdem soll<br />
verhindert werden, dass alte, eventuell schon behobene Fehler wieder in der Software<br />
auftauchen. Dazu bietet es sich an, alte Tesfälle zu wiederholen und die Ergebnisse mit<br />
den früheren Ergebnissen zu vergleichen.<br />
Die verschiedenen Testarten, die unter Punkt 3.2.1 beschrieben wurden, können prinzipiell<br />
alle für einen Regressionstest eingesetzt werden. Damit der Aufwand nicht zu groß<br />
wird, macht es Sinn, sämtliche Tests so weit wie möglich zu automatisieren. Dann ist es<br />
auch möglich, die Tests regelmäßig, insbesondere vor einem neuen Release, auszuführen.<br />
Der Aufwand für die Automatisierung darf aber keinesfalls unterschätzt werden (vgl.<br />
[Rät04, Seite 171]).<br />
Bei CoreBiz ist der Einsatz von Regressionstests besonders wichtig. Da bei einem CoreBiz<br />
System unterschiedlichste Software integriert wird, auf die keinen oder nur geringen<br />
Einfluss ausgeübt werden kann, darf nicht davon ausgegangen werden, dass sich die<br />
Software absolut gleich wie ihre Vorgängerversion verhält. Durch das Wiederholen von<br />
Testfällen kann auch diese Software getestet werden und somit läßt sich sicherstellen,<br />
dass sich diese Software weiterhin wie gewohnt in das System integrieren läßt.<br />
3.4 Zusammenfassung<br />
In diesem Kapitel wurde gezeigt, dass die Qualität von Software eine äußerst wichtige<br />
Rolle spielt, die nicht unterschätzt werden darf. Diese zu sichern ist die Aufgabe von<br />
Softwaretests, auf deren verschiedenen Ausprägungen eingegangen wurde. Speziell die<br />
verteilten Tests stellen dabei ein äußerst interessantes Gebiet dar. Als eine besondere<br />
Testart sind die Regressionstests zu verstehen. Damit werden zwar kaum neue Fehler<br />
gefunden, allerdings kann damit die Abwesenheit von Fehlern gezeigt werden. In diesem<br />
Zusammenhang ist die Automatisierung von Testfällen besonders wichtig. Darauf wird<br />
detailliert im nächsten Kapitel eingegangen.
16 Kapitel 3 Software-Test
Kapitel 4<br />
Test-Werkzeuge und Testsuites<br />
Es gibt sehr viele verschiedene freie und kommerzielle Werkzeuge, die das Testen von<br />
Software unterstützen. Im Folgenden werden einige dieser Werkzeuge vorgestellt und<br />
deren Nutzen diskutiert. Besonderes Augenmerk wird auf das Test Environment Toolkit<br />
gerichtet, welches die Basis für die CoreBiz Testumgebung darstellt.<br />
4.1 Automatisiertes Testen<br />
Das Automatisieren von Tests wurde schon im vorherigen Kapitel im Zusammenhang<br />
mit Regressionstests angesprochen. Es dient in erster Linie dazu, Tests auf einfache Art<br />
und Weise zu wiederholen, was natürlich gerade bei einem Regressionstest interessant<br />
ist. Es stellt sich also die Frage, was bei einem Testfall sinnvoll automatisiert werden<br />
kann und welche Werkzeuge dafür eingesetzt werden können. Dazu muß der Ablauf eines<br />
Tests betrachtet werden (vgl. [Tha02, Seite 228]):<br />
• Entwurf der Testfälle<br />
• Testumgebung vorbereiten<br />
• Für jeden Testfall folgende Schritte durchführen:<br />
– Testdaten zur Verfügung stellen<br />
– Test ausführen<br />
– Ergebnisse vergleichen und dokumentieren<br />
– Umgebung wiederherstellen<br />
• Ergebnisse zusammenfassen<br />
• Analysieren der Ergebnisse<br />
17
18 Kapitel 4 Test-Werkzeuge und Testsuites<br />
Die beiden hervorgehobenen Punkte, der Entwurf von Testfällen und das Analysieren<br />
der Ergebnisse, sind anspruchsvolle Aufgaben, die in der Regel von einem Menschen<br />
erledigt werden. Sie lassen sich daher nur bedingt automatisieren. Die anderen Punkte<br />
eignen sich dagegen sehr gut für die Automatisierung.<br />
Generell bieten sich Skriptsprachen an, um verschiedene Aufgaben, wie zum Beispiel das<br />
Zusammenfassen von Ergebnissen, zu erledigen. Speziell unter Unix/Linux ist hier der<br />
Einsatz von Werkzeugen wie ”<br />
awk“ , ”<br />
sed“ , ”<br />
diff“ etc. sinnvoll. Das Verwenden eines<br />
Test Management Tools hilft dabei, vor allem die Schritte eines einzelnen Testfalls zu<br />
automatisieren. Darauf wird später in diesem Kapitel noch detailliert eingegangen.<br />
Um das Vorbereiten der Testumgebung zu automatisieren, können zum Beispiel Werkzeuge<br />
zum Klonen von Festplatten einsetzt werden. Mit deren Hilfe kann ein bestimmter<br />
Zustand eines Testsystems ”<br />
eingefroren“ und absolut identisch wiederhergestellt werden.<br />
Eine weitere Möglichkeit ist der Einsatz einer Virtualisierungssoftware. Diese simuliert<br />
einen kompletten Computer und bietet in der Regel ebenfalls Funktionen an, um einen<br />
bestimmten Zustand zu speichern und wiederherzustellen. Mit einer Virtualisierungssoftware<br />
können außerdem Funktionen automatisiert werden, die mit einem realen Computer<br />
manuell erledigt werden müßten. Dazu gehört zum Beispiel das Einschalten eines Computers.<br />
Werden diese Möglichkeiten mit Skripten kombiniert, ist es möglich ein System<br />
auf schnelle und einfache Weise in einen Zustand zu bringen, in dem getestet werden<br />
kann.<br />
Trotz diesen Möglichkeiten muß jedoch klar sein, dass sich eine hunderprozentige Automatisierung<br />
von Tests einerseits nur schwer und mit größtem Aufwand erreichen läßt,<br />
andererseits aber oft auch nicht sinnvoll ist. Automatisierte Tests bergen verschiedene<br />
Probleme in sich (vgl. [Tha02, Seite 230] und [Kan02, Seite 102]):<br />
• Der Aufwand für die Automatisierung ist sehr hoch.<br />
• Es werden nur wenige neue Fehler entdeckt, da diese schon durch die manuellen<br />
Tests gefunden werden.<br />
• Die Wartung der automatischen Tests kann so aufwendig werden, dass ein manueller<br />
Test sinnvoller ist.<br />
• Fehler in Tests können in einer automatisierten Umgebung unbeachtet bleiben.<br />
• Ausführen von veralteten Tests, die zwar in einer älteren Version der Software Sinn<br />
machten, aber in der aktuellen Version nur Ressourcen und Zeit verschlingen.<br />
• Konzentration auf Testfälle, die sich leicht in die automatisierte Testumgebung<br />
einbinden lassen. Die Auswirkung ist eine geringe Testabdeckung.
4.2 Test-Werkzeuge 19<br />
Rob Savoye, Projektleiter und Entwickler des Test-Frameworks DejaGnu, schreibt in<br />
einem Usenet-Artikel:<br />
The higher level code that we used to automate all the testing was never part<br />
”<br />
of DejaGnu, and was pretty heavily customized for our own particular setup.<br />
It worked pretty good, but once we had a few dozen systems, maintaining it<br />
became close to a full-time job.“ [Savc]<br />
Er spricht damit genau die Problematik an, die eine Automatisierung von Tests mit sich<br />
bringen kann. Solange die Testumgebung statisch ist, lassen sich die Testfälle problemlos<br />
ausführen und wiederholen. Sobald sich aber Systeme verändern oder neue Systeme zur<br />
Testumgebung hinzugefügt werden, steigt der Aufwand stark an, um die automatisierten<br />
Tests der neuen Umgebung anzupassen.<br />
Andere Erfahrungen aus der Praxis zeigen jedoch, dass es sich in den meisten Fällen<br />
lohnt, Tests zumindest teilweise zu automatisieren (vgl. [Tha02, Seite 239ff]). Das Ziel<br />
sollte jedoch nicht das Finden von möglichst vielen neuen Fehlern sein, sondern vielmehr<br />
die Abwesenheit von Fehlern zu zeigen. Wie zu Beginn schon erwähnt, macht die Automatisierung<br />
von Tests insbesondere im Zusammenhang mit einem Regressionstest Sinn.<br />
Damit läßt sich dann mit minimalem Aufwand die wichtigsten Funktionalitäten einer<br />
Software überprüfen.<br />
4.2 Test-Werkzeuge<br />
Test-Werkzeuge sind Programme oder Bibliotheken, die bestimmte Funktionalitäten zur<br />
Verfügung stellen, um den Testprozess zu vereinfachen. Viele dieser Werkzeuge sind<br />
auf eine bestimmte Aufgabe spezialisiert. Beispielsweise sind GUI Test Tools darauf<br />
ausgelegt, grafische Benutzerobeflächen zu testen. Unit Test Tools setzen dagegen auf<br />
einer unteren Ebene an und sind für Komponententests geeignet.<br />
Unter [Fau] gibt es eine Übersicht über verschiedene Test Werkzeuge, kategorisiert nach<br />
der Art des Werkzeugs. Speziell für Open Source Werkzeuge gibt es eine Übersicht unter<br />
[Abe].<br />
In der CoreBiz-Testumgebung werden unterschiedliche Arten von Tests ausgeführt. Um<br />
einen Regressionstest für diese verschiedenen Tests zu realisieren, müssen sie ohne großen<br />
Aufwand wiederholt werden können. Daher wird ein so genanntes Test Management Tool<br />
benötigt. Dieses Werkzeug bietet ein Framework, um die Erstellung, das Ausführen und<br />
die Auswertung von unterschiedlichen Testarten in einer homogenen Art und Weise zu<br />
ermöglichen. Außerdem hilf es, einen beachtlichen Teil eines Tests zu automatisieren.
20 Kapitel 4 Test-Werkzeuge und Testsuites<br />
4.2.1 Vergleich von Test Management Tools<br />
Im Folgenden werden einige Test Management Tools untersucht und verglichen. Kriterium<br />
für die Auswahl war primär die Verfügbarkeit der Software unter Linux. Bei der<br />
Recherche nach geeigneter Software zeigte sich, dass es für Linux relativ wenig Software<br />
in diesem Bereich gibt und speziell kommerzielle Software fast überhaupt nicht vorhanden<br />
ist. Im Gegensatz dazu gibt es für Microsoft Windows eine Vielzahl kommerzieller<br />
Test-Werkzeuge. Eine Erklärung dafür könnte die Tatsache sein, dass die überwiegende<br />
Mehrheit an kommerzieller Software unter Windows und für Windows entwickelt wird.<br />
Dagegen wird Software für Linux meistens von Freiwilligen entwickelt, die kein Geld für<br />
Testwerkzeuge ausgeben wollen oder können. Daher macht es für die Anbieter kommerzieller<br />
Test Management Tools wenig Sinn ihre Software für Linux zu entwickeln oder<br />
zu portieren.<br />
Nachfolgend wird auf drei verschiedene Test Management Tools näher eingegangen:<br />
• DejaGnu (vgl. [Sava])<br />
• Software Testing Automation Framework (STAF) (vgl. [STA])<br />
• Test Environment Toolkit (TET) (vgl. [Theb])<br />
DejaGnu<br />
DejaGnu ist das Test-Framework der Free Software Foundation und ist unter der GNU<br />
General Public License erhältlich. Entwickelt wird es maßgeblich von Rob Savoye. Entstanden<br />
ist dieses Projekt durch die Tatsache, dass sein damaliger Arbeitgeber Cygnus<br />
Solutions ein Test-Framework mit folgenden Eigenschaften benötigte (vgl. [Savb]):<br />
• Automatisches ausführen von vielen Tests<br />
• Pattformübergreifend<br />
• Testen von interaktiven Programmen<br />
• Testen von batch-orientierten Programmen<br />
DejaGnu ist in ”<br />
Expect“ entwickelt, welches wiederum ”<br />
Tcl“ benutzt. Weiterhin ist es<br />
speziell darauf ausgelegt, auf so genannten Einplatinenrechnern Tests auszuführen. Diese<br />
haben oft sehr unterschiedliche Kommunikationsschnittstellen. Deshalb unterstützt<br />
DejaGnu rsh, rlogin, telnet, tip, kermit und mondfe für die Kommunikation mit entfernten<br />
Testsystemen.<br />
Zusammen mit TET ist DejaGnu das einzigste Framework, das den POSIX-Standard<br />
1003.3 unterstützt (vgl. [Savb]). Diese Spezifikationen definieren, welche Funktionalitäten<br />
ein Framework aufweisen muß, um POSIX-Konformitätstests durchführen zu<br />
können. Diese Eigenschaften können aber auch für andere Testfälle genutzt werden.
4.2 Test-Werkzeuge 21<br />
Software Testing Automation Framework<br />
Das Software Testing Automation Framework, kurz STAF, wird maßgeblich von IBM<br />
entwickelt und ist unter der Common Public License (CPL) lizenziert. Es wird viel Wert<br />
darauf gelegt, dass es nur minimale Leistungsanforderungen sowohl an die Hardware als<br />
auch an die Software stellt.<br />
Sämtliche Funktionalitäten sind bei STAF in so genannten Services ausgelagert. Neben<br />
einer großen Anzahl von Standard-Services, die beispielsweise das Logging durchführen,<br />
können beliebige weitere Services erstellt werden. Dadurch läßt sich STAF sehr einfach<br />
erweitern.<br />
Interessant ist auch das Konzept der so genannten ”<br />
Trust Levels“ von STAF. Mit ihnen<br />
lassen sich bestimmte Rechte auf den Testsystemen definieren. So kann zum Beispiel<br />
verhindert werden, dass Dateien auf einem bestimmten System gelöscht werden oder das<br />
System heruntergefahren wird. Die Einstellungen können per System oder per Benutzer<br />
durchgeführt werden.<br />
Test Environment Toolkit<br />
Das Test Environment Toolkit, kurz TET, ist ein plattformunabhängiges Test-Framework<br />
von ”<br />
The Open Group“. ”<br />
The Open Group“ ist ein herstellerunabhängiges Konsortium,<br />
dem beispielsweise Unternehmen wie Hewlett-Packard, IBM oder Sun Microsystems angehören.<br />
Dieses Konsortium war unter anderem auch an der Entwicklung der POSIX-<br />
Spezifikationen und des Lightweight Directory Access Protocol beteiligt.<br />
Das Test Environment Toolkit bietet Schnittstellen zu einer Vielzahl von Programmiersprachen<br />
und ist sowohl in einer freien, als auch in einer kommerziellen Version verfügbar.<br />
Ein besonderes Merkmal ist die Möglichkeit verteilte Tests durchzuführen.<br />
Neben der kommerziellen Version ”<br />
TETware“ ist das Test Environment Toolkit in zwei<br />
Varianten unter der ”<br />
Artistic License“ verfügbar. Zum Zeitpunkt des Schreibens dieser<br />
Arbeit wurden folgende Versionen veröffentlicht:<br />
• ”<br />
TET-Lite“ in der Version 3.6<br />
• Ein sogenanntes ”<br />
full source release“, das sowohl ”<br />
TET-Lite“ als auch ”<br />
Distributed<br />
TET“ in der Version 3.3 enthält<br />
Der Unterschied zwischen diesen beiden Versionen besteht im wesentlichen in der Einschränkung,<br />
Remote oder verteilte Tests in der Lite Version durchzuführen.
22 Kapitel 4 Test-Werkzeuge und Testsuites<br />
Features STAF Dejagnu TET<br />
Open Source ja ja ja<br />
Lizenz CPL GPL Artistic<br />
Gleiches Front-End für alle Tests ja ja ja<br />
Einheitliches Format für Ergebnisse ja ja ja<br />
Testfälle können X mal wiederholt werden nein nein ja<br />
Testfälle können eine bestimmte Zeit lang wiederholt<br />
nein nein ja<br />
werden<br />
Testfälle können zufällig ausgewählt werden nein nein ja<br />
Remote Tests ja ja ja<br />
Verteilte Tests nein nein ja<br />
Plattformübergreifend ja ja ja<br />
POSIX TM 1003.3 konform nein ja ja<br />
Logging Eigenschaften ja ja ja<br />
Debugging Eigenschaften ja ja ja<br />
Datenbank für Ergebnisse nein nein nein<br />
Dateien über das Netzwerk kopieren ja ja nein<br />
Security Eigenschaften ja nein nein<br />
Rückgabe von komplexen Datenstrukturen (Marshalling)<br />
ja nein nein<br />
Tabelle 4.1: Vergleich von Test Management Tools<br />
Fazit<br />
Die Tabelle 4.1 zeigt einen Überblick über die Features dieser Werkzeuge (vgl [Lin]).<br />
Alle drei Werkzeuge verfügen über die nötigen Funktionen, mit denen es prinzipiell<br />
möglich ist, eine größere Anzahl von Tests, auch auf entfernten Systemen, durchzuführen.<br />
STAF kann besonders durch die einfach erweiterbaren Services beeindrucken, was das<br />
Framework sehr flexibel macht. Die Entscheidung fiel schließlich aber zugunsten des Test<br />
Environment Toolkit aus. Die Gründe dafür waren:<br />
• Verteilte Tests sind möglich.<br />
• Das Framework wird bereits seit September 1989 von ”<br />
The Open Group“ entwickelt<br />
und gilt als sehr stabil und ausgereift.<br />
• Innerhalb des Unternehmens gibt es schon Erfahrungen mit TET.<br />
• Die Testsuites der Linux Standard Base basieren ebenfalls auf TET<br />
Nachfolgend wird noch einmal detailliert auf das Test Environment Toolkit eingegangen.
4.2 Test-Werkzeuge 23<br />
4.2.2 Test Environment Toolkit<br />
Im folgenden werden allgemein die Funktionen und Besonderheiten von Distributed TET<br />
erläutert. Dennoch sollte es abgesehen von der Einschränkung, Remote oder verteilte<br />
Tests durchzuführen, keine wesentlichen Unterschiede zu TET-Lite geben.<br />
Überblick<br />
Testsystem 1 Testsystem 2<br />
Testsystem 3<br />
Test Case Controller<br />
Test Case<br />
Controller Daemon<br />
Test Case<br />
Controller Daemon<br />
Test Case<br />
Controller Daemon<br />
Test Case<br />
Manager<br />
Test Case<br />
Manager<br />
Test Case<br />
Manager<br />
Abbildung 4.1: Die Komponenten von TET<br />
Ein Test wird immer durch das Programm ”<br />
tcc“, dem Test Case Controller ausgelöst. Es<br />
gibt drei verschiedene Modi: ”<br />
Build“, ”<br />
Execute“ und ”<br />
Clean“. Der Test Case Controller<br />
verteilt diesen Auftrag an den Test Case Controller Daemon ( ”<br />
tccd“) aller beteiligten<br />
Systeme. Der Test Case Manager (TCM) wird implizit durch das Benutzen einer der<br />
TET-APIs eingebunden und kümmert sich um den Ablauf der Test Cases (Testfälle).<br />
Abbildung 4.1 zeigt, wie ein Test in der TET-Umgebung gestartet wird. Interessant<br />
dabei ist, dass nahezu beliebig viele weitere Testsysteme hinzugefügt werden können.<br />
Das System, auf dem der Test Case Controller gestartet wird, muß nicht zwingend den<br />
Test selbst ausführen.<br />
Aufbau eines Testfalls<br />
Ein Test Case besteht aus einem oder mehreren so genannter Invocable Components<br />
(IC). Diese wiederum bestehen aus einem oder mehreren Test Purposes (TP). Abbildung<br />
4.2 zeigt den Aufbau eines Testfalls.
24 Kapitel 4 Test-Werkzeuge und Testsuites<br />
Test Case<br />
Invocable<br />
Component 1<br />
Invocable<br />
Component 2<br />
Test Purpose 1<br />
Test Purpose 2<br />
Test Purpose ...<br />
Test Purpose 1<br />
Test Purpose 2<br />
Test Purpose ...<br />
Abbildung 4.2: Aufbau eines Testfalls im TET<br />
Direktiven<br />
Neben dem simplen Ausführen eines Tests bietet das Test Environment Toolkit so genannte<br />
Direktiven an. Teilweise können diese miteinander kombiniert werden. So ist es<br />
zum Beispiel möglich einen zufällig ausgewählten Test auf einem bestimmten entfernten<br />
System genau acht mal zu wiederholen. In der Konfigurationsdatei ”<br />
tet scen“ werden<br />
diese Direktiven zusammen mit den Testfällen aufgelistet. Die wichtigsten Direktiven<br />
sind:<br />
• :repeat: - Einen Test eine bestimmte Anzahl lang wiederholen<br />
• :timed loop: - Einen Test eine bestimmte Zeit lang wiederholen<br />
• :random: - Einen zufälligen Test ausführen<br />
• :parallel: - Tests parallel (gleichzeitig) ausführen<br />
• :remote: - Tests auf entfernten Systemen durchführen<br />
• :distributed: - Verteilte Tests auf entfernten Systemen durchführen<br />
Die Direktiven :remote: und :distributed: benötigen als Parameter eine dreistellige System<br />
ID. Jedem System auf dem Tests ausgeführt werden können, ist solch eine ID zuge-
4.2 Test-Werkzeuge 25<br />
wiesen. Der Test Case Controller kann diese ID dann mit Hilfe der Konfigurationsdatei<br />
systems“ zu einer entsprechenden IP-Adresse eines Testsystems auflösen.<br />
”<br />
Die nachfolgende Szenario-Datei beschreibt einen verteilten Test, der auf zwei Testsystemen<br />
(001 und 002) ausgeführt wird.<br />
all<br />
"starting LDAP tests"<br />
:distributed,001,002:<br />
:repeat,1000:@/ldap-latenz/ldap-latenz<br />
:/ldap-performance/ldap-performance<br />
:timed_loop,3600:@/ldap-konflikt/ldap-konflikt<br />
:enddistributed:<br />
"LDAP tests finished"<br />
Das Journal<br />
Nachdem ein Testfall abgeschlossen ist, werden die Ergebnisse in der Datei ”<br />
journal“<br />
abgespeichert. Diese Datei ist unabhängig vom Test immer gleichartig aufgebaut und<br />
kann dadurch einfach, zum Beispiel durch Skripte, weiter bearbeitet werden. Nachfolgend<br />
ein kleiner Ausschnitt eines Journals:<br />
10|4 /ldap-latenz/ldap-latenz 16:48:17|TC Start, scenario ref 5-1<br />
15|4 3.3 1|TCM Start<br />
400|4 1 1 16:48:17|IC Start<br />
200|4 1 16:48:17|TP Start<br />
520|4 1 00226816 1 1|sync 1 OK (client)<br />
520|4 1 00128614 1 2|sync 1 OK (base)<br />
520|4 1 00226816 1 4|delay = 7055 microseconds = 7 milliseconds<br />
220|4 1 0 16:48:17|PASS<br />
410|4 1 1 16:48:17|IC End<br />
80|4 0 16:48:18|TC End, scenario ref 5-1<br />
Die Zeilen, die beispielsweise mit 520 beginnen, sind Meldungen, die die Test Purposes<br />
auf den verschiedenen Systemen selbst ausgeben können. Die Nummer 220 bedeutet<br />
dagegen, dass diese Zeile das Ergebnis des Test Purpose enthält. Es kann also jede Zeile<br />
auf einfache Weise interpretiert werden. Eine ausführliche Beschreibung des Aufbaus<br />
eines Journals können in der TETware User Guide beziehungsweise in der TETware<br />
Programmers Guide gefunden werden (vgl. [Thed] und [Thec]).
26 Kapitel 4 Test-Werkzeuge und Testsuites<br />
4.3 Testsuites<br />
Eine Testsuite ist eine Sammlung von Testfällen. Es ist möglich, dass die einzelnen<br />
Tesfälle einer Testsuite aufeinander aufbauen. Obwohl eine Testsuite immer aus einzelnen<br />
Tesfällen besteht, kann diese dann nur im Verbund ausführt werden. Diese Abhängigkeit<br />
sollte aber so weit wie möglich verhindert werden, um jeden Testfall auch individuell<br />
ausführen zu können (vgl. [Rät04, Site 193]).<br />
Nachfolgend werden die Testsuites der Linux Standard Base und die für CoreBiz geplanten<br />
Testsuites vorgestellt.<br />
4.3.1 Linux Standard Base Testsuites<br />
Das Linux Standard Base Project (vgl. [Frec]) definiert verschiedene Spezifikationen<br />
mit dem Ziel, die verschiedenen Linux Distributionen hinsichtlich der Dateisystemstruktur<br />
und der Basisbibliotheken zu vereinheitlichen, um eine zu starke Zersplitterung<br />
zu vermeiden. Die Spezifikationen beinhalten teilweise auch POSIX-Spezifikationen.<br />
Um diese Spezifikationen zu überprüfen, stellt das Projekt folgende Testsuites frei zur<br />
Verfügung:<br />
• Filesystem Hierarchy Specification Tests<br />
• POSIX.1 Conformance Tests<br />
• POSIX thread (pthread) Conformance Tests<br />
• Linux Operating System Calls Test<br />
Die Tests bauen auf das Framework VSXgen auf, welches wiederum auf TET-Lite basiert.<br />
VSXgen ist ein Framework, das Betriebssystemfunktionen abstrahiert und in verschiedenen<br />
Bibliotheken zur Verfügung stellt. 97% dieser Tests wurden von ”<br />
The Open Group“<br />
entwickelt (vgl. [Thea]). Das ist damit zu erklären, dass ”<br />
The Open Group“ schon sehr<br />
lang Testsuites für die POSIX Konformität anbietet. Diese Testsuites waren ehemals<br />
nur gegen sehr teure Lizenzgebühren erhältlich. Heute werden sie aber unter einer freien<br />
Lizenz zur Verfügung gestellt.<br />
4.3.2 CoreBiz Testsuites<br />
Eine kleinere Testsuite mit verschiedenen lokalen Tests existiert bereits. Diese wurden<br />
wie die Tests der LSB mit Hilfe von TET-Lite entwickelt.<br />
Geplant ist eine weitere Testsuite, die mit Hilfe von Distributed TET auf beliebig vielen<br />
entfernten Testsystemen ausführbar ist. Es ist denkbar, dass diese Testsuite die bereits<br />
existierende Testsuite integriert. Interessant ist die Frage, ob es eine Möglichkeit gibt,
4.4 Zusammenfassung 27<br />
auch die LSB Testsuites zu integrieren. Dieser Ansatz wird im Kapitel ”<br />
CoreBiz Testsuite<br />
- Remote Tests“ diskutiert.<br />
Speziell für die verteilten Tests wird eine weitere Testsuite erstellt. Diese enthält Testfälle,<br />
die in der Regel auf zwei Systemen, einem CoreBiz Base Server und einem CoreBiz Client<br />
ablaufen. Im Kapitel ”<br />
CoreBiz Testsuite - Verteilte Tests“ wird detailliert auf dieses<br />
Thema eingegangen.<br />
4.4 Zusammenfassung<br />
In diesem Kapitel wurde auf Möglichkeiten der Automatisierung von Tests eingegangen.<br />
Das führt zu der Erkenntnis, dass Testwerkzeuge benötigt werden, um dies realisieren<br />
zu können. Testwerkzeuge bieten aber noch eine ganze Reihe weiterer Vorteile, wie zum<br />
Beispiel die einheitliche Darstellung von Testergebnissen. Für die CoreBiz-Testumgebung<br />
werden für die Regressionstests einerseits Werkzeuge für die Automatisierung benötigt,<br />
andererseits aber vor allem ein Test Management Tool, um verschiedenste Tests in einem<br />
homogenen Rahmen durchzuführen. Dafür wurde das Test Environment Toolkit gewählt,<br />
welches sich vor allem durch die Möglichkeit verteilte Tests durchzuführen von anderen<br />
Frameworks hervorhebt.
28 Kapitel 4 Test-Werkzeuge und Testsuites
Kapitel 5<br />
CoreBiz Testsuite - Remote Tests<br />
In diesem Kapitel wird auf die Implementierung des Test-Frameworks eingegangen. Es<br />
wird diskutiert, ob und wie die schon vorhandenen Tests der Linux Information Systems<br />
AG und die Testsuites der Linux Standard Base integriert werden können. Weiterhin wird<br />
der Aufbau einer Testumgebung erläutert, die es erlaubt Remote Tests auszuführen. Die<br />
prototypische Implementierung eines Testfalls veranschaulicht die Thematik.<br />
5.1 Ausgangssituation<br />
Für die Qualitätssicherung von CoreBiz wurden bisher die Testsuites der Linux Standard<br />
Base eingesetzt. Diese Tests basieren auf den Frameworks TET-Lite und VSXgen.<br />
Zusätzlich sind selbst entwickelte Tests vorhanden, die allerdings wie die Testsuites der<br />
LSB nur lokal auf einem Testsystem ausgeführt wurden. Diese Tests sind ebenfalls mit<br />
Hilfe von TET-Lite implementiert.<br />
5.2 Aufbau der Testumgebung<br />
Nachfolgend werden die Komponenten vorgestellt, die für den Aufbau der Testumgebung<br />
benötigt werden.<br />
5.2.1 TET-Lite vs. Distributed TET<br />
Für das Design der Testumgebung mit Hilfe des Test Environment Toolkits können im<br />
Prinzip zwei Möglichkeiten in Erwägung gezogen werden. Damit verknüpft ist allerdings<br />
auch die Frage, ob und wie die bisherigen CoreBiz-spezifischen Testfälle und die Testsuites<br />
der LSB integriert werden können. Hier muß sich noch einmal klar gemacht werden,<br />
dass mit TET-Lite ausschließlich lokale Tests möglich sind. Distributed TET dagegen<br />
erlaubt das Ausführen von Remote Tests und verteilten Tests.<br />
29
30 Kapitel 5 CoreBiz Testsuite - Remote Tests<br />
Die erste Variante würde die Erweiterung der bisherigen Testsuite bedeuten. Testfälle<br />
würden also mit Hilfe des Frameworks TET-Lite und optional VSXgen implementiert<br />
werden. Das hätte den Vorteil, dass diese Testsuite und die Testsuites der LSB sich in der<br />
gleichen Testumgebung ausführen lassen würden. Es müßte also die bisherige Testumgebung<br />
nicht verändert werden. Der Nachteil ist allerdings, dass so auf die Möglichkeiten<br />
von Distributed TET verzichtet wird. Um Tests auf entfernten Systemen durchführen<br />
zu können, müßte ein weiteres Framework entwickelt werden. Beispielsweise wäre vorstellbar,<br />
dass Tests mit Hilfe von ssh (Secure Shell) gestartet werden und die Ergebnisse<br />
mittels scp (Secure Copy) oder NFS (Network File System) an eine zentrale Stelle kopiert<br />
werden.<br />
Die zweite Variante, die schließlich auch implementiert wurde, setzt dagegen auf Distributed<br />
TET auf. Der größte Vorteil ist sicherlich, dass damit ein Framework zur<br />
Verfügung steht, dass Tests auf beliebig vielen entfernten Systemen grundsätzlich zuläßt.<br />
Weiterhin ist so auch gewährleistet, dass verteilte Tests in dieser Umgebung implementiert<br />
werden können. Allerdings muß hier die Frage gestellt werden, ob und wie die schon<br />
vorhandenen Testsuites in die neue Umgebung integriert werden können.<br />
Als problematisch stellt sich dabei das Framework VSXgen heraus, welches nur für TET-<br />
Lite verfügbar ist. Für die CoreBiz-spezifische Testfälle ist das nicht von Bedeutung,<br />
da die Funktionalitäten dieses Frameworks bisher nicht genutzt wurden. Da VSXgen<br />
hauptsächlich grundlegende Betriebssystemfunktionen in einer abstrahierten Form zur<br />
Verfügung stellt, ist es im Hinblick auf die Zukunft eher unwahrscheinlich, dass diese<br />
Funktionen von Testfällen aus den CoreBiz Testsuites benötigt werden.<br />
Die Testsuites der LSB sind jedoch ohne VSXgen nicht ausführbar. Für die Integration<br />
der LSB-Testsuites wäre also die Portierung dieses Frameworks auf Distributed TET<br />
nötig. Das wäre zwar mit etwas Aufwand durchaus möglich, dennoch ist dieser Schritt<br />
und der damit verbundene Aufwand nicht unbedingt notwendig. Die Testsuites der LSB<br />
haben ein ganz anderes Ziel als die CoreBiz Testsuites. Mit ihnen werden keine neuen<br />
Fehler in Produkten gefunden. Es kann damit aber gezeigt werden, dass CoreBiz-Systeme<br />
gewisse Standards und Spezifikationen einhalten. Während es bei CoreBiz-spezifischen<br />
Tests je nach Testart Sinn macht, diese möglichst oft und regelmäßig durchzuführen, ist<br />
es bei den Tests der LSB ausreichend, diese zum Beispiel vor einem neuen Release durchzuführen.<br />
Sie werden also nicht direkt für die Produktentwicklung benötigt und müssen<br />
deshalb auch nicht so häufig ausgeführt werden. Weiterhin werden die Testsuites der<br />
LSB nicht von der Linux Information Systems AG entwickelt. Es darf daher nicht davon<br />
ausgegangen werden, dass zukünftige Versionen der Testsuites kompatibel zur jetzigen<br />
Testumgebung sind. Von diesen Gesichtspunkten aus betrachtet, ist es vertretbar und<br />
sinnvoll, die LSB und CoreBiz Testsuites weitestgehend unabhängig voneinander auszuführen.<br />
Im Vordergrund sollten die Anforderungen für die CoreBiz Testsuites stehen<br />
und das Framework sollte maßgeblich danach ausgerichtet sein.
5.2 Aufbau der Testumgebung 31<br />
5.2.2 Virtualisierungssoftware<br />
Basis der Testumgebung ist der CoreBiz Factory Server. Auf diesem System werden dann<br />
mit Hilfe der Software ”<br />
VMware Workstation“ ein oder mehrere Testsysteme ”<br />
virtuell“<br />
aufgesetzt. Dieser Ansatz bringt verschiedene Vorteile mit sich:<br />
• Es muß keine weitere Hardware für Testssysteme angeschafft werden<br />
• Es können beliebig viele weitere Systeme hinzugefügt werden<br />
• Mit Hilfe so genannter Snapshots kann ein bestimmter Zustand eines Systems<br />
eingefroren werden<br />
• Systeme können schnell und einfach dupliziert werden<br />
• Verschiedene Aktionen wie zum Beispiel das Einschalten eines Rechners, die normalerweise<br />
manuell durchgeführt werden müßten, können automatisiert werden.<br />
Abbildung 5.1 zeigt den Aufbau einer Testumgebung für Remote Tests, die mit Hilfe<br />
von VMware und Distributed TET realisiert wurde. Die Testumgebung ist im Prinzip<br />
frei skalierbar. Eine Einschränkung setzen nur die TET System IDs, die von 000 bis<br />
999 vergeben werden können und natürlich die Leistungsfähigkeit der Hardware, auf der<br />
VMware installiert ist.<br />
CoreBiz Factory<br />
Test Case<br />
Control Daemon<br />
VMware<br />
LAN<br />
Test Case<br />
Control Daemon<br />
Test Case<br />
Control Daemon<br />
Test Case<br />
Control Daemon<br />
Testsystem 1<br />
(Bsp.: CoreBiz Base)<br />
Testsystem 2, optional<br />
(Bsp.: CoreBiz Client)<br />
Weitere Testsysteme,<br />
optional<br />
Abbildung 5.1: Aufbau der CoreBiz Testumgebung für Remote Tests
32 Kapitel 5 CoreBiz Testsuite - Remote Tests<br />
Eine Virtualisierungssoftware bringt allerdings auch Probleme mit sich. Auf diese wird im<br />
Zusammenhang mit verteilten Tests im nächsten Kapitel noch detailliert eingegangen.<br />
5.2.3 Konfiguration der Systeme<br />
Das Test Environment Toolkit installiert sich standardmäßig in das Verzeichnis<br />
/home/tet. Da bei einem CoreBiz System die Benutzerverzeichnisse in der Regel per<br />
NFS über das Netzwerk bezogen werden, würde das zu Problemen führen. Damit sichergestellt<br />
werden kann, dass sich TET auf einer lokalen Festplatte befindet, wird es in<br />
das Verzeichnis /opt/tet-full installiert. Dazu wurde ein entsprechendes Debian-Paket<br />
erstellt, das neben den Programmen und den Bibliotheken von TET außerdem ein Startskript<br />
für den Test Case Controller Daemon enthält. Bei der Installation dieses Pakets<br />
werden automatisch der Benutzer und die Gruppe ”<br />
tet“ angelegt. Um das Test Environment<br />
Toolkit einsetzen zu können, muß nur noch die Datei ”<br />
systems.equiv“ auf<br />
dem Testsystem beziehungsweise die Datei ”<br />
systems“ auf dem CoreBiz Factory Server<br />
angepaßt werden.<br />
Für jede Testsuite gibt es ebenfalls ein eigenes Debian-Paket. Dieses installiert die zugehörigen<br />
Testfälle unterhalb des Verzeichnisses /opt/tests//.<br />
Da es bestimmte Tests geben kann, die nicht auf allen CoreBiz Systemen ausgeführt<br />
werden können, ist es notwendig, innerhalb der Testumgebung standardisierte TET-ID-<br />
Nummern zu vergeben. Dann kann die Szenario-Datei schon beim Erstellen des Tests<br />
entsprechend konfiguriert werden, so dass der Test nur auf bestimmten Systemen gestartet<br />
wird. Wichtig wird dieser Punkt auch im Hinblick auf verteilte Tests.<br />
ID CoreBiz System<br />
000 CoreBiz Factory<br />
001 CoreBiz Base<br />
002 CoreBiz Client<br />
003<br />
bis<br />
009 CoreBiz Backup)<br />
ab<br />
010<br />
reserviert für bestimmte<br />
CoreBiz Systeme (Beispiel:<br />
für beliebig weitere Testsysteme<br />
nutzbar<br />
Tabelle 5.1: Zuweisung von TET-IDs zu CoreBiz Systemen<br />
Tabelle 5.1 zeigt die Zuweisung von IDs zu den jeweiligen CoreBiz Systemen. ID 000 ist<br />
immer für den CoreBiz Factory Server reserviert, von dem aus sämtliche Tests gestartet<br />
werden, auf dem selbst aber in der Regel keine Tests ablaufen. ID 001 und 002 werden<br />
für den CoreBiz Base Server beziehungsweise den CoreBiz Client reserviert. Die IDs<br />
003 bis 009 werden vorerst für Systeme wie zum Beispiel dem CoreBiz Backup Server
5.3 Ablauf eines Testfalls 33<br />
reserviert, für die zur Zeit aber noch keine speziellen Testfälle existieren. Alle weiteren<br />
IDs können beliebig für zusätzliche Testsysteme benutzt werden.<br />
Ein weiteres Problem ist die Notwendigkeit bestimmte Programme mir root-Rechten<br />
auszuführen. Der Test Case Control Daemon und damit auch die Tests werden aber<br />
standardmäßig als Benutzer ”<br />
tet“ ausgeführt. Das Problem kann am einfachsten mit<br />
Hilfe des Programms ”<br />
sudo“ gelöst werden. Durch den Eintrag der Zeile<br />
tet ALL = NOPASSWD: ALL<br />
in /etc/sudoers können alle Programme als Benutzer root ausgeführt werden.<br />
5.3 Ablauf eines Testfalls<br />
Der Testprozess läßt sich in drei Phasen beschreiben:<br />
• Phase 1 - Installation:<br />
Die Testsysteme werden weitestgehend automatisch über das Netzwerk installiert.<br />
In der Regel wird ein CoreBiz Base Server und ein CoreBiz Client als Testsystem<br />
dienen, aber es können natürlich prinzipiell alle CoreBiz Systeme verwendet werden.<br />
Dannach muß TET und die CoreBiz Testsuite installiert werden und unter<br />
Umständen die Konfiguration von TET angepaßt werden. Dieser Schritt kann in<br />
Zukunft sicherlich auch relativ einfach automatisiert werden. Aus den verschiedenen<br />
CoreBiz Profilen könnte jeweils ein entsprechendes Testprofil generiert werden,<br />
das eine zusätzliche Komponente mit TET, den CoreBiz Testsuites und eventuell<br />
sogar eine passende Konfiguration enthält.<br />
• Phase 2 - Testing:<br />
Nach der Installation sollte auf allen Testsystemen der Test Case Controller Daemon<br />
aktiv sein. Nun kann festgelegt werden, auf welchen Testsystemen überhaupt getestet<br />
werden soll beziehungsweise welche Testfälle auf den verschiedenen Testsystemen<br />
ausgeführt werden sollen. Dazu kann die Szenario-Datei angepaßt werden.<br />
Standardmäßig wird die vollständige Testsuite ausgeführt. Die Testfälle werden<br />
dann vom CoreBiz Factory Server aus mit Hilfe des Test Case Controllers gestartet.<br />
Die Tests selbst werden automatisch ausgeführt und die Ergebnisse zentral<br />
auf dem Server abgelegt.<br />
• Phase 3 - Reporting:<br />
Für die Auswertung der Journale kann beispielsweise das Perl-Skript ”<br />
tetreport.pl“<br />
benutzt werden, das von TET mitgeliefert wird. Dieses Skript erstellt einen kurzen<br />
Report über die erfolgreichen und fehlgeschlagenen Testfälle. Für bestimmte Tests,<br />
etwa einen Performance Test, muß das Journal aber weitergehend ausgewertet<br />
werden. Es müssen zum Beispiel bestimmte Werte extrahiert und Berechnungen
34 Kapitel 5 CoreBiz Testsuite - Remote Tests<br />
durchgeführt werden. Das kann in der Regel durch kleine SHELL-Skripte erledigt<br />
werden.<br />
5.4 Testarten<br />
Nachfolgend wird erläutert, wie verschiedene Testarten in dieser Umgebung realisiert<br />
werden können. Die theoretischen Hintergründe dazu sind im Kapitel ”<br />
Softwaretest“<br />
unter Punkt 3.2.1 zu finden.<br />
Remote Tests unterscheiden sich prinzipiell nicht von lokalen Tests. Zu Remote Tests<br />
werden sie allein durch das Benutzen der Direktive ”<br />
:remote:“ (vgl. 4.2.2). Die Tests<br />
selbst enthalten also keinen Quellcode, der darauf hinweist, dass die Tests auf entfernten<br />
Systemen ausgeführt werden können. Alle Testfälle sollten daher auch problemlos lokal<br />
ausgeführt werden können. Selbst das Verwenden von TET-Lite anstatt Distributed<br />
TET sollte möglich sein.<br />
5.4.1 Verifikation von Konfigurationen<br />
Diese Tests haben das Ziel, bestimmte Konfigurationsdateien zu verifizieren. Dabei geht<br />
es speziell um solche Konfigurationsdateien, die von den cfengine-Skripten verändert<br />
werden. Es wurden schon einige Tests dieser Art in der bisherigen Testumgebung unter<br />
Verwendung von TET-Lite erstellt. Der Aufwand für das Portieren der Tests sollte relativ<br />
gering sein, da Distributed TET alle Funktionalitäten von TET-Lite besitzt.<br />
Bei dieser Art von Testfall wird zuerst cfengine mit der Standardumgebung ausgeführt,<br />
um sicherzustellen, dass das System keinen undefinierten Zustand hat. Die entsprechenden<br />
Konfigurationsdateien werden geprüft und cfengine dann mit der Testumgebung<br />
ausgeführt. Wieder werden die Konfigurationsdateien geprüft. Danach wird die Standardumgebung<br />
wiederhergestellt. Wenn nach allen drei Durchläufen von cfengine die<br />
Konfigurationsdateien dem erwartetem Ergebnis entsprechen, gilt der Test als erfolgreich<br />
bestanden (PASS).<br />
Das Überprüfen der Konfigurationsdateien läßt sich mit Hilfe des Werkzeugs ”<br />
diff“ realisieren.<br />
Es muß dazu eine Datei mit dem erwartetem Ergebnis existieren. Diese wird<br />
dann mit der veränderten Konfigurationsdatei verglichen. Gibt es keine Unterschiede,<br />
dann ist der Testschritt bestanden.<br />
Die Verifikation einer Konfigurationsdatei läuft im wesentlichen nach folgendem Schema<br />
ab:<br />
• cfengine mit der Parameterisierung für die Standardumgebung ausführen<br />
• Konfigurationsdatei(en) mit dem erwartetem Ergebnis vergleichen<br />
• cfengine mit der Parameterisierung für die Testumgebung ausführen
5.4 Testarten 35<br />
• Konfigurationsdatei(en) mit dem erwartetem Ergebnis vergleichen<br />
• cfengine mit der Parameterisierung für die Standardumgebung ausführen<br />
• Konfigurationsdatei(en) mit dem erwartetem Ergebnis vergleichen<br />
• Testergebnis: PASS / FAIL<br />
5.4.2 Funktionstests<br />
Die Verifikation von Konfigurationsdateien sind einerseits sehr nützlich, um eine korrekte<br />
Manipulation von Konfigurationsdateien durch cfengine-Skripte sicherzustellen. Andererseits<br />
stoßen diese Tests schnell an ihre Grenzen. So kann es durchaus sein, dass es<br />
mehrere cfengine-Skripte gibt, die dieselbe Konfigurationsdatei verändern. Je nachdem<br />
welche Komponente installiert ist, kann das Ergebnis dann unterschiedlich ausfallen.<br />
Der weitaus größte Nachteil dieser Tests ist jedoch, dass korrekte Konfigurationsdateien<br />
nicht automatisch zu einem korrekt funktionierendem System führen. Um die Funktionalität<br />
bestimmter Dienste oder Programme zu gewährleisten, müssen diese selbst getestet<br />
werden.<br />
Bei den Funktionstests kann generell zwischen zwei Varianten unterschieden werden.<br />
Die einfachere Variante sind Tests, die eine Funktion oder ein Programm aufrufen und<br />
ein bestimmtes, statisches Ergebnis erwarten. Das könnten zum Beispiel Tests sein, die<br />
nach der Installation eines Systems verschiedene Basisfunktionalitäten überprüfen. Auf<br />
einem CoreBiz Base Server könnte beispielsweise getestet werden, ob alle notwendigen<br />
Administrationswerkzeuge auf dem System installiert sind.<br />
Konfigurationsunabhängige Funktionstests laufen nach folgendem Schema ab:<br />
• Funktion/Programm ausführen<br />
• Ergebnis mit erwartetem Ergebnis vergleichen<br />
• Testergebnis: PASS / FAIL<br />
Die zweite Variante geht davon aus, dass sich das Ergebnis eines Funktions- oder Programmaufrufs<br />
verändert, wenn bestimmte Konfigurationsparameter verändert werden.<br />
So ist es möglich, dass das Ergebnis eines Programmaufrufs von verschiedenen korrekt<br />
parameterisierten Konfigurationsdateien abhängt. Durch den Aufruf von cfengine mit einer<br />
entsprechenden Testumgebung kann dieses Ergebnis beeinflusst werden. Der Aufruf<br />
eines Programms kann also vorraussetzen, dass eine ganze Reihe von anderen Programmen<br />
oder Diensten korrekt konfiguriert sein muß. Hier zeigt sich dann der große Vorteil<br />
gegenüber der Verifikation von Konfigurationen. Es müßten unzählige Testfälle erstellt<br />
werden, um sämtliche Konfigurationsdateien zu überprüfen.
36 Kapitel 5 CoreBiz Testsuite - Remote Tests<br />
Der Ablauf von konfigurationsabhängigen Funktionstests ist dem Ablauf der Verifikation<br />
von Konfigurationen sehr ähnlich. Er sieht folgendermaßen aus:<br />
• cfengine mit der Parameterisierung für die Standardumgebung ausführen<br />
• Funktion/Programm ausführen, Ergebnis speichern<br />
• cfengine mit der Parameterisierung für die Testumgebung ausführen<br />
• Funktion/Programm ausführen<br />
• Ergebnis mit erwartetem Ergebnis vergleichen<br />
• cfengine mit der Parameterisierung für die Standardumgebung ausführen<br />
• Funktion/Programm ausführen und mit dem gespeicherten Ergebnis vergleichen<br />
• Testergebnis: PASS / FAIL<br />
5.4.3 Performance Tests<br />
Neben der Verifikation von Konfigurationen und den Funktionstests, die sicherlich am<br />
häufigsten eingesetzt werden, können auch Performance Tests sinnvoll angewendet werden.<br />
Vorstellbar wäre hier der Test von verschiedenen Diensten wie zum Beispiel der<br />
Zugriff auf Dateien via NFS. Es könnten in diesem Zusammenhang aber auch grundlegende<br />
Systemeigenschaften wie die Performance der Festplatte oder des Netzwerks<br />
getestet werden. Um Funktionen oder Programme unter Last zu testen bietet sich die<br />
Direktive ”<br />
:parallel:“ an. Damit lassen sich zwei Tests auf einem System gleichzeitig starten.<br />
Weiterhin ist es in vielen Fällen interessant die Performance eines Programms mit<br />
unterschiedlichen Konfigurationen zu testen. In diesem Fall muß der Test entsprechend<br />
vorbereitet werden und Konfigurationsdateien angepaßt werden. Performance Tests laufen<br />
nach folgendem Schema ab:<br />
• Umgebung vorbereiten (falls nötig)<br />
• Messung starten<br />
• Funktionen oder Programme ausführen<br />
• Messung stoppen<br />
• Umgebung wiederherstellen<br />
• Journal auswerten<br />
Eine Besonderheit von Performance Tests ist die Auswertung des Journals. Testfälle<br />
liefern in der Regel nicht das übliche PASS oder FAIL zurück, sondern verschiedene<br />
Messwerte. Diese müssen dann, zum Beispiel mit SHELL-Skripten, aus den Journalen<br />
extrahiert und mit Referenzwerten verglichen werden.
5.5 Ein prototypischer Testfall 37<br />
5.5 Ein prototypischer Testfall<br />
Dieser prototypisch implementierte Testfall soll die Möglichkeiten des Test Environment<br />
Toolkit zeigen. Er wurde mit Hilfe der SHELL-API von TET erstellt.<br />
5.5.1 Ziel<br />
Bei diesem Testfall soll überprüft werden, ob der Hostname eines CoreBiz Systems korrekt<br />
durch die cfengine-Skripte verändert wird. Dieser wird bei einem CoreBiz System in<br />
einer CoreBiz-eigenen Konfigurationsdatei durch den Parameter ”<br />
hostName“ definiert.<br />
Der Hostname soll mit Hilfe des Programms ”<br />
hostname“ überprüft werden. Es handelt<br />
sich also um einen konfigurationsabhängigen Funktionstest.<br />
5.5.2 Implementierung<br />
Um einen definierten Zustand des Systems zu erhalten wird zu allererst ein Aufruf von<br />
cfengine mit der Standardkonfiguration durchgeführt. Dann wird der aktuelle Hostname<br />
des Systems abgespeichert und cfengine mit einer Testkonfiguration aufgerufen. Diese<br />
Konfiguration ist bis auf den Parameter ”<br />
hostName“ identisch mit der Standardkonfiguration.<br />
Es wird nun erwartet, dass nach dem Durchlauf von cfengine der Befehl ”<br />
hostname“<br />
den entsprechenden Wert der Testkonfiguration zurückliefert. Danach wird wieder<br />
die Standardkonfiguration aktiviert und der Hostname des Systems mit dem am Anfang<br />
des Tests abgespeicherten Wert verglichen. Abbildung 5.2 zeigt ein Flussdiagramm, dass<br />
den Ablauf veranschaulicht.<br />
Bei der Implementierung des Tests zeigte sich, dass es einige Funktionen gibt, die wahrscheinlich<br />
in gleicher oder ähnlicher Form in anderen Testfällen ebenfalls benötigt werden.<br />
Dazu gehört zum Beispiel das Aufrufen von cfenigne mit der Testkonfiguration<br />
beziehungsweise der Standardkonfiguration. Daher wurde begonnen eine Bibliothek für<br />
diese wiederverwendbaren Funktionen zu erstellen. Allerdings muß auch beachtet werden,<br />
dass solche Bibliotheken problematisch werden können. Kaner, Bach und Pettichord<br />
schreiben dazu, dass Bibliotheken für das Testen besonders gut durchdacht sein müssen<br />
und Quellcode im Zweifelsfall besser in den einzelnen Testfällen wiederholt werden sollte.<br />
Sonst kann es passieren, dass unterschiedlichste Funktionen in einer Bibliothek zusammengefaßt<br />
werden. Es gestaltet sich dann schwer den Quellcode von Tests, die Funktionen<br />
aus dieser Bibliothek benutzen, zu lesen oder Fehler darin zu suchen (vgl. [Kan02,<br />
Seite 113f]).
38 Kapitel 5 CoreBiz Testsuite - Remote Tests<br />
<br />
cfengine mit<br />
Standardkonfiguration<br />
aufrufen<br />
cfengine mit<br />
Testkonfiguration<br />
aufrufen<br />
cfengine mit<br />
Standardkonfiguration<br />
aufrufen<br />
Hostname<br />
überprüfen<br />
Hostname<br />
überprüfen<br />
Hostname<br />
überprüfen<br />
<br />
Abbildung 5.2: Flussdiagramm Hostname-Test<br />
5.6 Problematiken bei Remote Tests<br />
Das Ausführen eines Tests auf einem oder mehreren entfernten Systemen bringt neben<br />
allen Vorteilen auch einige Schwierigkeiten mit sich. Dazu gehören:<br />
• Ein funktionstüchtiges Netzwerk ist für die Kommunikation der Test Case Controller<br />
Daemons unbedingt notwendig. Daher können Testfälle, welche die Konfiguration<br />
des Netzwerks betreffen, nicht ausgeführt werden. Eine zweite Netzwerkkarte<br />
in den Testsystemen kann hier teilweise Abhilfe schaffen.<br />
• TET selbst bietet keine Unterstützung für das Kopieren von Tests auf die Testsysteme.<br />
Daher muß die Entwicklung von Tests auf den Testsystemen selbst durchgeführt<br />
werden. Soll in dieser Phase der Test auf einem weiteren System ausgeführt<br />
werden, muß er manuell auf dieses System kopiert werden.<br />
• In einer Testumgebung mit VMware muß darauf geachtet werden, dass beim Duplizieren<br />
von Systemen die MAC-Adresse der Netzwerkkarte verändert wird, da es<br />
ansonsten einen Konflikt geben würde.
5.7 Zusammenfassung 39<br />
5.7 Zusammenfassung<br />
Dieses Kapitel zeigte wie eine Testumgebung aufgebaut werden kann, um verschiedene<br />
Testarten auf beliebig vielen entfernten Systemen auszuführen. Es wurde erläutert<br />
wie die Vorteile einer Virtualisierungssoftware wie VMware genutzt werden können und<br />
warum schließlich Distributed TET als Basis für das Testframework gewählt wurde.<br />
Weiterhin wurde auf verschiedene Testarten eingegangen, die sich in dieser Umgebung<br />
sinnvoll implementieren lassen. Um die Thematik zu veranschaulichen wurde exemplarisch<br />
ein Funktionstest implementiert. Das Potenzial des Test Environment Toolkits<br />
wird aber erst voll ausgespielt werden können, wenn eine größere Anzahl von Testfällen<br />
implementiert ist.
40 Kapitel 5 CoreBiz Testsuite - Remote Tests
Kapitel 6<br />
Corebiz Testsuite - Verteilte Tests<br />
In diesem Kapitel wird auf die Besonderheiten der verteilten Tests und deren Umsetzung<br />
mit Hilfe des Test Environment Toolkits eingegangen. Darauf aufbauend werden einige<br />
prototypische Implementierungen von Teställen vorgestellt, die verschiedene Aspekte<br />
eines LDAP-Servers testen. Zu beachten ist, dass auf grundsätzliche Sachverhalte, die<br />
im vorherigen Kapitel detailliert behandelt wurden, nicht nocheinmal eingegangen wird.<br />
Dieses Kapitel beschränkt sich darauf, die Unterschiede der beiden Testsuites hervorzuheben.<br />
6.1 Aufbau der Testumgebung<br />
Bei verteilten Tests müssen alle beteiligten Testsysteme mit einem Netzwerk verbunden<br />
sein. Da dies schon eine Voraussetzung bei der Testumgebung für Remote Tests war,<br />
sollte prinzipiell das Verwenden der gleichen Testumgebung möglich sein. Es spricht<br />
nichts dagegen, sowohl Remote als auch verteilte Tests in der gleichen Umgebung auszuführen.<br />
Je nach Art des Tests muß aber beachtet werden, dass das Netzwerk nicht ausschließlich<br />
für die Kommunikation zwischen den Testsystemen genutzt wird, sondern mindestens<br />
auch für die Kommunikation zwischen den Testsystemen und dem CoreBiz Factory Server.<br />
Deshalb kann es zum Beispiel bei einem Performance-Test Sinn machen, die Testsysteme<br />
mit einer zweiten Netzwerkkarte auszustatten, damit die Testsyteme ein eigenes<br />
dediziertes Netzwerk benutzen können. Weiterhin ist so sichergestellt, dass verschiedene<br />
Dienste, wie zum Beispiel DHCP, die unter Umständen auf dem CoreBiz Factory Server<br />
aktiviert sind, keinen ungewollten Einfluss auf die Testsysteme nehmen können.<br />
Abbildung 6.1 zeigt den Aufbau einer solchen Testumgebung mit einem CoreBiz Base<br />
Server und einem CoreBiz Client innerhalb einer VMware-Umgebung. Ein Netzwerkinterface<br />
wird dabei für die Kommunikation mit dem CoreBiz Factory Server verwendet,<br />
das andere für die Kommunikation der Testsysteme untereinander. Die folgenden Tests<br />
wurden genau in solch einer Testumgebung durchgeführt. Ein zweites, unabhängiges<br />
Netzwerk ist aber nicht zwingend notwendig.<br />
41
42 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
CoreBiz Factory<br />
Test Case<br />
Control Daemon<br />
VMware<br />
Test Case<br />
Control Daemon<br />
Test Case<br />
Control Daemon<br />
Virtuelles<br />
Netzwerk<br />
CoreBiz Base<br />
CoreBiz Client<br />
Abbildung 6.1: Aufbau der CoreBiz Testumgebung für verteilte Tests<br />
6.2 Das Test Environment Toolkit und verteilte Tests<br />
Verteilte Tests sind im Test Environment Toolkit daran zu erkennen, dass die Tests in<br />
der Szenario-Datei unter der Direktive ”<br />
:distributed:“ aufgeführt sind (vgl. 4.2.2). Bei<br />
den Tests selbst ist zu beachten, dass die Funktionen für die Synchronisierung beziehungsweise<br />
für das Austauschen von Nachrichten nur in der C- und C++-API von TET<br />
integriert sind. Im Gegensatz zu den Remote Tests ist es also nicht möglich, Tests mit<br />
Hilfe der SHELL- oder Perl-API zu erstellen.<br />
6.2.1 Einbinden von weiteren Programmiersprachen<br />
Oftmals liegen relativ einfache Testfälle vor, die mit deutlich weniger Aufwand in einer<br />
Skriptsprache zu realisieren sind. Daher wurden Möglichkeiten gesucht, wie verteilte<br />
Tests auch in diesen Sprachen entwickelt werden können. Der erste Ansatz war, einen<br />
Wrapper zu erstellen, der aus einer Konfigurationsdatei ein C-Programm generiert, das<br />
die auszuführenden Skripte in der richtigen Reihenfolge aufruft und zu den entsprechenden<br />
Zeitpunkten synchronisiert. Es wurde aber schnell klar, dass dieser Ansatz zu<br />
komplex und zu unflexibel werden würde. Es ist in den meisten Fällen einfacher, selbst<br />
ein C-Programm zu schreiben und daraus andere Skripte aufzurufen. Das C-Programm
6.2 Das Test Environment Toolkit und verteilte Tests 43<br />
wird dann hauptsächlich für die Synchronisation der Tests benutzt, während die Skripte<br />
die anderen Aufgaben erledigen.<br />
Ein Ansatz, der für die jeweilige Skriptsprache Funktionen für die Synchronisation implementiert,<br />
wäre natürlich wünschenswert. Diese müßten dann zum Beispiel auf die<br />
entsprechenden C-Funktionen zurückgreifen oder vollständig neu implementiert werden.<br />
Es bleibt allerdings fraglich, ob dieser Aufwand gerechtfertigt ist. Falls sich verteilte<br />
Tests in Zukunft bewähren sollten und eine größere Anzahl von Testfällen implementiert<br />
werden muß, sollte diese Option noch einmal geprüft werden.<br />
6.2.2 Synchronisation<br />
Eine Synchronisation zwischen zwei oder mehreren Testsystemen wird mit Hilfe von<br />
TET durch den Aufruf der Funktion ”<br />
tet remsync()“ erreicht. Diese Funktion kann auf<br />
drei verschiedenen Varianten benutzt werden:<br />
• Einfache Synchronisation<br />
• Synchronisation + Nachricht senden<br />
• Synchronisation + Nachricht empfangen<br />
Das nachfolgende Listing zeigt eine Funktion zum Synchronisieren und Senden einer<br />
Nachricht. Diese wird so oder in ähnlicher Form in den LDAP-Tests benutzt.<br />
int snd_msg(char *str) {<br />
int sys[] = { 2 }; /* system IDs to sync with */<br />
struct tet_synmsg msg;<br />
msg.tsm_flags = TET_SMSNDMSG;<br />
msg.tsm_dlen = strlen(str)+1;<br />
msg.tsm_data = str;<br />
}<br />
if (tet_remsync(sync_nr, sys, 1,<br />
TIMEOUT, TET_SV_YES, &msg) != 0) {<br />
tet_printf("sync %d failed", sync_nr++);<br />
return 1;<br />
}<br />
else {<br />
tet_printf("sync %d OK", sync_nr++);<br />
return 0;<br />
}
44 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
6.2.3 Installation von verteilten Tests<br />
Damit verteilte Tests problemlos auf einem CoreBiz-System installiert werden können,<br />
müssen alle notwendigen Dateien in einem Debian-Paket bereitgestellt werden. Das Problem<br />
im Zusammenhang mit TET ist dabei, dass der Name eines Tests und das Verzeichnis<br />
in dem er liegt auf allen Testsystemen gleich sein muß. Ein Debian-Paket kann<br />
aber verständlicher Weise nur eine Datei mit dem selben Namen in das gleich Verzeichnis<br />
installieren.<br />
Ein Ansatz wäre nun, zwei Debianpakete zu erstellen: Eines mit den Tests für das erste<br />
Testsystem und eines mit dem Test für das zweite Testsystem. Es wäre allerdings viel<br />
sinnvoller alle Tests in einem einzigen Paket unterzubringen. Es müßte dann nur ein<br />
einziges Debian-Paket gepflegt werden und es kann nicht passieren, dass die falsche<br />
Version auf einem Testsystem installiert wird. Weiterhin könnte es in Zukunft auch<br />
Tests mit mehr als zwei Testsystemen geben. Für jedes weitere System müßte dann<br />
entsprechend ein weiteres Debian-Paket erstellt werden.<br />
Eine flexiblere Lösung bietet die Option ”<br />
TET REMXXX TET TSROOT“ der TET-<br />
Konfigurationsdatei ”<br />
tetdist.cfg“. Damit kann das Verzeichnis festgelegt werden, in der<br />
die Tests liegen. XXX steht dabei für die System ID. Es wurden vorerst zwei Verzeichnisse<br />
definiert: ”<br />
base“ und ”<br />
client“, entsprechend der System IDs des CoreBiz Base Servers<br />
beziehungsweise des CoreBiz Clients. Falls in Zukunft Verzeichnisse für weitere Systeme<br />
benötigt werden, sollten sie sich an den festgelegten System IDs orientieren. Für die<br />
implementierten Tests wurde folgende ”<br />
tetdist.cfg“ benutzt:<br />
TET_ROOT=/opt/tet-full<br />
TET_REM001_TET_TSROOT=/opt/tests/distributed_tests/base<br />
TET_REM002_TET_TSROOT=/opt/tests/distributed_tests/client<br />
Zusammengefaßt heißt das, dass in einem Debian-Paket immer vollständige Tests enthalten<br />
sind. Die Entscheidung, welcher Teil eines Tests auf einem bestimmten System<br />
ausgeführt wird, trifft der Test Case Controller anhand der Konfigurationsdatei tetdist.cfg“.<br />
Diese muß für alle am Test beteiligten Systemen den Parameter ”<br />
TET REMXXX TET TSROOT“ definieren. Neben der Direktive ist dies der einzigste<br />
”<br />
Konfigurationsparameter, der eine Testumgebung für verteilte Tests von einer Testumgebung<br />
für Remote Tests unterscheidet.<br />
6.3 Drei prototypische Testfälle<br />
Im Folgenden werden drei prototypische Implementierungen von Testfällen beschrieben.<br />
Diese Tests beziehen sich auf den LDAP-Server, dessen Verhalten auf unterschiedliche<br />
Weise getestet wird. Alle Tests sind in der Programmiersprache C implementiert und es<br />
werden die entsprechenden APIs von TET und OpenLDAP verwendet.
6.3 Drei prototypische Testfälle 45<br />
Synchrone und asynchrone LDAP-Funktionen<br />
Das Lightweight Directory Access Protocol ist ein asynchrones Protokoll. Das heißt, dass<br />
mehrere LDAP-Anfragen gleichzeitig an den Server geschickt werden können und es dem<br />
Server überlassen ist, in welcher Reihenfolge er die Anfragen abarbeitet.<br />
Aus diesem Grund gibt es die meisten LDAP-Funktionen in einer synchronen und einer<br />
asynchronen Variante. Während synchrone LDAP-Funktionen auf die Antwort des<br />
LDAP-Servers warten und in dieser Zeit das Programm blockieren, können mit asynchronen<br />
LDAP-Funktionen in dieser Wartezeit andere Aufgaben erledigt werden oder<br />
auch weitere LDAP-Funktionen aufgerufen werden.<br />
Timing-Probleme mit VMware<br />
Nach ersten Versuchen wurde deutlich, dass das Verwenden von VMware problematisch<br />
im Hinblick auf eine exakte Zeitmessung sein kann. Die interne Uhr von Systemen<br />
innerhalb einer VMware-Instanz laufen meistens nicht synchron zu den Uhren realer<br />
Systeme. Daher wird die Zeit dieser Systeme in bestimmten Abständen durch VMware<br />
synchronisiert.<br />
Für die Zeitmessung bedeutet das, dass es ab und zu größere Zeitsprünge geben kann,<br />
nämlich genau dann, wenn die Uhr durch VMware synchronisiert wird. Außerdem ist<br />
die absolute Zeit ebenfalls sehr ungenau, da wie schon erwähnt, die Uhr zu schnell oder<br />
zu langsam laufen kann. Bei den Tests kommt es aber hauptsächlich auf die Zeitdifferenz<br />
an. Es sollten daher die eigentlich relevanten Messungen und Auswertungen nicht<br />
beeinträchtigt werden.<br />
6.3.1 LDAP Konflikttest<br />
Ziel<br />
Es soll getestet werden, was passiert, wenn zwei Systeme gleichzeitig versuchen einen<br />
identischen LDAP Eintrag zu ändern, neu anzulegen oder zu löschen. Interessant wird<br />
dieser Test in Kombination mit einem Lasttest. Der Testfall wird also über einen längeren<br />
Zeitraum ständig wiederholt.<br />
Implementierung<br />
Sowohl Server als auch Client versuchen gleichzeitig einen LDAP-Eintrag anzulegen,<br />
zu ändern und wieder zu löschen. Nach jeder Operation wird dem anderen System eine<br />
Nachricht mit dem Ergebnis geschickt. Für die Operationen Eintrag anlegen“ und<br />
”<br />
Eintrag löschen“ wird erwartet, dass die Operation bei einem Testsystem erfolgreich<br />
”<br />
ausgeführt wird und entsprechend beim anderen Testsystem eine Fehlermeldung erzeugt.<br />
Bei der Operation Eintrag modifizieren“ wird erwartet, dass beide Testsysteme die<br />
”
46 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
Funktion fehlerfrei ausführen können. Hier ist dann besonders interessant, welcher Eintrag<br />
nach dem Test in der Datenbank steht. Abbildung 6.2 beschreibt den Ablauf des<br />
LDAP Konflikttests.<br />
Server<br />
LDAP<br />
Client<br />
Sync<br />
Sync<br />
ldap operation<br />
ldap operation<br />
ok/fail<br />
ok/fail<br />
send result<br />
send result<br />
Abbildung 6.2: Sequenzdiagramm LDAP Konflikttest<br />
Es werden sowohl die synchronen als auch asynchronen Varianten der LDAP-Funktionen<br />
benutzt. Daher gibt es zwei Test Purposes (vgl. 4.2.2). Test Purpose 1 führt die synchronen,<br />
Test Purpose 2 die asynchronen LDAP-Funktionen aus. Der Testfall wird mit<br />
der Standardkonfiguration des LDAP-Servers ausgeführt und insgesamt 8 Stunden lang<br />
wiederholt.<br />
Analyse der Ergebnisse<br />
Die Ergebnisse bestätigen die Vermutungen, die beim Erstellen des Testfalls gemacht<br />
wurden: Der LDAP-Server kam mit allen Funktionsaufrufen zurecht, es traten nur die<br />
erwarteten Fehler auf. Jeder erfolgreiche Versuch eines Testsystems einen neuen Eintrag<br />
im LDAP anzulegen oder zu löschen, erzeugte einen Fehlversuch auf dem jeweils anderen<br />
Testsystem. In den 8 Stunden wurde der Testfall insgesamt 54130 mal wiederholt. Tabelle<br />
6.1 zeigt die Anzahl der erfolgreich ausgeführten Funktionen bei den Operationen
6.3 Drei prototypische Testfälle 47<br />
” add“ und delete“ und die Anzahl der zuerst ausgeführten Anfragen bei der Operation<br />
”<br />
” modify“.<br />
Es zeigt sich, dass der CoreBiz Base Server deutlich öfter erfolgreich“ war, als der<br />
”<br />
CoreBiz Client. Das läßt sich dadurch erklären, dass der OpenLDAP-Server auf dem<br />
CoreBiz Base Server läuft und damit die Anfrage nicht wie beim Client zuerst über das<br />
Netzwerk geschickt werden muß. Zwischen den synchronen und asynchronen Funktionen<br />
gibt es in diesem Testfall keine wesentlichen Unterschiede. Interessant ist aber, dass<br />
nicht 100% der Anfragen des Servers erfolgreich waren und der Client bei einem nicht<br />
unerheblichen Teil trotz der Netzwerkverzögerung schneller war.<br />
synchron<br />
asynchron<br />
add modify delete add modify delete<br />
Server 22798 22222 19355 24149 22118 18670<br />
Client 4267 4843 7710 2916 4947 8395<br />
Tabelle 6.1: Ergebnis des LDAP Konflikttests<br />
Eine interessante Erweiterung dieses Testfalls wäre das Hinzufügen von weiteren Testsystemen.<br />
Beispielsweise könnten zehn Clients gleichzeitig versuchen Änderungen am<br />
LDAP-Server vorzunehmen. Da alle Clients nahezu die gleiche Verzögerung durch das<br />
Netzwerk haben, wäre es interessant zu wissen, wie die erfolgreichen Anfragen verteilt<br />
sind. Weiterhin könnte getestet werden, wieviel gleichzeitige Anfragen der LDAP-Server<br />
überhaupt verkraftet oder ob nur die Bandbreite des Netzwerks eine Grenze darstellt.<br />
6.3.2 LDAP Performance Test<br />
Ziel<br />
Es soll gemessen werden, wie sich die Performance des LDAP Servers bei stetig größer<br />
werdender Datenbank verhält. Dabei gilt es zu klären, von welchen Parametern die<br />
Performance maßgeblich abhängt.<br />
Der Test ermöglicht es, den Leistungsbedarf eines LDAP Servers zu ermitteln. Das ist<br />
zum Beispiel nötig, um Kunden eine realistische Einschätzung geben zu können, ob ihr<br />
bisheriger Server mit 20000 Benutzern umgehen kann, oder ob neue, leistungsstärkere<br />
Hardware angeschafft werden muß.<br />
Weiterhin lassen sich so auch Änderungen der Performance des LDAP-Servers selbst<br />
feststellen. Beispielsweise können folgende Systemparameter die Performance beeinflussen:<br />
• Neue oder andere Version des OpenLDAP Servers<br />
• Verwenden eines anderen Datenbank-Backends für den LDAP-Server
48 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
• Veränderung bestimmter Konfigurationsparameter des LDAP-Servers<br />
Implementierung<br />
Der Test läuft wieder in der üblichen Testumgebung ab, einem CoreBiz Base Server und<br />
einem CoreBiz Client. Auf dem CoreBiz Base Server werden nach und nach immer mehr<br />
LDAP-Einträge hinzugefügt. Der CoreBiz Client misst dann die Laufzeit bestimmter<br />
LDAP-Operationen. Abbildung 6.3 zeigt ein Sequenzdiagramm, das den Ablauf des Tests<br />
beschreibt.<br />
Server<br />
LDAP<br />
Client<br />
ldap_add<br />
Sync 1<br />
Sync 1<br />
Sync 2<br />
ldap operation<br />
ldap operation ok<br />
delay<br />
Sync 2<br />
loop<br />
loop<br />
Abbildung 6.3: Sequenzdiagramm LDAP Performance Test<br />
Der Testfall besteht aus zwei Test Purposes. Der erste Test Purpose benutzt die synchronen<br />
LDAP Funktionen, um die Laufzeit folgender Operationen zu messen:<br />
• ldap search auf alle Einträge im LDAP<br />
• ldap add von 100 Einträgen<br />
• ldap modify von 100 Einträgen<br />
• ldap search mit Filter, der 100 Einträge zurückliefert<br />
• ldap delete von 100 Einträgen
6.3 Drei prototypische Testfälle 49<br />
Der zweite Test Purpose führt die gleichen Operationen mit Hilfe der asynchronen Varianten<br />
durch. Es werden jeweils 100 Einträge hinzugefügt, modifiziert oder gelöscht,<br />
um eine sinnvolle Zeitspanne messen zu können. Zusätzlich wird jede Operation 10 mal<br />
ausgeführt, um Abweichungen durch verschiedene Einflüsse erkennen zu können.<br />
Analyse der Ergebnisse<br />
Anzahl Einträge im LDAP<br />
LDAP Operation 1000 3000 7000 15000 30000<br />
add 1738 2110 2245 2158 2448<br />
modify 446 504 507 529 484<br />
delete 1988 2510 2899 3969 4743<br />
search1 1901 11314 30887 88226 254950<br />
search2 300 336 306 407 362<br />
Tabelle 6.2: Ergebnisse des LDAP Performance Tests (synchron)<br />
Anzahl Einträge im LDAP<br />
LDAP Operation 1000 3000 7000 15000 30000<br />
add 1395 2610 186 763 168<br />
modify 397 302 155 128 149<br />
delete 5442 2385 3635 6054 8655<br />
search1 9034 25243 50367 99711 343316<br />
search2 423 15 15 14 21<br />
Tabelle 6.3: Ergebnisse des LDAP Performance Tests (asynchron)<br />
Die Tabelle 6.2 und das dazugehörige Diagramm 6.4 zeigen die Ergebnisse der synchronen<br />
LDAP-Operationen (Test Purpose 1). Die Tabelle 6.3 und das dazugehörige Diagramm<br />
6.5 zeigen dagegen die Ergebnisse der asynchronen LDAP-Operationen (Test Purpose<br />
1).<br />
Zu jeder LDAP-Operation werden pro Vergrößerung der LDAP-Datenbank 10 Werte<br />
gemessen. Die zwei größten beziehungsweise zwei kleinsten Werte werden nicht weiter<br />
ausgewertet. Von den übrigen 6 Werten wird jeweils der Durchschnitt gebildet. Die in<br />
den Tabellen 6.2 und 6.3 unter ”<br />
search1“ aufgelisteten Werte stellen die Suche auf alle<br />
Einträge im LDAP dar, während die unter ”<br />
search2“ aufgelisteten Werte die Suche mit<br />
der Rückgabe von 100 Einträgen darstellt. Zu beachten ist die logarithmische Darstellung<br />
der Y-Achse in den Diagrammen.<br />
Während die Operationen ”<br />
add“ und ”<br />
delete“ mit größer werdender Datenbank etwas<br />
mehr Zeit benötigen, bleiben die Werte der Operationen ”<br />
modify“ und ”<br />
search2 “ praktisch<br />
konstant. Die Operation ”<br />
search2“ benötigt erwartungsgemäß immer mehr Zeit.
50 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
1000000<br />
100000<br />
Millisekunden<br />
10000<br />
1000<br />
add<br />
modify<br />
delete<br />
search1<br />
search2<br />
100<br />
1000 3000 7000 15000 30000<br />
Anzahl Einträge<br />
Abbildung 6.4: Ergebnisse des LDAP Performance Tests (synchron)
6.3 Drei prototypische Testfälle 51<br />
1000000<br />
100000<br />
Millisekunden<br />
10000<br />
1000<br />
100<br />
add<br />
modify<br />
delete<br />
search1<br />
search2<br />
10<br />
1000 3000 7000 15000 30000<br />
Anzahl Einträge<br />
Abbildung 6.5: Ergebnisse des LDAP Performance Tests (asynchron)
52 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
Interessant ist aber, dass sich diese Zeiten mit steigender Anzahl von Datenbankeinträgen<br />
um ein Vielfaches erhöht. Beispielhaft können die Werte von 15000 und 30000<br />
Einträgen betrachtet werden. Während sich die Einträge in der LDAP-Datenbank verdoppelt<br />
haben, hat sich die Zeit für das Auslesen nahezu verdreifacht.<br />
Auffällig bei den asynchronen Funktionsaufrufen ist zu allererst, dass die Zeiten im<br />
Gegensatz zu den synchronen Varianten sehr viel mehr Schwanken können. Abgesehen<br />
von den Timing-Problemen der VMware könnte eine andere Abarbeitungsmethode der<br />
einzelnen Anfragen im OpenLDAP-Server eine Erklärung dafür sein. Bei synchronen<br />
Funktionsaufrufen wird genau eine Anfrage an den Server geschickt und erst nach dem<br />
Erhalt des Ergebnisses die nächste Anfrage an den LDAP-Server gesendet. Bei den<br />
asynchronen Funktionsaufrufen werden dagegen alle Anfragen auf einmal an den Server<br />
übertragen. Dieser kann dann selbst entscheiden wann und in welcher Reihenfolge die<br />
Anfragen abgearbeitet werden.<br />
Einen direkten Vergleich zwischen den synchronen und asynchronen Funktionen machen<br />
diese teilweise heftigen Schwankungen schwer. Obwohl die Zahlen schon Durchschnittswerte<br />
darstellen, müßten viele weitere Testläufe gemacht werden, um wirklich<br />
verwendbare Durchschnittswerte zu erhalten. Auffällig ist aber, dass ”<br />
search1“ in der<br />
asynchronen Variante langsamer ist, während ”<br />
search2“ fast immer deutlich schneller<br />
als die synchrone Variante ist.<br />
An dieser Stelle muß noch einmal erwähnt werden, dass bei diesem Testfall ausschließlich<br />
mit der C-API gearbeitet wird. Es soll also das Verhalten und die Leistung des Servers<br />
selbst getestet werden. Damit können aber keine Aussagen über Programme getroffen<br />
werden, die in irgendeiner Form mit dem LDAP-Server kommunizieren. Beispielsweise<br />
werden bei allen Testfällen jeweils nur zu Beginn beziehungsweise zum Ende des Tests<br />
die Funktionen ldap init, ldap bind und ldap unbind aufgerufen. Während des ganzen<br />
Tests wird also mit der gleichen Verbindung gearbeitet. Bei diversen Programmen liegt<br />
es aber nahe, dass dies jeweils beim Ausführen des Programms geschieht. Um das Verhalten<br />
und die Performance von LDAP-basierter Software korrekt zu Testen, müssen die<br />
Funktionsaufrufe so gut wie möglich nachgebildet werden. Ein anderer Ansatz wäre die<br />
zu testenden Programme direkt aufzurufen.<br />
Probleme mit dem Datenbank-Backend ”<br />
ldbm“<br />
Bei einem Performance Test wie diesem, bei dem sehr große Mengen an Daten geschrieben<br />
und gelesen werden, handelt es sich natürlich auch um eine Art Stresstest. Dieser<br />
Nebeneffekt führte dazu, dass folgender Fehler entdeckt wurde: Wenn als Datenbank-<br />
Backend ”<br />
ldbm“ verwendet wird und in Größenordnungen von mehreren 10000 LDAP-<br />
Einträge gearbeitet wird, dann läßt sich die zuvor angelegte ”<br />
Organizational Unit“, unterhalb<br />
der die LDAP-Einträge angelegt werden, nicht mehr löschen. Der LDAP-Server<br />
anwortet mit der Fehlermeldung:<br />
Delete Result: Operation not allowed on non-leaf (66)<br />
Additional info: subtree delete not supported
6.3 Drei prototypische Testfälle 53<br />
Der Fehler deutet eigentlich darauf hin, dass es noch weitere Einträge unterhalb dieses<br />
Knoten gibt. Es waren aber offensichtlich keine weiteren Einträge vorhanden. Um<br />
eine korrekte LDAP-Datenbank wiederhezustellen, mußte die Datenbank gelöscht und<br />
neu aufgebaut werden. Da in den aktuellen CoreBiz Servern ausschließlich ”<br />
bdb“ als<br />
Backend verwendet wird, wurde der Ursache dieses Fehlers nicht weiter nachgegangen.<br />
Beim Verwenden des Datenbank-Backends ”<br />
bdb“ tritt dieser Fehler nicht auf.<br />
6.3.3 LDAP Latenztest<br />
Ziel<br />
Es soll die Verzögerung gemessen werden, wie lange es dauert, bis ein neuer Eintrag oder<br />
eine Änderung eines vorhandenen LDAP-Eintrags bei einem Client, der diesen Eintrag<br />
ausliest, sichtbar wird. Dabei werden verschiedene Konfigurationsparameter verändert,<br />
von denen erwartet wird, dass sie diese Verzögerung beeinflussen. Auch wenn dieser<br />
Testfall Latenztest genannt wird, um ihn von den anderen Testfällen zu unterscheiden,<br />
handelt es sich um einen Performance Test.<br />
Implementierung<br />
Zuerst synchronisieren sich Server und Client. Nun ändert der Server ein bestimmtes<br />
LDAP-Attribut auf einen Testwert, den er zuvor während der Synchronisation dem<br />
Client mitgeteilt hatte. Der Client versucht dann, dieses geänderte Attribut auszulesen.<br />
Gemessen wird die Zeit ab der Synchronisation bis zum erfolgreichen Auslesen des<br />
geänderten LDAP-Attributs. Abbildung 6.6 beschreibt den Ablauf des LDAP Latenz<br />
Tests. Sowohl Server als auch Client verwenden synchrone LDAP-Funktionen.<br />
Neben der Standard-Konfiguration des LDAP-Servers werden zusätzlich Testläufe durchgeführt,<br />
bei denen folgende Konfigurationsparameter verändert werden:<br />
• ”<br />
dirtyread“ - Lesen von modifizierten Einträgen, auf die aber noch kein commit<br />
folgte<br />
• ”<br />
dbnosync“ - Daten im Speicher werden nicht sofort auf die Festplatte synchronisiert<br />
• Verwenden des Datenbank-Backends ”<br />
ldbm“ anstatt ”<br />
bdb“<br />
Vor jedem Durchlauf wird die LDAP-Datenbank gelöscht und neu initialisiert, damit<br />
exakt die gleichen Ausgangsbedingungen geschaffen werden.
54 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
Server<br />
LDAP<br />
Client<br />
Sync 1 Sync 1<br />
ldap_modify<br />
ldap_search<br />
old value<br />
delay<br />
ldap_search<br />
modified value<br />
Abbildung 6.6: Sequenzdiagramm LDAP Latenztest<br />
Analyse der Ergebnisse<br />
Jeder Testlauf wurde 1000 mal durchgeführt, um einen möglichst guten Durchschnittswert<br />
zu erhalten. Die 100 höchsten und 100 niedrigsten Messwerte werden nicht in die<br />
Auswertung mit einbezogen, da es durch die Problematik mit der VMware teilweise extrem<br />
abweichende Werte geben kann. Es bleiben also noch 800 Messwerte, aus denen<br />
die durchschnittliche Verzögerung berechnet wird. Zusätzlich wurde jede Konfiguration<br />
drei mal wiederholt. Tabelle 6.4 zeigt das Ergebnis.<br />
Die geänderten Konfigurationsparameter haben also Auswirkungen auf die Performance<br />
des LDAP-Servers. Allerdings fällt diese Verbesserung relativ gering aus, so dass es<br />
kaum Sinn machen würde, deswegen das Risiko von inkonsistenzen Daten oder sogar<br />
der Verlust von Daten deutlich zu erhöhen. Es gibt natürlich noch viele weitere Konfigurationsparameter,<br />
die verändert und getestet werden können. Besonders interessant<br />
für weitere Tests sind neue Versionen des OpenLDAP-Servers oder auch des Datenbank-<br />
Backends.<br />
Was aus der Tabelle 6.4 nicht ersichtlich ist, sind die einzeln gemessenen Werte. Diese
6.3 Drei prototypische Testfälle 55<br />
bdb standard<br />
bdb + dirtyread<br />
bdb + dbnosync<br />
bdb + dirtyread<br />
+<br />
dbnosync<br />
DL 1 in ms 7,69 7,02 7,29 6,25 8,99<br />
DL 2 in ms 7,75 7,24 7,35 6,35 8,86<br />
DL 3 in ms 7,38 6,88 5,83 6,25 9,49<br />
Durchschnitt 7,61 7,05 6,82 6,28 9,11<br />
Prozentualer<br />
Unterschied<br />
ldbm standard<br />
0 7,95 11,48 21,06 -16,53<br />
Tabelle 6.4: Ergebnis des LDAP Latenztests<br />
schwanken im Bereich von 2 bis 21 Millisekunden, obwohl die am stärksten abweichenden<br />
Werte nicht mit einberechnet wurden. Erklären läßt sich das mit der Tatsache, dass<br />
LDAP ein asynchrones Protokoll ist und der Server nicht zwingend sofort antworten<br />
muß. Auffällig ist, dass die schnellsten Zeiten unabhängig von der Konfiguration immer<br />
2 Millisekunden betrugen. Die verschiedenen Konfigurationen wirken sich also nur auf<br />
die langsamsten Zeiten und damit auch auf die Durchschnittszeiten aus. Interessant<br />
wäre die Durchführung dieses Testfalls auf realen Systemen, damit der Test nicht von<br />
den Timing Problemen der VMware beeinflusst wird. Diese Probleme führen auch dazu,<br />
dass die Ergebnisse dieses Tests praktisch wertlos für den Vergleich mit zukünftigen Tests<br />
sind. Nur die prozentualen Unterschiede lassen sich unter Umständen weiter nutzen.<br />
Bei diesem Testfall wurde wenig Zeit für die Automatisierung aufgewendet. Das machte<br />
sich dadurch bemerkbar, dass das Vorbereiten der Testumgebung und insbesondere<br />
die Auswertung der Tests noch manuell gemacht werden muß. Das Vorbeiten der Testumgebung,<br />
also vor allem das Initialisieren des LDAP-Servers kann relativ einfach<br />
durch ein Skript automatisiert werden. Allerdings stellt sich hier die Frage, wie sinnvoll<br />
eine Automatisierung wäre. Das interessante an diesem Test sind die Auswirkungen<br />
der veränderten Konfigurationsparameter. Wenn neue Parameter getestet werden sollen,<br />
müssen diese ohnehin manuell eingestellt werden. Bei einer Automatisierung würde das<br />
bedeuten, dass jedes mal der Testfall angepasst werden müßte. Dagegen wäre das automatisierte<br />
Auswerten der Testergebnisse, also das Extrahieren der relevanten Messdaten,<br />
durchaus sinnvoll. Problematisch ist hier hauptsächlich die Tatsache, dass dies außerhalb<br />
des Testframeworks gemacht werden muß, da das Journal des Testfalls die Messwerte<br />
enthält. Bei diesem Test wurde das mit Hilfe einiger SHELL-Befehlen manuell realisiert.<br />
Die Zahlen wurden dann in eine Tabellenkalkulation eingefügt und entsprechend<br />
aufbereitet.
56 Kapitel 6 Corebiz Testsuite - Verteilte Tests<br />
6.4 Problematiken bei verteilten Tests<br />
Die Probleme, die eine Virtualisierungssoftware mit sich bringt, wurden schon in den<br />
vorherigen Abschnitten erwähnt. Speziell Performance Tests, bei denen man bestimmte<br />
Zeiten messen will, sollten daher auf realen Systemen durchgeführt werden.<br />
Allgemein ist das Erstellen von verteilten Tests deutlich aufwändiger, als von Remote<br />
beziehungsweise lokalen Tests. Das liegt allein schon an der Tatsache, dass die Tests<br />
auf den einzelnen Systemen unterschiedlich aufgebaut sind. Die Entwicklung eines Tests<br />
verkompliziert sich in Folge dessen. Die Problematik dabei ist, dass ein verteilter Test nur<br />
ausgeführt werden kann, wenn auf allen beteiligten Testsystemen, der Test vorhanden<br />
ist. Für die Entwicklung bedeutet das, dass zuerst alle Komponenten eines Tests erstellt<br />
werden müssen, bevor der Test selbst getestet werden kann. Die Fehlersuche gestaltet<br />
sich dann ähnlich schwierig, da es oftmals nicht offensichtlich ist, auf welchem Testsystem<br />
der Fehler verursacht wurde.<br />
Darin liegt auch der größte Nachteil von verteilten Tests gegenüber Remote Tests. Deshalb<br />
sollte vor der Entwicklung eines Testfalls immer geprüft werden, ob mit einem<br />
Remote Test nicht das gleiche Ergebnis erzielt werden kann. Wenn doch ein verteilter<br />
Test entwickelt werden muß, sollte der Testfall gut durchdacht und geplant sein. Das<br />
Design ist hier deutlich wichtiger als bei Remote Tests.<br />
Ein weiteres Problem ist das Senden von Daten an ein anderes Testsystem. Hier ist<br />
TET auf einfache Zeichenketten beschränkt. Es gibt keine Marshalling-Funktionalität,<br />
um auch komplexere Datentypen zu übertragen. In bestimmten Testfällen wäre es aber<br />
wünschenswert, beispielsweise einen Array an das andere Testsystem zu übertragen.<br />
Lösen könnte man dieses Problem, indem man Funktionen implementiert, die diese Datentypen<br />
auf der Senderseite in eine Zeichenkette umwandeln und auf der Empfängerseite<br />
diese wieder in den entsprechenden Datentyp umwandeln.<br />
6.5 Zusammenfassung<br />
Dieses Kapitel erklärte den Aufbau, die Möglichkeiten, aber auch die Schwierigkeiten einer<br />
Testumgebung in der verteilte Tests ausgeführt werden können. Interessant dabei ist,<br />
dass sich die Umgebung nur minimal von der Testumgebung für Remote Tests unterscheidet.<br />
Die prototypisch implementierten Testfälle demonstrieren, wie sich verteilte Tests<br />
einsetzen lassen können. Die Vorteile liegen speziell in einer Client-Server-Umgebung auf<br />
der Hand: Es können zeitlich exakt abgestimmte Interaktionen zwischen diesen Systemen<br />
getestet werden. Allerdings ist der Aufwand für das Erstellen solcher Tests deutlich<br />
höher im Vergleich zu Remote Tests.
Kapitel 7<br />
Conclusio<br />
Im letzten Kapitel dieser Arbeit wird noch einmal ein Fazit gezogen und ein Ausblick<br />
für die Zukunft gegeben.<br />
7.1 Fazit<br />
Das Testen von Software ist ein äußerst interessantes, aber auch sehr komplexes Themengebiet.<br />
Leider wird es oftmals von vielen Softwareentwicklern, aber auch Projektleitern<br />
und dem Management nur stiefmütterlich behandelt. Das kann sich in verschiedener<br />
Hinsicht in einem Softwareprojekt auswirken. Das Management stellt ein zu geringes<br />
Budget für das Testen bereit, der Projektleiter plant zu wenig Zeit dafür ein und die<br />
Entwickler haben kaum Wissen und Erfahrung in diesem Themengebiet.<br />
Dieser Umgang mit dem Thema Software führt dazu, dass die Qualität der Software<br />
leidet. Um dem entgegen zu wirken, muß zuerst ein geeigneter Rahmen geschaffen werden.<br />
Dazu gehört, dass von Anfang an genügend Mittel und Zeit für den Test in einem<br />
Softwareprojekt eingeplant werden. Es werden geschulte Mitarbeiter benötigt, die zumindest<br />
über ein Basiswissen im Themengebiet Softwaretest verfügen. Weiterhin ist es<br />
notwendig, dass es standardisierte Verfahren gibt, wie Software zu testen ist. Dazu muß<br />
auch ein einheitliches Test-Framework vorhanden sein.<br />
Die Erarbeitung eines Konzepts für ein solches Test-Framework war die Zielsetzung dieser<br />
Arbeit. Besondere Bedeutung hatten dabei einerseits die Regressionstests und die<br />
damit verbundene Automatisierung von Tests, und andererseits die verteilten Tests.<br />
Um diese Anforderungen zu realisieren, wurde eine Testumgebung mit Hilfe des Test<br />
Environment Toolkits entwickelt. Es wurden so die Voraussetzungen geschaffen, Tests<br />
auf entfernten Systemen und verteilte Tests durchzuführen. Einige prototypische Implementierungen<br />
von Testfällen veranschaulichten die Funktionsweise des Test-Frameworks,<br />
zeigten aber auch die Schwierigkeiten und Problematiken auf.<br />
57
58 Kapitel 7 Conclusio<br />
Das Test Environment Toolkit zeigte sich dabei als ein sehr ausgereiftes und gut durchdachtes<br />
Test-Framework. So enstehen Probleme meist dann, wenn außerhalb dieses Frameworks<br />
Aktionen durchgeführt werden müssen. Als Beispiel können hier die Performance<br />
Tests dienen, bei denen in der Regel verschiedene Messwerte aus einem Journal<br />
extrahiert werden müssen. Diese Aufgabe selbst ist zwar einfach zu realisieren, aber<br />
da sie außerhalb des TET-Frameworks abläuft, verkompliziert sich der Testfall dadurch<br />
deutlich.<br />
Besonders interessante Testfälle in einer Client-Server-Umgebung können durch verteilte<br />
Tests realisiert werden. Das Test-Framework ermöglicht dies dadurch, dass Funktionen<br />
bereitgestellt werden, die eine Synchronisation sowie das Senden und Empfangen von<br />
Nachrichten zwischen mehreren Testsystemen erlauben. Im Hinblick auf CoreBiz Systeme,<br />
die sehr stark von der Client-Server-Kommunikation abhängen, wurden diesen Tests<br />
besondere Aufmerksamkeit geschenkt. Die implementierten Testfälle zeigten verschiedene<br />
Szenarien, wie solche Tests eingesetzt werden können. Allerdings wurde daraus auch<br />
ersichtlich, dass der Aufwand für die Implementierung von verteilten Tests im Vergleich<br />
zu Remote Tests deutlich höher ist.<br />
Zusammenfassend kann gesagt werden, dass für die meisten Testfälle, Remote Tests<br />
ausreichend sind und mit weitaus geringerem Aufwand zu realisieren sind. Hier kommen<br />
hauptsächlich die Verifikation von Konfigurationen und Funktionstests in Frage. Verteilte<br />
Tests sollten dagegen für besondere Tesfälle eingesetzt werden, für die zeitlich exakt<br />
abgestimmte Interaktionen zwischen Server und Client notwendig sind. Beispiele wären<br />
Funktionstests die bestimmte Konfliktsituationen testen, aber auch Performance, Lastund<br />
Stresstests.<br />
Das ganze Potenzial dieses Test-Frameworks, mit dem sowohl Remote als auch verteilte<br />
Tests realisiert werden können, wird sich aber erst in Zukunft zeigen, wenn eine größere<br />
Anzahl von Testfällen implementiert ist.<br />
7.2 Ausblick<br />
Mit dieser Arbeit ist nun ein Rahmen für das Erstellen von Testfällen gegeben. Es stellt<br />
sich nun abschließend die Frage, wie dieses Projekt in Zukunft weitergeführt werden<br />
kann.<br />
Der wahrscheinlich wichtigste Schritt wird nun das Erstellen von möglichst vielen Testfällen<br />
sein. So können Erfahrungen auf diesem Gebiet gesammelt werden und das Test-<br />
Framework selbst auf seine Praxistauglichkeit getestet werden. In diesem Zusammenhang<br />
ist es sicherlich sinnvoll, häufig benutzte Funktionen in Bibliotheken zusammenzufassen.<br />
So kann das Erstellen von Tests vereinfacht und die Entwicklungszeit verkürzt werden.<br />
Wenn eine gewisse Anzahl an Testfällen existiert, können diese in verschiedenen Testsuites<br />
zusammengefaßt werden. Vorstellbar wäre beispielsweise eine Testsuite, die auf allen
7.2 Ausblick 59<br />
CoreBiz Systemen sinnvoll ausgeführt werden kann und jeweils eine weitere Testsuite für<br />
bestimmte CoreBiz Systeme wie zum Beispiel der CoreBiz Base Server und der CoreBiz<br />
Client. In diesem Zusammenhang sollte auch die Automatisierung der Tests noch einmal<br />
untersucht werden. Zwar wurden einige Konzepte in dieser Arbeit vorgestellt und auch<br />
umgesetzt, für das effektive Durchführen von Regressionstests muß die Automatisierung<br />
aber weiter verbessert werden.<br />
Weiterhin könnten neue Testarten evaluiert werden. Naheliegend wären zum Beispiel<br />
GUI-Tests, die bestimmte Aspekte der grafischen Benutzeroberfläche auf einem CoreBiz<br />
Client überprüfen.<br />
In der Praxis werden CoreBiz Systeme oft in heterogenen Netzwerkumgebungen eingesetzt.<br />
Daher wäre es durchaus vorstellbar, dass auch Windows-Clients im Zusammenspiel<br />
mit einem CoreBiz Base Server getestet werden. Ein sinnvoller Testfall wäre zum<br />
Beispiel die Überprüfung, ob auf einem Windows-Client ein bestimmtes Netzlaufwerk<br />
eingebunden werden kann, das der CoreBiz Base Server mit Hilfe der Software ”<br />
samba“<br />
zur Verfügung stellt.<br />
Ein weiterer Ansatz, um den Testprozess zu vereinfachen, wäre die Entwicklung einer<br />
GUI oder eines Web-Interfaces. Dieses Interface sollte auf einfache Art und Weise das<br />
Ausführen von Testfällen erlauben und die Ergebnisse grafisch aufbereiten. So könnte<br />
auch technisch nicht versierten Mitarbeitern die Möglichkeit gegeben werden, Testfälle<br />
auszuführen und die Ergebnisse zu überprüfen.<br />
Die Problematiken der Virtualisierungssoftware VMware wurde in den vorherigen Kapiteln<br />
schon angesprochen. Deshalb könnten Alternativen evaluiert werden. In diesem<br />
Zusammenhang sollten Xen (vgl. [Unib]) und User Mode Linux (vgl. [Dik]) untersucht<br />
werden. Neben den Performance Vorteilen, die sich eventuell ergeben könnten, wäre dies<br />
auch der Schritt zu einer ausschließlich auf freier Software basierenden Testumgebung.<br />
Sowohl Xen als auch User Mode Linux sind unter der GNU GPL freigegeben.<br />
Bei näherer Betrachtung des Debian Projekts kann festgestellt werden, dass es nur wenige<br />
Ansätze für die Qualitätssicherung durch Softwaretests gibt. Daher könnte geprüft<br />
werden, ob aus dem CoreBiz Regressionstest-Framework bestimmte Teile dem Debian<br />
Projekt zur Verfügung gestellt werden können. Das können verständlicher Weise nur<br />
Teile sein, die nicht CoreBiz-spezifisch sind. So würde einerseits der Open Source Gedanken<br />
weitergeführt werden und andererseits erhofft werden, dass die Qualität von<br />
Debian weiter verbessert wird. Das würde langfristig auch den CoreBiz Produkten zu<br />
Gute kommen.
60 Kapitel 7 Conclusio
Anhang A<br />
Literaturverzeichnis<br />
[Abe] Aberdour, Mark. Open source tools for software testing professionals.<br />
http://opensourcetesting.org/ (Stand: 28.08.2005)<br />
[Deba] Debian. Debian Project Homepage. http://www.debian.org/ (Stand:<br />
28.08.2005)<br />
[Debb]<br />
Debian. Debian-Richtlinien für Freie Software (DFSG). http://www.debian.<br />
org/social_contract#guidelines (Stand: 28.08.2005)<br />
[Dik] Dike, Jeff. The User-mode Linux Kernel Home Page.<br />
http://user-mode-linux.sourceforge.net/ (Stand: 28.08.2005)<br />
[Fau]<br />
[Frea]<br />
[Freb]<br />
Faught, Danny. testingfaqs.org - An information resource for software testers.<br />
http://www.testingfaqs.org/ (Stand: 28.08.2005)<br />
Free Software Foundation. cfengine. http://www.gnu.org/software/<br />
cfengine/cfengine.html (Stand: 28.08.2005)<br />
Free Software Foundation. GNU General Public License. http://www.<br />
gnu.org/licenses/gpl.html (Stand: 28.08.2005)<br />
[Frec] Free Standards Group. Linux Standard Base Project. http://www.<br />
linuxbase.org/ (Stand: 28.08.2005)<br />
[Kan02] Kaner, Bach, Pettichord: Lessons Learned in Software Testing. Wiley,<br />
New York, 2002<br />
[Lan] Lange, Thomas. Fully Automatic Installation (FAI). http://www.<br />
informatik.uni-koeln.de/fai/ (Stand: 28.08.2005)<br />
[Lin]<br />
Linux Test Project. Test Plan. http://ltp.sourceforge.net/testPlan.<br />
php (Stand: 28.08.2005)<br />
[Mye79] Myers, Glenford J.: The Art of Software Testing. John Wiley & Sons, 1979<br />
[Ope]<br />
OpenLDAP Foundation. OpenLDAP. http://www.openldap.org/ (Stand:<br />
28.08.2005)<br />
61
62 Literaturverzeichnis<br />
[OU87]<br />
Ould, Martyn A. ; Unwin, Charles: Testing in Software Development (British<br />
Computer Society Monographs in Informatics). Cambridge University Press,<br />
1987<br />
[Rät04] Rätzmann, Manfred: Software-Testing - Rapid Application Testing, Softwaretest,<br />
Agiles Qualitätsmanagement. Galileo Press, 2004<br />
[Riv] Rivest, Raymond. comp.software.testing Frequently Asked Questions.<br />
http://www.faqs.org/faqs/software-eng/testing-faq/ (Stand:<br />
28.08.2005)<br />
[Sava]<br />
[Savb]<br />
[Savc]<br />
Savoye, Rob. DejaGnu. http://www.gnu.org/software/dejagnu/ (Stand:<br />
28.08.2005)<br />
Savoye, Rob. DejaGnu. http://www.gnu.org/software/dejagnu/manual/<br />
x47.html (Stand: 28.08.2005)<br />
Savoye, Rob. Re: Using DejaGnu in a regression farm. http://lists.gnu.<br />
org/archive/html/dejagnu/2005-08/msg00006.html (Stand: 28.08.2005)<br />
[Sch83] Schmitz, Bons, van Megen: Software-Qualitätssicherung - Testen im<br />
Software-Lebenszyklus. Vieweg, Wiesbaden, 1983<br />
[STA] STAF Core Team. Software Testing Automation Framework.<br />
http://staf.sourceforge.net/ (Stand: 28.08.2005)<br />
[Tha97] Thaller, Georg E.: Der individuelle Software-Prozess. Bhv, 1997<br />
[Tha02] Thaller, Georg E.: Software-Test - Verifikation und Validation. H. Heise<br />
Vlg., Hann., 2002<br />
[Thea] The Open Group. Testing. http://www.opengroup.org/testing/<br />
downloads.html (Stand: 28.08.2005)<br />
[Theb]<br />
[Thec]<br />
[Thed]<br />
The Open Group. TETware and the Open Source Test Environment Toolkit.<br />
http://tetworks.opengroup.org/ (Stand: 28.08.2005)<br />
The Open Group: TETware Programmers Guide. : The Open Group<br />
The Open Group: TETware User Guide. : The Open Group<br />
[Unia] University of California. Berkeley Software Distribution License.<br />
http://www.opensource.org/licenses/bsd-license.php (Stand:<br />
28.08.2005)<br />
[Unib] University of Cambridge. The Xen virtual machine monitor.<br />
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ (Stand: 28.08.2005)<br />
[Wik] Wikipedia. Debian. http://de.wikipedia.org/wiki/Debian (Stand:<br />
28.08.2005)
Anhang B<br />
Abbildungsverzeichnis<br />
2.1 CoreBiz Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
3.1 Remote Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
3.2 Verteilter Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
4.1 Die Komponenten von TET . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
4.2 Aufbau eines Testfalls im TET . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
5.1 Aufbau der CoreBiz Testumgebung für Remote Tests . . . . . . . . . . . 31<br />
5.2 Flussdiagramm Hostname-Test . . . . . . . . . . . . . . . . . . . . . . . 38<br />
6.1 Aufbau der CoreBiz Testumgebung für verteilte Tests . . . . . . . . . . . 42<br />
6.2 Sequenzdiagramm LDAP Konflikttest . . . . . . . . . . . . . . . . . . . . 46<br />
6.3 Sequenzdiagramm LDAP Performance Test . . . . . . . . . . . . . . . . . 48<br />
6.4 Ergebnisse des LDAP Performance Tests (synchron) . . . . . . . . . . . . 50<br />
6.5 Ergebnisse des LDAP Performance Tests (asynchron) . . . . . . . . . . . 51<br />
6.6 Sequenzdiagramm LDAP Latenztest . . . . . . . . . . . . . . . . . . . . 54<br />
63
64 Abbildungsverzeichnis
Anhang C<br />
Tabellenverzeichnis<br />
2.1 Veröffentlichte Versionen von Debian . . . . . . . . . . . . . . . . . . . . 4<br />
2.2 Interner Aufbau eines CoreBiz Systems . . . . . . . . . . . . . . . . . . . 6<br />
3.1 Verschiedene Definitionen von Qualität . . . . . . . . . . . . . . . . . . . 9<br />
4.1 Vergleich von Test Management Tools . . . . . . . . . . . . . . . . . . . . 22<br />
5.1 Zuweisung von TET-IDs zu CoreBiz Systemen . . . . . . . . . . . . . . . 32<br />
6.1 Ergebnis des LDAP Konflikttests . . . . . . . . . . . . . . . . . . . . . . 47<br />
6.2 Ergebnisse des LDAP Performance Tests (synchron) . . . . . . . . . . . . 49<br />
6.3 Ergebnisse des LDAP Performance Tests (asynchron) . . . . . . . . . . . 49<br />
6.4 Ergebnis des LDAP Latenztests . . . . . . . . . . . . . . . . . . . . . . . 55<br />
65
66 Tabellenverzeichnis
Anhang D<br />
Abkürzungsverzeichnis<br />
BSD<br />
CPL<br />
DFSG<br />
DHCP<br />
FAI<br />
GNU<br />
GNU GPL<br />
GUI<br />
IC<br />
KDE<br />
LDAP<br />
LSB<br />
POSIX<br />
PXE<br />
scp<br />
ssh<br />
STAF<br />
tcc<br />
tccd<br />
TCM<br />
TET<br />
TP<br />
Berkeley Software Distribution<br />
Common Public License<br />
Debian Free Software Guidelines<br />
Dynamic Host Configuration Protocol<br />
Fully Automatic Installation<br />
GNU’s Not Unix<br />
GNU General Public License<br />
Graphical User Interface<br />
Invocable Component<br />
K Desktop Environment<br />
Lightweight Directory Access Protocol<br />
Linux Standard Base<br />
Portable Operating System Interface<br />
Preboot eXecution Environment<br />
Secure Shell<br />
Secure Copy<br />
Software Testing Automation Framework<br />
Test Case Controller<br />
Test Case Controller Daemon<br />
Test Case Manager<br />
Test Environment Toolkit<br />
Test Purposes<br />
67