Diplomarbeit. Fachhochschule Furtwangen Computer Networking. Thema: Design und Implementierung eines verteilten Regressionstest-Frameworks

Transkript

1 Fachhochschule Furtwangen Computer Networking Diplomarbeit Thema: Design und Implementierung eines verteilten Regressionstest-Frameworks Referent: Prof. Dr. Christoph Reich Fachhochschule Furtwangen Korreferent: Rudolf Strobl Linux Information Systems AG vorgelegt im: Sommersemester 2005 am: 31. August 2005 vorgelegt von: Thilo Alexander Uttendorfer Matrikelnummer: Bismarckstraße Köngen

2 ii Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Diplomarbeit selbständig und ohne unzulässige fremde Hilfe angefertigt habe. Die verwendeten Quellen und Hilfsmittel sind vollständig zitiert. München, den 29. August 2005 Thilo Alexander Uttendorfer Bismarckstraße Köngen

3 Inhaltsverzeichnis 1 Einleitung Problemstellung Vorgehensweise CoreBiz Debian GNU/Linux CoreBiz Ressource-Pool Installation und Konfiguration von CoreBiz Systemen Generierung von Systemen Installation Konfiguration Qualitätssicherung des CoreBiz Ressource-Pools Zusammenfassung Software-Test Softwarequalität Ausprägungen von Tests Testarten Testszenarien Regressionstest Zusammenfassung Test-Werkzeuge und Testsuites Automatisiertes Testen Test-Werkzeuge Vergleich von Test Management Tools Test Environment Toolkit Testsuites Linux Standard Base Testsuites CoreBiz Testsuites Zusammenfassung iii

4 iv Inhaltsverzeichnis 5 CoreBiz Testsuite - Remote Tests Ausgangssituation Aufbau der Testumgebung TET-Lite vs. Distributed TET Virtualisierungssoftware Konfiguration der Systeme Ablauf eines Testfalls Testarten Verifikation von Konfigurationen Funktionstests Performance Tests Ein prototypischer Testfall Ziel Implementierung Problematiken bei Remote Tests Zusammenfassung Corebiz Testsuite - Verteilte Tests Aufbau der Testumgebung Das Test Environment Toolkit und verteilte Tests Einbinden von weiteren Programmiersprachen Synchronisation Installation von verteilten Tests Drei prototypische Testfälle LDAP Konflikttest LDAP Performance Test LDAP Latenztest Problematiken bei verteilten Tests Zusammenfassung Conclusio Fazit Ausblick A Literaturverzeichnis 61 B Abbildungsverzeichnis 63 C Tabellenverzeichnis 65 D Abkürzungsverzeichnis 67

5 Kapitel 1 Einleitung 1.1 Problemstellung Das Ziel dieser Diplomarbeit ist die Erarbeitung eines Konzepts für ein verteiltes Regressionstest-Framework und dessen prototypische Implementierung. Hintergrund dieser Tests ist die Qualitätssicherung der Produktreihe CoreBiz, die von der Linux Information Systems AG entwickelt wird. CoreBiz basiert auf dem Softwarearchiv von Debian GNU/Linux. Dieses Archiv wird in regelmäßigen Abständen aktualisiert. Das bedeutet, dass jedes Softwarepaket, für das eine aktuellere Version verfügbar ist, durch diese ersetzt wird. Um nach solch einer Aktualisierung eine Regression, also einen Rückschritt bei der Qualität zu verhindern, müssen verschiedene Tests durchgeführt werden. Das Regressionstest-Framework soll die bisherige Testumgebung integrieren und erweitern. Dabei soll untersucht werden, welche Arten von Tests sinnvoll eingesetzt werden können. Besondere Bedeutung haben die so genannten verteilten Tests. Diese unterscheiden sich zu normalen Tests dahingehend, dass die Komponenten eines solchen Testfalls auf verschiedenen Systemen eines lokalen Netzwerkes ablaufen und sich zeitlich und inhaltlich aufeinander beziehen. Es werden also die Interaktionen zwischen verschiedenen Systemen getestet. 1.2 Vorgehensweise Zunächst wird die Produktreihe CoreBiz vorgestellt. Da sich das Regressionstest-Framework vorrangig auf die verschiedenen Produkte von CoreBiz bezieht, ist ein grundlegendes Verständnis über den Aufbau dieser Software nötig. Es wird gezeigt was die Software leistet und aus welchen Komponenten sie besteht. Aus diesem Zusammenhang heraus wird erläutert, warum und an welchen Punkten Softwaretests eingesetzt werden sollen. Anschließend wird auf das Thema Softwaretest im Allgemeinen eingegangen. Es wird die Notwendigkeit eines Qualitätsmanagements von Software aufgezeigt und es werden 1

6 2 Kapitel 1 Einleitung verschiedene Testarten näher erläutert. Darauf folgt ein Überblick über Werkzeuge, die den Testprozess unterstützen und vereinfachen. In diesem Zusammenhang werden die Möglichkeiten sowie die Vor- und Nachteile der Automatisierung von Tesfällen diskutiert. Der praktische Teil dieser Arbeit enthält die prototypische Implementierung von Remote und verteilten Tests. Es wird gezeigt, wie eine Testumgebung für Testfälle dieser Art realisiert werden kann. Auf einige exemplarische Testfälle wird näher eingegangen und es werden die Probleme und Ergebnisse dieser Tests diskutiert. Zum Ende dieser Arbeit wird ein Fazit gezogen und ein Ausblick für die Zukunft dargestellt.

7 Kapitel 2 CoreBiz Eine modular aufgebaute Software um Linux für unterschiedlichste Einsatzzwecke zu installieren und zu konfigurieren wird unter dem Namen CoreBiz von der Linux Information Systems AG angeboten. Als Basis wird dafür die Linux Distribution Debian GNU/Linux (vgl. [Deba]) benutzt. Da sich diese Arbeit an vielen Stellen immer wieder darauf bezieht, wird im Folgenden der Aufbau und die Funktionsweise von Core- Biz Systemen im Detail erläutert. In diesem Zusammenhang wird zunächst auf Debian GNU/Linux eingegangen. 2.1 Debian GNU/Linux Debian GNU/Linux ist ein freies Betriebssystem, das unterschiedlichste Rechnerarchitekturen unterstützt und mehrere Tausend Softwarepakete enthält. Es wird im Gegensatz zu vielen anderen Linux Distributionen ausschließlich von Freiwilligen entwickelt und ist die am weitesten verbreitete nicht-kommerzielle Linux Distribution (vgl. [Wik]). Debian hat sehr strenge Richtlinien in Bezug auf Software, die in die Distribution aufgenommen wird. So wird ausschließlich Software zugelassen, die unter einer freien Lizenz, wie zum Beispiel der GNU General Public License (GPL) oder der Berkeley Software Distribution (BSD) License 1, veröffentlicht wurde. Diese Richtlinien sind in den Debian Free Software Guidelines (DFSG) (vgl. [Debb]) geregelt. Debian hebt sich von anderen Linux Distributionen vor allem durch sein Paketmanagement ab, welches das Aktualisieren von Paketen und das Auflösen von Abhängigkeiten zwischen diesen Paketen zuverlässig löst. Außerdem bietet es ein sehr umfangreiches Archiv an Software. Dieses Archiv ist in drei 2 verschiedenen Varianten erhältlich: stable, testing und unstable. Dabei enthält stable die jeweils letzte veröffentlichte Version und testing die Kommende aber noch nicht veröffentlichte Version des Betriebssystems. Die Variante unstable enthält jeweils relativ aktuelle, meist aber ungetestete Pakete, die, wie der Name schon sagt, unstabil oder fehlerhaft sein können. 1 Die beiden Lizenzen findet man unter [Freb] beziehungsweise unter [Unia] 2 Es gibt noch eine vierte Variante experimental, die aber nur für Entwickler gedacht ist. 3

8 4 Kapitel 2 CoreBiz 2.2 CoreBiz Ressource-Pool Größter Nachteil an Debian (zum Zeitpunkt des Schreibens dieser Arbeit) ist der sehr lange Releasezyklus. Tabelle 2.1 zeigt die veröffentlichten Versionen der letzten Jahre. Der immer größer werdende Abstand zwischen den Versionen ist unter anderem auf die Vielzahl der unterstützten Architekturen und der stetig steigenden Anzahl an Paketen zurückzuführen. Das Debian Projekt ist sich zwar diesem Problem bewußt und arbeitet an Lösungen, es ist jedoch nicht damit zu rechnen, dass es mittelfristig deutlich kürzere Releasezyklen geben wird. Version Name Datum 2.0 Hamm 24. Juli Slink 9. März Potato 15. August Woody 19. Juli Sarge 6. Juni 2005? Etch? Tabelle 2.1: Veröffentlichte Versionen von Debian (Quelle: [Deba]) Daraus ergibt sich, dass die stabile Variante von Debian zum Teil sehr alte Pakete enthält, da in diesem Archiv nur eventuelle Sicherheitslücken beseitigt werden, jedoch keine neuen Pakete hinzugefügt werden. Dagegen werden die Varianten testing und unstable ständig mit neuen Paketen aktualisiert. Das führt dazu, dass sich auch grundlegende Teile des Systems verändern können und diese Varianten somit keine verlässliche Lösung darstellen. Die Anforderungen an ein CoreBiz System sind aber einerseits die Verfügbarkeit aktueller Versionen von bestimmten Softwarepaketen, andererseits muß die Software stabil und langfristig einsetzbar sein. Um dieses Dilemma zu überwinden, wird für CoreBiz in regelmäßigen Abständen ein so genannter Snapshot aus testing gemacht. Das bedeutet, dass sämtliche Pakete aus dem Debian Archiv eingefroren werden und von diesem Zeitpunkt an nur noch durch Sicherheitsaktualisierungen oder Bugfixes verändert werden können. Dadurch sind CoreBiz basierte Server und Clients einerseits aktueller als entsprechende, auf Debian stable basierende Systeme. Andererseits wird trotzdem versucht die Stabilität und Qualität von Debian stable zu erreichen. Diesem regelmäßig aktualisiertem Archiv werden dann zusätzlich CoreBiz-spezifische Pakete hinzugefügt. Um begrifflichen Missverständnissen vorzubeugen, wird dieses Archiv CoreBiz Ressource-Pool bezeichnet.

9 2.3 Installation und Konfiguration von CoreBiz Systemen Installation und Konfiguration von CoreBiz Systemen Die Basis jeder CoreBiz Installation ist der so genannte CoreBiz Factory Server. Dieses System verfügt über alle Komponenten, die nötig sind, um weitere Systeme zu installieren und hat direkten Zugriff auf den CoreBiz Ressource-Pool. Hier werden sämtliche Konfigurationseinstellungen, Parameterisierungen und Kundenanpassungen durchgeführt, um daraus den so genannten CoreBiz Base Server zu generieren. Der CoreBiz Base Server wird an den Kunden ausgeliefert und ist dann in der Lage, weitere Systeme zu installieren. Diese Fähigkeit wird zum Beispiel genutzt, um die Installation von Clients direkt vor Ort beim Kunden durchzuführen. Abbildung 2.1 zeigt den typischen Aufbau einer CoreBiz Umgebung. CoreBiz Factory CoreBiz Base CoreBiz Ressource-Pool installiert installiert CoreBiz Backup CoreBiz Client CoreBiz Client CoreBiz Client Abbildung 2.1: CoreBiz Umgebung

10 6 Kapitel 2 CoreBiz Auf dem CoreBiz Factory Server beziehungsweise dem CoreBiz Base Server ist das Softwarepaket OpenLDAP (vgl. [Ope]) installiert, um Benutzerkonten und Gruppen mittels des Lightweight Directory Access Protocol (LDAP) zentral verwalten zu können. Außerdem wird der LDAP-Server genutzt, um bestimmte Server-Dienste zu parameterisieren. Das wird aber nur von einigen Diensten unterstützt, wie beispielsweise dem DHCP- Server. Wenn alle Kundenanpassungen und Konfigurationen für ein neues System erstellt wurden, werden im wesentlichen folgende Schritte durchgeführt: 1. Generierung 2. Installation 3. Konfiguration Generierung von Systemen Wichtiger Bestandteil ist die frei erhältliche Software FAI (Fully Automatic Installation) (vgl.[lan]), welche die Infrastruktur für eine komplett automatische Installation über das Netzwerk oder die Generierung von Installations-CDs ermöglicht. Anhand von Profilen und Komponenten werden die unterschiedlichen CoreBiz Systeme erstellt. Tabelle 2.2 zeigt den Zusammenhang zwischen Profil, Komponente und Debian-Paket. Ein Profil stellt ein komplettes CoreBiz System dar. Eine Komponente dagegen ist ein bestimmter Teil eines Systems, wie zum Beispiel die KDE Umgebung, und enthält eine Liste von Debian-Paketen. Da die Komponenten aber unabhängig von einem Profil sind, können sie beliebig in anderen Profilen wiederverwendet werden. Durch diesen modularen Ansatz ist es möglich, auf einfache Art und Weise Kundenanpassungen durchzuführen. enthält Beispiel Profil Liste mit Komponenten CoreBiz Client Komponente Liste mit Paketen KDE Umgebung Paket Debian-Paket Konqueror Tabelle 2.2: Interner Aufbau eines CoreBiz Systems Installation Die Installation eines CoreBiz Systems erfolgt vollkommen automatisch entweder durch eine Installations-CD oder über das Netzwerk. Im Falle der Netzwerkinstallation wird PXE (Preboot execution Environment) genutzt, um ein System automatisch zu installieren. Als PXE-Boot-Server dient dabei der CoreBiz Factory Server beziehungsweise der CoreBiz Base Server.

11 2.4 Qualitätssicherung des CoreBiz Ressource-Pools 7 Einem System, das über das Netzwerk installiert wird, wird mit Hilfe von DHCP (Dynamic Host Configuration Protocol) eine IP-Adresse zugewiesen. Daraufhin wird vom Server ein Kernel heruntergeladen mit dem das System in der Lage ist zu booten. Die Installation erfolgt dann in zwei Phasen. Während der ersten Phase werden Systeminformationen ausgelesen und an den Server übermittelt. Es werden dabei entsprechende Eintragungen im LDAP des CoreBiz Base Servers vorgenommen. Ab diesem Zeitpunkt ist das System registriert und es können beispielsweise Hardwareinformationen ausgelesen oder das zu installierende Profil geändert werden. Nach einem Neustart des Systems erfolgt dann die zweite Phase mit der eigentlichen Installation. Die Installation von CD kann unabhängig der Netzwerkumgebung durchgeführt werden. Von Nachteil ist allerdings die Beschränkung der Kapazität auf eine CD oder, falls ein entsprechendes Laufwerk vorhanden ist, auf eine DVD. Zum Beispiel kann es bei einem so genannten Fat Client sein, dass mehrere Gigabyte an Softwarepaketen installiert werden müssen Konfiguration Ziel jeder CoreBiz Installation ist es, ohne manuellen Eingriff abzulaufen. Das setzt voraus, dass alle Konfigurationsparameter schon vor der Installation festgelegt werden. Des weiteren ist es oft wünschenswert bestimmte Konfigurationen bei produktiven Systemen später zu ändern. Um diese Anforderungen realisieren zu können, wird das Werkzeug cfengine (vgl. [Frea]) eingesetzt. Der Name cfengine leitet sich von configuration engine ab. Damit lassen sich unter anderem Konfigurationsdateien auf einfache und elegante Art und Weise modifizieren. Es bringt eine eigene Programmiersprache mit, die im Gegensatz zu vielen anderen Sprachen ohne die üblichen if-else-anweisungen auskommt. Anweisungen werden dagegen in Abhängigkeit von bestimmten Klassen ausgeführt, die frei definiert werden können. Weiterhin stehen eine Vielzahl von vordefinierten Klassen zur Verfügung, die beispielsweise bestimmte Systemeigenschaften wie die Kernelversion repräsentieren. Bei einem CoreBiz System wird dieses Werkzeug genutzt, um bestimmte Systemparameter in Konfigurationsdateien zu setzen oder zu überprüfen. Das können beispielsweise grundlegende Dinge wie die Netzwerkkonfiguration sein, aber auch das Hintergrundbild der grafischen Oberfläche kann so verändert werden. 2.4 Qualitätssicherung des CoreBiz Ressource-Pools Bei einer Aktualisierung des CoreBiz Ressource-Pools wird die Variante testing des Debian Archivs verwendet. Dabei kann nicht davon ausgegangen werden, dass alle Pa-

12 8 Kapitel 2 CoreBiz kete fehlerfrei sind, beziehungsweise sich alle Programme genau so verhalten wie ihre Vorgängerversion. Fehler können beispielsweise schon daraus entstehen, dass sich der Name eines Parameters einer Konfigurationsdatei ändert. Wenn dieser Parameter durch CoreBiz mittels cfengine kontrolliert wird, würde dies höchstwahrscheinlich zu einer fehlerhaften Konfiguration führen. Es könnten sich aber auch die Schnittstellen eines Programmes geändert haben oder es fehlen sogar bestimmte Pakete im Ressource-Pool. Das bisherige Verfahren bei einer Aktualisierung des Ressource-Pools war, das auf einer CoreBiz Installation Tests der Linux Standard Base (LSB) ausgeführt wurden. Diese Tests überprüfen verschiedene Aspekte wie zum Beispiel die POSIX-Kompatibilität oder die Konformität des Dateisystems zur LSB. Damit kann zwar eine gewisse Grundfunktionalität abgedeckt werden, aber es wäre wünschenswert weitergehende Tests durchzuführen. Deshalb gibt es den Ansatz, Konfigurationsdateien, die durch cfengine automatisch verwaltet werden, mit Hilfe von Tests zu verifizieren. Vorstellbar sind aber auch weitergehende Tests, die direkt bestimmte Funktionalitäten von CoreBiz Systemen überprüfen oder aber auch Performance- und Lasttests. Ziel aller Tests ist es, festzustellen, ob sich nach einer Aktualisierung des Ressource- Pools, die Funktionalität der CoreBiz Skripte, die CoreBiz Systeme an sich und das Zusammenspiel verschiedener CoreBiz Systeme miteinander in irgendeiner Form beeinträchtigt ist. Auf letzteres, also die Interaktion zwischen verschiedenen Systemen, wird dabei besonderen Wert gelegt. 2.5 Zusammenfassung In diesem Kapitel wurden die Komponenten eines CoreBiz Systems erklärt. Neben Debian GNU/Linux, welches die Basis für alle CoreBiz Systeme darstellt, wurde die Generierung, die Installation und die Konfiguration dieser Systeme detailliert erläutert. Besonders interessant ist die Qualitätssicherung des Resource-Pools, der sämtliche Software enthält, die bei CoreBiz Systemen verwendet wird. Es wurde gezeigt, dass bei CoreBiz Systemen unterschiedliche Software integriert wird und diese Systeme im Netzwerk zusammenarbeiten und voneinander abhängig sind. Um Fehler in einem CoreBiz System, aber auch in der vollständigen CoreBiz Umgebung zu verhindern, müssen gewisse Tests durchgeführt werden. Es ist also nötig ein Konzept für die Qualitätssicherung dieser Systeme zu entwickeln und zu realisieren.

13 Kapitel 3 Software-Test Testing is the process of executing a program with the intent of finding errors. [Mye79, Seite 5] In diesem Kapitel wird auf die Notwendigkeit des Qualitätsmanagements von Software eingegangen. Es soll einen Überblick über die grundlegenden Termini und Themen aus dem Gebiet der Softwaretests im Hinblick auf die CoreBiz Testumgebung geben. Besondere Beachtung wird den verschiedenen Testausprägungen geschenkt. 3.1 Softwarequalität Definition von Definition 1 Philip B. Crosby Qualität ist die Erfüllung von Anforderungen 2 DATEV Qualität ist Kundenzufriedenheit 3 Thaller Qualität ist Fehlerfreiheit 4 Weinberg Qualität heißt, die Anforderungen eines Menschen zu erfüllen Tabelle 3.1: Verschiedene Definitionen von Qualität (Quelle: [Tha97]) Tabelle 3.1 zeigt verschiedene Definitionen von Qualität. Wenn Qualität mit Fehlerfreiheit definiert wird, stellt sich zunächst die Frage, wie es überhaupt dazu kommt, dass Fehler entstehen: Fehler entstehen prinzipiell in jeder Phase eines Softwareprojekts, beim Aufnehmen der Anforderungen, beim Erstellen des Designs und bei der Kodierung der Software (vgl. [OU87, Seite 5]). Problematisch dabei ist, dass Fehler in einer frühen Phase in der Regel zu Folgefehlern in den darauf folgenden Phasen führen. Wie empirische Untersuchungen gezeigt haben, sind solche Fehler, die in späten Phasen der Software- Entwicklung oder sogar erst im Betrieb gefunden werden, sehr teuer (vgl. [Sch83, Seite 61f]). Es ist also notwendig, in allen Phasen eines Projekts zu testen und Fehler möglichst früh zu erkennen und zu beheben. Das führt aber dazu, dass das Testen einen nicht unbeachtlichen Teil am Gesamtaufwand eines Projekts einnimmt und somit zu einem 9

14 10 Kapitel 3 Software-Test aufwändigen und kostspieligen Prozess wird. Thaller schreibt von 30 bis 50 Prozent des Gesamtaufwands, welches das Testen eines Softwareprojekts an Ressourcen verschlingen kann (vgl. [Tha02, Seite 49]). Die Erfahrungen in der Softwareentwicklung haben gezeigt, dass es praktisch unmöglich ist, fehlerfreie Software zu schreiben. Thaller stellte eine interressante Rechnung an, die das verdeutlicht: Er nimmt relativ optimistische Fehlerraten an und berechnet damit die Anzahl der nicht erkannten schwerwiegenden Fehlern von verschiedenen Softwareprojekten. Ein Beispiel ist die Software für das Navigationssystem des Space Shuttles. Obwohl die NASA eine der niedrigsten Fehlerraten der Industrie aufweist, muß trotzdem mit 100 schwerwiegenden Fehlern gerechnet werden, die nicht erkannt werden. Es muß beachtet werden, dass dies die Anzahl der Fehler ist, die nach dem Test der Software verbleibt (vgl. [Tha02, Seite 17]). Für die Qualitätssicherung von Software bedeutet das, dass auch hier ständig Fortschritte und Verbesserungen erzielt werden müssen. Nur so kann bei immer größer werdenden Softwareprojekten die Qualität sichergestellt werden. Trotzdem muß auch die Wirtschaftlichkeit des Testens im Auge behalten werden. Es macht einen Unterschied, ob von einer Software Menschenleben abhängen oder ob durch einen Softwarefehler nur Daten verloren gehen, die mit etwas Aufwand wiederhergestellt werden können. Entsprechend muß der Aufwand abgeschätzt werden, der in das Testen der Software investiert wird. 3.2 Ausprägungen von Tests Softwaretests haben das Ziel, bestimmte Systemparameter zu erzeugen und zu ermitteln. Diese Systemparameter werden je nach Ausprägung des Tests auf unterschiedliche Art und Weise erzeugt. Sie werden dann mit den eigentlich korrekten Parametern verglichen und entsprechend bewertet. Die erwarteten Systemparameter müssen daher eindeutig ermittelt werden können (vgl. [Rät04, Seite 34]). Nachfolgend werden verschiedene Arten von Tests erläutert und dann mögliche Testszenarien vorgestellt Testarten Im folgenden wird auf verschiedene Arten von Tests eingegangen, die für das Qualitätsmanagement von CoreBiz sinnvoll erscheinen. Verifikation von Konfigurationen Diese Art des Tests darf nicht mit Konfigurationstests verwechselt werden, bei denen es in der Regel um das Zusammenspiel einer Software mit unterschiedlichen Hardwarekonfigurationen geht. Bei der Verifikation von Konfigurationen handelt es sich um

15 3.2 Ausprägungen von Tests 11 Tests, die bestimmte Werte in Konfigurationsdateien verifizieren, welche automatisch, zum Beispiel durch ein Skript, verändert werden. Für den Test bedeutet das, dass ein Programm oder Skript ausführt wird, welches bestimmte Parameter in einer Konfigurationsdatei auf einen vorher festgelegten Wert setzt. Dann wird diese Konfigurationsdatei beziehungsweise die einzelnen Parameter mit dem erwartetem Ergebnis verglichen. Die Tests sind nötig, da sich beispielsweise der Aufbau einer Konfigurationsdatei oder der Name eines Parameters ändern kann. Ein Skript, das diese Datei verändern will, würde dann eine fehlerhafte Konfiguration hinterlassen. Als Nebeneffekt lassen sich damit auch Fehler im Skript selbst aufdecken. Funktionstest Funktionstests überprüfen das Ergebnis eines Aufrufs eines Programms (vgl. [Tha02, Seite 122ff]). Sie setzen die korrekte Konfiguration aller Programme, die am Test beteiligt sind, vorraus. Eine korrekte Konfiguration ist aber noch kein Garant für einen erfolgreichen Funktionstest. Der Test führt ein Programm aus und vergleicht dessen Rückgabewert mit dem erwartetem Ergebnis. Vor der eigentlichen Überprüfung des Rückgabewertes werden in der Regel andere Programme oder Skripte ausgeführt, die diesen Rückgabewert beeinflussen. Stress- und Lasttest Wie Boris Beizer bemerkt, werden diese beiden Begriffe sehr oft falsch benutzt und als Synonyme verwendet (vgl. [Riv]). Nachfolgend wird versucht, die Unterschiede dieser beiden Testarten aufzuzeigen. Bei einem Stresstest wird versucht das zu testende Programm extrem zu belasten. Es wird dabei keinesfalls erwartet, dass das Programm unter dieser Belastung korrekt weiterarbeitet. Das Programm sollte aber zum Beispiel mit einer entsprechenden Fehlermeldung abbrechen. Das ist oftmals aber nicht der Fall und das Programm kann abstürzen oder Daten beschädigen. Beim Lasttest dagegen wird das Programm gleichmäßig über einen längeren Zeitraum unter Last gesetzt. Es sollen also die Auswirkungen getestet werden, wenn eine Funktion nicht nur einmal ausgeführt wird, sondern über eine bestimmte Dauer ständig wiederholt wird. Wenn ein Programm zum Beispiel für eine Funktion Speicher reserviert, aber aufgrund eines Fehlers nicht mehr freigibt, dann fällt das beim einmaligen Ausführen möglicherweise nicht weiter auf. Durch das ständige Wiederholen würde höchstwahrscheinlich aber auch solch ein Fehler erkannt.

16 12 Kapitel 3 Software-Test Performance Test Performance Tests sollen die Geschwindigkeit bestimmter Funktionen des Systems messen. Das Besondere an diesem Test ist, dass kein Fehler auftreten muß, sondern nur verschiedene Messwerte zurückgeliefert werden. Diese müssen dann entsprechend interpretiert werden und zum Beispiel mit Referenzwerten verglichen werden. So kann beispielsweise die Performance-Verbesserung zwischen zwei Programmversionen gemessen werden. Aber auch die Unterschiede in Bezug auf die Performance beim Einsatz verschiedener Hardwarekonfigurationen können so bestimmt werden. Weiterhin lassen sich Performance Tests mit Lasttests kombinieren. Es wird also die Performance eines Programmes oder einer Funktion unter verschieden großen Lasten gemessen Testszenarien Tests können auf unterschiedliche Weise durchgeführt werden. Im folgenden wird auf diese Szenarien näher eingegangen: Lokaler Test Remote Test Verteilter Test Lokaler Test Ein lokaler Test wird direkt auf dem Testsystem ausgeführt, die Systemparameter werden dort ermittelt und verglichen. Es kann für den Test selbst aber nötig sein, dass weitere Systeme im Netzwerk verfügbar sind. Diese Systeme werden allerdings nicht vom Testframework kontrolliert oder beeinflusst. Lokale Tests haben den Vorteil, dass sie in der Regel auf einem beliebigen System installiert und ausgeführt werden können. Im Vergleich zu Remote und verteilten Tests ist der Konfigurationsaufwand minimal. Die Ergebnisse können auf dem Testsystem selbst ausgewertet werden. Problematisch wird dieser Ansatz, wenn auf mehreren Systemen Tests ausgeführt werden sollen. Der Aufwand, um die Ergebnisse auszuwerten steigt in diesem Fall deutlich an.

17 3.2 Ausprägungen von Tests 13 Remote Test Ein Remote Test ist im Prinzip ein lokaler Test, welcher aber von einem zentralen System aus gesteuert wird. Dieses System kann auf einem oder mehreren entfernten Systemen die Tests ausführen. Die Ergebnisse jedes einzelnen Systems werden dann ebenfalls zentral auf diesem System erfasst. Es kann außerdem selbst eines der Systeme sein, auf dem Tests ausgeführt werden. Abbildung 3.1 zeigt eine mögliche Testumgebung. Server Tests ausführen LAN Testsystem Testsystem Testsystem Abbildung 3.1: Remote Test Mit diesem Ansatz ist es möglich, einen Test auf unterschiedlichen Systemen gleichzeitig auszuführen oder aber auch unterschiedliche Tests auf viele, eventuell sogar identische, Systeme zu verteilen. Der größte Vorteil gegenüber lokalen Tests ist die Tatsache, dass es nur noch eine zentrale Datei mit Ergebnissen sämtlicher Tests gibt. Allerdings ist der Konfigurationsaufwand etwas höher als bei lokalen Tests. Durch Automatisierung kann aber dieser Aufwand auf ein Minimum reduziert werden. Verteilter Test Bei verteilten Tests geht es nicht darum, Tests durch ein Lastverteilungsverfahren auf mehrere parallel arbeitende Systeme zu verteilen, um so eine schnellere Durchführung der Tests zu ermöglichen. Das ist schon mit Hilfe der Remote Tests möglich. Das Wort verteilt bezieht sich vielmehr auf den Testfall, der über mindestens zwei Systeme verteilt ist. Diese Systeme sind über ein Netzwerk verbunden und können miteinander kommunizieren.

18 14 Kapitel 3 Software-Test Die einzelnen Schritte eines solchen Tests, also die Erzeugung und Ermittlung von Systemparametern, müssen zeitlich und inhaltlich aufeinander abgestimmt sein. Das bedeutet, dass jeder Schritt vom vorherigen abhängig ist und erst gestartet werden darf, wenn dieser abgeschlossen ist. Um diesen zeitlichen Ablauf zu kontrollieren, werden sogenannte Synchronisationspunkte verwendet. Die Testsysteme warten dann gegenseitig aufeinander, bis jeder an diesem Synchronisationspunkt angelangt ist und fahren erst dann mit den weiteren Testschritten fort. Abbildung 3.2 zeigt eine mögliche Testumgebung. Server Tests ausführen LAN Aktion 1 Aktion 2 Testsystem Testsystem Abbildung 3.2: Verteilter Test Verteilte Tests werden benötigt, wenn bestimmte Interaktionen zwischen den Testsystemen getestet werden sollen. Damit sind auf den Testsystemen stattfindende Aktionen gemeint, die die Interaktion der Systeme beeinflussen. Für die Erzeugung und Ermittlung von Systemparametern auf einem System ist es also nötig, dass auf einem anderen System in zeitlich koordinierter Abfolge bestimmte Aktionen durchgeführt werden. Weiterhin ist es möglich, Nachrichten zwischen den Testsystemen auszutauschen. Das heißt, dass es zur Laufzeit des Tests möglich ist, die einzelnen Testschritte zu beeinflussen. Es werden also nicht nur die jeweilgen Testschritte nach einem vorgegebenen Schema auf den beteiligten Systemen ausgeführt, sondern jeder Testschritt kann vom vorherigen beeinflusst werden und darauf reagieren.

19 3.3 Regressionstest Regressionstest Regressionstests werden eingesetzt, um eine Regression, also einen Rückschritt beziehungsweise eine Verschlechterung einer Software zu erkennen. Das heißt, dass Funktionalitäten getestet werden, die in einer älteren Version fehlerfrei waren. Außerdem soll verhindert werden, dass alte, eventuell schon behobene Fehler wieder in der Software auftauchen. Dazu bietet es sich an, alte Tesfälle zu wiederholen und die Ergebnisse mit den früheren Ergebnissen zu vergleichen. Die verschiedenen Testarten, die unter Punkt beschrieben wurden, können prinzipiell alle für einen Regressionstest eingesetzt werden. Damit der Aufwand nicht zu groß wird, macht es Sinn, sämtliche Tests so weit wie möglich zu automatisieren. Dann ist es auch möglich, die Tests regelmäßig, insbesondere vor einem neuen Release, auszuführen. Der Aufwand für die Automatisierung darf aber keinesfalls unterschätzt werden (vgl. [Rät04, Seite 171]). Bei CoreBiz ist der Einsatz von Regressionstests besonders wichtig. Da bei einem CoreBiz System unterschiedlichste Software integriert wird, auf die keinen oder nur geringen Einfluss ausgeübt werden kann, darf nicht davon ausgegangen werden, dass sich die Software absolut gleich wie ihre Vorgängerversion verhält. Durch das Wiederholen von Testfällen kann auch diese Software getestet werden und somit läßt sich sicherstellen, dass sich diese Software weiterhin wie gewohnt in das System integrieren läßt. 3.4 Zusammenfassung In diesem Kapitel wurde gezeigt, dass die Qualität von Software eine äußerst wichtige Rolle spielt, die nicht unterschätzt werden darf. Diese zu sichern ist die Aufgabe von Softwaretests, auf deren verschiedenen Ausprägungen eingegangen wurde. Speziell die verteilten Tests stellen dabei ein äußerst interessantes Gebiet dar. Als eine besondere Testart sind die Regressionstests zu verstehen. Damit werden zwar kaum neue Fehler gefunden, allerdings kann damit die Abwesenheit von Fehlern gezeigt werden. In diesem Zusammenhang ist die Automatisierung von Testfällen besonders wichtig. Darauf wird detailliert im nächsten Kapitel eingegangen.

20 16 Kapitel 3 Software-Test