3 Lasttesttools

3.1 Entscheidungskriterien

Last- und Performancetests sind für Webanwendungen unabdingbar, aber auch bei anderen Projekten ein wichtiges Instrument, um die Stabilität und Korrektheit des Systems sicherzustellen. Die Entscheidung, wann und wie diese durchgeführt werden, sollte möglichst früh in Betracht gezogen werden, da jeder Fehler der erst später aufgedeckt wird, um vieles teurer ist, als wenn er in einer frühen Phase der Entwicklung erkannt wird.

Daniel A. Menascé beschreibt in seiner Arbeit "Load Testing of Web Sites" [21] anhand des Modells der vier Schichten des e-Business [22], Anforderungen, die bei der Auswahl von Tools zur Unterstützung der Performancetests beachtet werden sollten.

Die erste Schicht ist das "business model". Aus dieser Sicht dienen Tools zum Aufspüren möglicher Einnahmen oder Verluste, zum Durchführen von Performancetest zur Identifikation, ob die IT-Infrastruktur nicht über- oder unterproportioniert ist und zum Verstehen, wie Businessentscheidungen sich auf die IT-Infrastruktur auswirken. [21]

Die zweite Schicht ist das "functional model", dass sich auf die funktionalen Aspekte der Webanwendung bezieht. Hierbei muss das Tool die gewünschten Funktionen dieser Anwendung unterstützen. Hierzu zählen die verschiedensten genutzten Technologien, wie Flash, JavaScript, Cookies oder SSL-Protokolle. [21]

In der dritten Schicht, dem "customer behavior model", ist es wichtig, dass das gewählte Tool das erwartete Nutzerverhalten abbilden kann. Auch der Ablauf des Erstellens und Anpassens der Skripte, die zur Durchführung der Tests notwendig sind, soll durch das Tool erleichtert werden. Dies ist zum Beispiel durch Aufzeichnen von Nutzeraktionen und graphischen Oberflächen mit den erzeugten Aktionen möglich. [21]

In der letzten Schicht, "model of IT resources", sind Anforderungen an das Tool gestellt, die es ermöglichen, die notwendigen Tests auch im Produktivsystem, anstatt in abgespeckten System durchzuführen. Weiterhin sollen Änderungen am System keine großen Änderungen an den Testskripten oder des Tools nach sich ziehen. Das Tool soll eventuelle Engpässe erkennen oder bei der Erkennung unterstützen und die Testdurchführung sollte nach Wunsch sofort oder zu definierbaren Zeiten erfolgen. [21]

Nachdem für das zu testende System die Anforderungen für das gewünschte Tool herausgearbeitet wurden, ist eine weitere Entscheidung zu treffen. Soll ein Tool für die Last- und Performancetests selbst entwickelt oder soll auf vorhandene Produkte zurückgegriffen werden.

Die Nachteile beim Kauf eines Lasttesttools sind:

• Recherche und Auswahl des Tools kostet viel Zeit
• Lasttesttool erfüllt möglicherweise nicht alle gewünschten Anforderungen
• Überflüssige Funktionen und Möglichkeiten, die nicht genutzt werden, müssen mit bezahlt werden
• Lasttesttools sind teuer

Bei der Selbstentwicklung sind auf den ersten Blick keine Kauf- oder Mietkosten zu erkennen, aber:

• viel Zeit für die Entwicklung nötig
• viele qualifizierte Entwickler und Analysten erforderlich
• "Kinderkrankheiten" von neuen Produkten können sich erst später herausstellen
• Tool wird nicht wieder verwendbar sein, da es auf das bestehende System ausgerichtet ist

3.2 Vergleichsmerkmale

Es gibt zur Zeit eine große Anzahl von Tools, die verschiedenste Systeme oder Anwendungen auf unterschiedlichste Arten testen können. Sie bieten viele Funktionen, die für ein spezielles Testen mehr oder weniger notwendig oder aussagekräftig sind. Aus diesem Grund wird ihr eine Liste von Merkmalen vorgestellt, mit denen man diese Tools vergleichen kann.

3.2.1 Unterstützte Systeme, Protokolle

Das wichtigste Kriterium eines Lasttesttools ist natürlich, dass es die Voraussetzungen mitbringt, dass es mit dem zu testenden System kompatibel ist. Selbst in einer doch schon sehr speziellen Webmehrschichtarchitektur gibt es Kriterien, die nicht alle Lasttesttools unterstützen. So unterstützen viele der Tools zwar das HTTP-Protokoll, aber nicht alle unterstützen ebenfalls das HTTPS-Protokoll. Je nach Architektur des Systems können weitere Protokolle interessant werden.

Der Silkperformerâ - das Lasttesttool der Firma Segueâ unterstützt zum Beispiel folgende Protokolle und Interfaces:

"Supported protocols and interfaces for load testing: HTTP(S)/HTML, Unicode (UTF-8), SOAP (XML), WAP2 (WTLS, MMS), i-Mode, streaming media (MS, Real), Macromedia AMF, FTP, LDAP, MAPI, SMTP, POP, SSL, CORBA (IIOP), Java RMI (EJB/J2EE), .NET remoting, (D)COM, ActiveX, Oracle Forms, Citrix ICA, ODBC, Oracle Call Interface (OCI), DB2 CLI, DLL's, Java (Framework), .NET (Framework), VB (Framework), TCP/IP, UDP, Tuxedo ATMI, Jolt, Jacada, and TN 3270e

Supported CRM/ERP systems: SAP, PeopleSoft, Siebel, Oracle Applications, Chordiant, e.Piphany, SSPS ShowCase, Amdocs Clarify, and Lawson" [28]

3.2.2 Szenario-Unterstützung ( request-flow )

Als Szenario bezeichnet man ein aufeinander folgendes Aufrufen von mehreren Aktionen. In einem Webinterface ist dies das Aufrufen verschiedener Seiten. Szenariounterstützung ist in Projekten mit gesicherten Bereichen für Nutzer unabdingbar. Um diese Bereiche erreichen zu können, muss ein Nutzer erst authentifiziert werden und dies muss für die folgenden Bereiche festgeschrieben werden - hierzu sind inhaltlich zusammenhängende Aktionen notwendig. Weitere Beispiele für die Notwendigkeit der Abbildungen von Aktionsketten sind leicht zu finden.

3.2.3 Parallele Nutzerzahl ( virtual users )

Die Erzeugung einer großen Anzahl paralleler Nutzer, die unabhängig voneinander das System Testen ist eine der wichtigsten Unterscheidungsmerkmale der Lasttesttools. Erreicht das Lasttesttool nicht die parallele Nutzerzahl die getestet werden soll, so ist es nutzlos.

Das Problem von hohen parallelen Nutzerzahlen, die durch ein Lasttesttool verarbeiten werden sollen, ist zum einen das extreme Ansteigen der aufzuzeichnenden Protokolldaten, aber auch das Verwalten und Verteilen der Ausgangsdaten. Hier finden viele Lasttesttools ihre Grenzen, da sie mit einem Rechner diese Daten nicht mehr verwalten, geschweige denn, die gewünschte Last auf das zu testende System vollständig übertragen können. Da dies die meisten Firmen erkannt haben, ist der Preis der Lasttesttools meist auch nach diesem Kriterium gestaffelt.

3.2.4 Verteilte Anwendung ( distributed )

Bei Projekten, die mit einer großen Menge an parallelen Nutzern arbeiten, reicht die Leistung eines Rechners nicht aus, um die gewünschte Last zu erzeugen. Hier müssen mehrere Rechner verteilt zusammen arbeiten. Hierbei ist es nicht ausreichend, dass diese Rechner einfach nur Last auf den Servern erzeugen, sondern es ist auch wichtig, dass die gesammelten Daten wieder zusammengefügt werden, um später eine aussagekräftige Auswertung zu erzeugen. Lasttesttools die dieses unterstützen, besitzen eine Steuerungsinstanz, welche das Anlegen von Tests ermöglichen und verteilen die durchzuführenden Arbeiten auf die Lastgeneratoren und sammeln während oder anschließend an die Tests die Daten für die Weiterverarbeitung ein.

Ein weiterer wichtiger Punkt ist, dass das Verwalten der erzeugten Daten und das Verarbeiten der gesammelten Daten, das zu testende System nicht beeinträchtigen darf.

3.2.5 Testskript-Erzeugung ( recording )

Testskripte sind das wichtigste Utensil für Lasttests. Allein das Erstellen von speziellen Testfällen für ein Projekt kostet einen großen Teil an Zeit und Verständnis. Aber nur durch ein passendes Set an Testfällen können am Ende aus der Vielzahl der gesammelten Daten, Aussagen getroffen werden, ob das System performant ist oder nicht. Ein Lasttesttool kann bei der Erzeugung der Testskripte für das gewünschte Projekt unterstützen. Hier gehen die Möglichkeiten der Tools stark auseinander.

Beginnend bei einfachen Listen von Internetadressen, die unabhängig von einander einfach abgerufen werden, über eigene Skriptsprachen (Python, Jython, Jscript,...), die es teilweise auch ermöglichen, abhängig von vorherigen Aktionen, die nächste Aktion zu beeinflussen, bis hin zu der Möglichkeit Testskripte aufzunehmen. Letzteres umfasst das Nachvollziehen einer Aktionskette, während das Lasttesttool die entsprechenden Skripte aufzeichnet. Die aufgezeichneten Testskripte können dann einzelnen virtuellen Nutzern zugewiesen und bearbeitet werden.

Hier sind wiederum die Protokolle oder Interfaces zu beachten, die durch das Tool unterstützt werden.

3.2.6 Monitoring der Clients und Server

Beim Durchführen der Last- und Performancetests ist zum einen das zu testende System, aber auch die Testumgebung unter Last zu überwachen. Um mögliche Fehlerquellen zu erkennen unterstützen einige Lasttesttools das Beobachten von Testclients sowie von Testservern.

Es werden nicht nur Daten über entsprechende Antwortzeiten, sondern auch über den Zustand einzelner Komponenten gesammelt. Häufig gehören dazu: CPU-Auslastung, Speicherauslastung, Festplattenzugriffe, Netzwerkbelastung - auch wenn diese Angaben nur bedingt aussagekräftig sind. Die Lasttesttools stellen diese Informationen teilweise online, das heißt, während des Testlaufs oder offline, erst nach Beendigung des Testlaufs zur Verfügung.

3.2.7 Analyse-Möglichkeiten

Die Analyse von gesammelten Daten ist nicht von Lasttesttools durchführbar. Sie unterstützen nur das Darstellen der Informationen in den verschiedensten Formen. Beginnend bei einfachen Textdateien, die eine Liste von Zahlen enthalten, über das Darstellen von Graphen und Erzeugen von Berichten, bis hin zu der Möglichkeit alle gesammelten Rohdaten in Tabellen oder Datenbanken zu exportieren.

Doch alle Lasttesttools haben eins gemeinsam, die Auswertung und Interpretation der Ergebnisse müssen anhand der Erwartungen und der erhaltenen Daten, speziell für das getestete System durchgeführt werden.

3.2.8 Kommerziell vs. Open-Source

Zu welchem Produkt man greift, sollte nicht im Vorhinein auf eine finanzielle Entscheidung beschränkt werden. Für viele Projekte sind die Möglichkeiten, die Open-Source-Projekte bieten, ausreichend. Durch die Erweiterung von Open-Source-Projekten durch zusätzliche Implementierungen, kann man mit Zeit und Arbeitsaufwand, ein auf das zu testende System ausgerichtetes Lasttesttool erstellen. Je komplexer die Systemlandschaft wird, desto so größer sind aber auch die Wahrscheinlichkeiten, dass die Open-Source-Projekte an Ihre Grenzen stoßen. Hier sind dann doch kommerzielle Lasttesttools vorzuziehen.

3.3 Einteilung der Lasttesttools in Kategorien

Anhand der vorherigen Vergleichsmerkmale ist es nun möglich, die verschiedenen Lasttest-Tools in Kategorien einzuteilen. Für die Auswahl des Lasttesttools für das Projekt Campus Management bot sich folgende Kategorisierung an:

3.3.1 Kommerzielle "General Purpose"-Werkzeuge

Sie unterstützen auch seltenere Protokolle und Interfaces, geben umfangreiche Unterstützung bei der Erstellung von Testskripten, Graphiken und Berichten, sowie bei der Protokollierung von Zuständen der Server und Clients. Weiterhin werden Probleme, wie Proxies, Firewalls und Netzwerkmonitoring gelöst und bereits vordefinierte Analyseprozesse angeboten.

Sie haben den Nachteil, dass sie sehr schwergewichtig sind und Support und Trainings erfordern, um mit Ihnen arbeiten zu können. Die Kosten für diese kommerziellen Lasttesttools können bis in 6-stellige Eurobeträge reichen.

3.3.2 "Middle Ware"-Werkzeuge

Kommerzielle und mit Einschränkungen auch einige Open-Source Lasttesttools, die aber nur Webanwendungen testen, aber Skript-Aufzeichnung, Online-Monitoring und verteilte Clients unterstützen.

Kaufpreis: ab 15000€

Miete: ab 1200€ pro Woche

3.3.3 Open-Source

Open-Source Lasttools, die nur Webschnittstellen testen und sehr begrenzt Monitoring unterstützen. Ebenfalls ist das Erstellen und von Testskripten meist nur die verschiedene Skriptsprachen möglich und erfordern ein Erweitern der Tools. Diese Tools können nebenläufig, aber nicht verteilt ausgeführt werden. Das Auswerten besteht dann aus dem Zusammenführen der Client-Logs und deren Analyse, die entsprechend aufgewertet werden muss.

3.4 Vorstellung einiger Lasttesttools

In den letzten Abschnitten wurden die Kriterien erläutert, die für Last- und Performancetests mit Hilfe von Tools wichtig sind. In diesem Abschnitt werden nun einige Lasttesttools vorgestellt und ihre Möglichkeiten und Handhabung beschrieben.

Performancetest Bottleneck Testtool Mercury Virtuelle User Testverfahren  Black box test White box test Grey box test testnutzer Virtuelle User Lasttest