Leistungsmessung- und bewertung

Westfälische Wilhelms-Universität Münster
Seminararbeit
Leistungsmessung- und bewertung
im Rahmen des Seminars „Qualitätsmanagement in der Softwaretechnik“
Tobias Müller
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Dipl.-Wirt.Inform. Roger Müller
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Inhaltsverzeichnis
1
Qualitätsanforderungen an Software-Systeme.........................................................3
2
Grundlagen der Leistungsmessung- und bewertung ................................................3
3
2.1
Leistung als Qualitätsmerkmal.........................................................................3
2.2
Definition und Kenngrößen von Leistung .......................................................4
2.3
Norm DIN 66273.............................................................................................5
Methoden, Testverfahren und Werkzeuge...............................................................6
3.1
Methoden zur Leistungsbewertung ..................................................................6
3.2
Der Leistungstest .............................................................................................9
3.3
Testtools........................................................................................................16
4
Relevanz der Leistungsüberprüfung......................................................................20
5
Literaturverzeichnis..............................................................................................21
II
Kapitel 1: Qualitätsanforderungen an Software-Systeme
1 Qualitätsanforderungen an Software-Systeme
In der heutigen Zeit übernehmen Software-Systeme immer komplexere und
verantwortungsvollere Aufgaben. Die Gesellschaft ist in vielen Lebensbereichen auf das
fehlerfreie Funktionieren von Software angewiesen.
Ausfälle, Fehler oder Leistungseinbußen von Software-Systemen in privaten
Haushalten, Unternehmen oder beim Militär können nicht nur ärgerlich sein und das
Ansehen des Herstellers negativ beeinflussen, sondern enorme wirtschaftliche Schäden
verursachen und Gefahren bergen. Neben Büroanwendungen werden heute
medizinische Geräte, Flugzeuge und Raketen, sowie Kraftwerke und chemische
Anlagen durch Software gesteuert.
Ein wichtiges Ziel der Softwareentwicklung und des Qualitätsmanagements sollte also
die Herstellung fehlerfreier und qualitativ hochwertiger Software sein. Die Qualität
einer Software leitet sich dabei nicht nur aus der Fehlerfreiheit ab, sondern bezieht sich
auch auf Aspekte wie Zuverlässigkeit und Leistung.
Die Leistungsmessung und –bewertung von Software ist Thema dieser Seminararbeit.
Neben grundlegenden Definitionen und Einordnung des Leistungsbegriffes in Bezug
auf Software wird besonders auf den Leistungstest eingegangen. Die verschiedenen
Aspekte der Leistungsmessung werden in Bezug auf diesen Test dargestellt und anhand
von Beispielen verdeutlicht. Abschließend wird eine Auswahl einsetzbarer Tools zur
Unterstützung des Mess- und Bewertungsprozesses vorgestellt.
2 Grundlagen der Leistungsmessung- und bewertung
2.1 Leistung als Qualitätsmerkmal
Allgemein ist Qualität definiert als „die Gesamtheit von Eigenschaften und Merkmalen
eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener
Erfordernisse bezieht“ [Ba98, S. 257]. Software-Qualität bezieht sich auf spezielle
Merkmale sowie Eigenschaften eines Software-Produktes und lässt sich durch
vielfältige Qualitätsmodelle beschreiben [z.B. Ba98, S. 257ff]. Häufig genannte
Merkmale sind Funktionalität, Zuverlässigkeit, Benutzbarkeit und Leistung. Wie
einleitend erläutert, bilden hohe Leistung und Zuverlässigkeit eine zentrale Rolle in der
Softwareentwicklung. Die Leistungsanalyse kommt im wesentlichen in zwei
Anwendungsgebieten zum Einsatz. Einerseits wird sie bei Entwurf, Optimierung und
Weiterentwicklung von Software-Systemen eingesetzt, um verschiedene Versionen
3
Kapitel 2: Grundlagen der Leistungsmessung- und bewertung
miteinander vergleichen zu können und Einflüsse ausfindig zu machen, die sich auf die
Leistung auswirken. Zum anderen wird sie bei der Analyse, Auswahl und Konfiguration
einbezogen, damit Software-Systeme anhand standardisierter Tests verglichen und
Entscheidungen bezüglich des Einsatzes getroffen werden können.
2.2 Definition und Kenngrößen von Leistung
Um eine quantitative Leistungsanalyse durchführen zu können, muss der
Leistungsbegriff genauer abgegrenzt und in Leistungskenngrößen untergliedert werden.
Die Analyse bezieht sowohl Prozessoren, Speichersysteme, Netzwerke,
Betriebssysteme und die Software selbst mit in die Bewertung ein, da eine Software
nicht isoliert betrachtet werden kann. Zur konkreten Messung und Bewertung müssen
Kenngrößen in meß- und bewertbare Metriken untergliedert werden [LZ99]. Zur
Definition von Leistung werden die folgenden Kenngrößen [Ba98, S. 538] genauer
erläutert.
Zunächst können verschiedene Arten des Zeitverhaltens unterschieden werden. Die
Kenngröße Zeit wird dazu in messbare Größen unterteilt. Die Bedienzeit beschreibt in
diesem Zusammenhang die Bearbeitungszeit eines Auftrages an einem System oder
einer Stelle der Software. Unter Wartezeit ist die Zeit zu verstehen, die ein Auftrag an
einer Stelle des Systems warten muss, bevor er dort bearbeitet wird. Auch die Summe
aller Wartezeiten eines Auftrages fällt unter diesen Begriff. Die Verweil- oder auch
Antwortzeit beschreibt die Zeitdauer vom Absenden eines Auftrages bis zum Eintreffen
des Resultates. Sie lässt sich auch durch die Summe von Bedien- und Wartezeit
abschätzen. Die reine Rechenzeit ist ein Hardware-bezogenes Leistungsmaß und ist als
die Zeit zu verstehen, die ein Auftrag an einem Prozessor (CPU) verbringt. Alle Zeiten
können dabei in Sekunden, Millisekunden oder weiteren Größeneinheiten gemessen
werden. [MF03, S. 10, Fe03, He94]
Eine weitere Kenngröße von Leistung ist der Durchsatz oder das Volumen. Sie
beschreibt die Datenmengen und Dateigrößen, welche ein Software-Produkt und
Rechnersysteme handhaben und verarbeiten können. Der Durchsatz wird genauer
definiert als die Anzahl von Aufträgen pro Zeiteinheit. Im Laufe der Zeit haben sich
verschiedene Größen etabliert. Beispielhaft sollen hier Million of Instructions Per
Second (MIPS) und Million of Floating-Point-Operations per Second (MFLOPS) zur
Messung von CPU-Durchsätzen, sowie Jobs pro Sekunde bei Batch-Systemen oder Bit
pro Sekunde für die allgemeine Datenübertragung genannt werden [MF03, S. 10].
Weiterhin können Größen wie der Grenzdurchsatz und die Verlustrate betrachtet
werden. Der Grenzdurchsatz beschreibt die maximal erreichbaren Durchsätze oder
anders ausgedrückt, die Anzahl der Aufträge, für welche die Antwortzeit eine
4
Kapitel 2: Grundlagen der Leistungsmessung- und bewertung
bestimmte obere Schranke nicht überschreitet. Als Verlustrate ist die Anzahl der
Aufträge zu verstehen, die pro Zeiteinheit verloren gehen oder abgewiesen werden
[Fe03, S. 14] . Die jeweiligen Maßeinheiten orientieren sich dabei an den zu messenden
Merkmalen der jeweiligen Durchsatzgröße.
Die Auslastung ist eine auf das Gesamtsystem bezogene Leistungskenngröße. Sie stellt
das Verhältnis von tatsächlich erreichtem Durchsatz zum Grenzdurchsatz dar [Fe03].
Unterschieden werden dabei u. a. die Prozessorauslastung, die Systemauslastung und
der Verwaltungsaufwand. Die Prozessorauslastung ist der relative Anteil der Aktivzeit
einer CPU, die zur Bearbeitung von Aufträgen oder Mengen benötigt wird. Die
gewichtete Summe der Auslastungen aller Systemkomponenten wird als
Systemauslastung bezeichnet. Der Verwaltungsaufwand stellt schließlich den relativen
Anteil der Systemprogramme an der CPU-Zeit dar [MF03, S.10; He94].
Eine letzte Kenngröße ist die Verfügbarkeit oder auch Zuverlässigkeit. Damit wird die
Fähigkeit der Software, unter starker Belastung im Grenzbereich zu arbeiten,
ausgedrückt. Zur Feststellung der Zuverlässigkeit wird die Wahrscheinlichkeit für das
Auftreten eines Fehlers in einem bestimmten Zeitintervall, auch als Mean Time
Between Errors (MTBE) bezeichnet, gemessen. Die Verfügbarkeit ist der Zeitanteil, in
dem das System betriebsbereit ist [MF03, S.10]. Die Fehlertoleranz und -behandlung
bei Überlast, Ressourcenausfall oder falscher Eingabedaten wird durch die Robustheit
beschrieben.
Die Leistungsmaße zur Auslastung und zum Durchsatz beschreiben die Leistung
vorwiegend aus der Herstellersicht und werden als Effizienzmaße bezeichnet. Von
Seiten des Kunden oder des Anwenders ist die Effektivität relevanter, welche in den
Kenngrößen zur Zeit und Verfügbarkeit ausgedrückt wird [MF03, S. 6, 11].
Bei der Definition der einzelnen Messgrößen ist sowohl die Wahl einer angemessenen
Skala (Nominal-, Ordinal-, Intervall-, Verhältnis- oder Absolutskala), als auch die je
nach Skala eingeschränkte Auswahl sinnvoller statistischer Operationen zu beachten. So
macht es keinen Sinn, Abstände zwischen Klassen ordinalskalierter Größen zu
interpretieren, oder nominalskalierte Größen zu ordnen. Metriken sollten weiterhin
zuverlässig, sensitiv, gültig und vergleichbar sein, um aussagekräftige Messungen
durchführen zu können [BR03].
2.3 Norm DIN 66273
Die nationale Norm DIN 66273 mit dem Titel „Messung und Bewertung der Leistung
von
DV-Systemen“
beschreibt
ein
Begriffssystem,
sowie
Bewertungs-
und
5
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Messverfahren zur Leistungsanalyse. Dieses standardisierte Lasttestverfahren
ermöglicht es, objektive Aussagen bezüglich des Zeitverhaltens im realistischen Betrieb
eines IT-Systems zu machen. Das zu testende System wird dabei als Black-Box
betrachtet, um die Optimierung von Kennzahlen durch Anpassung der Messverfahren
und Benchmarks auf spezielle innere Funktionen und Eigenschaften der Software zu
vermeiden [He94]. Werden alle Messungen nach den Norm-Vorschriften durchgeführt,
sowie die eingesetzte Hardware und die Benutzerzahlen berücksichtigt, so sind die
Ergebnisse jederzeit reproduzierbar und vergleichbar. Mit Leistungsgrößen wie dem
Durchsatz, dem Antwortzeitverhalten und der Termintreue wird besonders das
Verhalten des Systems an der Benutzerschnittstelle gemessen. Die Leistung, welche im
realen Betrieb erbracht werden kann, wird somit auf realistische Weise eingestuft.
[HU00; Sa02; Sa04].
3 Methoden, Testverfahren und Werkzeuge
3.1 Methoden zur Leistungsbewertung
Die Methoden zur Bewertung von Leistung lassen sich in drei Klassen unterteilen, diese
drei Klassen sind die analytischen Methoden, die Messung und die Simulation. Abb. 3.1
verdeutlicht die Klassifizierung.
Leistungsbewertung
Analytische Modelle
Messung
Simulation
Warteschlangen
Monitoring
Testtools
Petri-Netze
Benchmarking
...
...
...
Abb. 3.1: Methoden zur Leistungsbewertung [MF03, S. 6].
Analytische Modelle
Analytische Modelle versuchen die Leistung eines Systems in Form von Gleichungen
abstrakt zu beschreiben. Der Aufwand und die Kosten, die mit dem Aufbau von realen
Testszenarien verbunden sind, können auf diese Weise vermindert werden. Der Test
von z. B. Multi-User-Systemen und großen Web-Anwendungen mit einer Vielzahl von
zugreifenden Benutzern kann somit wesentlich einfacher durchgeführt werden. Im
6
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Rahmen der analytischen Modellierung kommen Formeln, Petri-Netze und
Warteschlangenmodelle zum Einsatz. Die einzelnen Modellierungsmöglichkeiten
stellen jeweils komplexe mathematische Themengebiete dar. Exemplarisch sollen hier
die Warteschlangenmodelle näher betrachtet werden.
Im einfachsten Fall bestehen solche Modelle aus einer einzigen Warteschlange und
einer Bedieneinheit. In der Warteschlange befinden sich alle Aufträge, die noch nicht
durch die Bedieneinheit bearbeitet wurden. Die Bedieneinheit repräsentiert Prozessoren,
Server oder einzelne Prozesse eines Programms. Abb. 3.2 verdeutlicht den Sachverhalt.
Warteschlange /
Queue
Ankunftsrate
Bedieneinheit
Abarbeitungsrate
Abb. 3.2: Grundmodell M/M/1 Warteschlange.
Neben der Anzahl der Bedieneinheiten und der Größe der Warteschlange müssen die in
Abb. 3.2 dargestellten Ankunfts- und Abarbeitungsraten modelliert werden. Die
Ankunftsrate beschreibt den zeitlichen Abstand zwischen zwei eintreffenden Aufträgen
an der Warteschlange. Die Abarbeitungsrate ist die Bearbeitungsdauer, welche die
Bedieneinheit zur Fertigstellung eines Auftrages benötigt. Die Abarbeitungs- und
Ankunftsraten von Aufträgen sind in diesem Zusammenhang möglichst realistisch im
Modell zu definieren. Dabei kann zwischen stochastischen und deterministischen
Modellen unterschieden werden. Stochastische Modelle bedienen sich an Zufallsgrößen
und können vereinfacht in der Kendall-Notation beschrieben werden. Das in Abb. 3.2
dargestellte M/M/1 Grundmodell besteht nach der Kendall-Notation aus einer
exponential verteilten Ankunftsrate (M), einer exponential verteilten Abarbeitungszeit
(M) und nur einer Bedieneinheit (1). Deterministische Modelle beziehen sich auf
funktionales und zeitliches Verhalten von Systemen im realen Betrieb. Als Beispiel
könnte nun eine Software betrachtet werden, die mehrere Prozesse einsetzt, um
ankommende Aufträge zu Bearbeiten, wie etwa eine Kontoverwaltungssoftware, die
Buchungen und Kontoabfragen bearbeitet. Gelingt eine realistische Modellierung der
Ankunfts- und Abarbeitungsraten, können für ein solches Modell Verkehrsdichten,
Auslastungen sowie Mittel- und Erwartungswerte berechnet werden. Engpässe und
Schwachstellen bezüglich des Leistungsverhaltens können dann schnell lokalisiert
werden.
7
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Messungen
Die Messung als Methode zur Leistungsbewertung wird an vorhandenen Systemen
durchgeführt. Sie dient der konkreten Beurteilung von realen Systemen. Jede Software
läuft auf einer bestimmten Hardware, so dass Messungen nur für eine bestimmte
Kombination von Soft- und Hardware gelten. Bei der Messung gibt es eine
Unterscheidung zwischen Monitoring und Benchmarking. Das Monitoring dient der
Überwachung einer Anwendung im aktiven Betrieb. Zur Laufzeit werden an wichtigen
Punkten im System Messwerte protokolliert, die später überprüft und miteinander
verglichen werden können. Engpässe können auf diese Weise aufgespürt und das
Verhalten des Systems eingeschätzt werden. Überwachungsobjekte könnten z. B.
Antwortzeiten sein. Dazu werden die zu untersuchenden Anwendungen an den
relevanten Stellen instrumentiert, das heißt, es werden Codeanpassungen vorgenommen
oder Kollektoren eingesetzt, welche Zeiten zwischen festgelegten Programmstücken
und Ausführungsschritten messen und protokollieren. Das Benchmarking bedient sich
standardisierter Messprogramme und dient der Erfassung der Leistung eines Systems.
Die Standardisierung ermöglicht einen Vergleich mit ähnlichen Systemen und
Software-Produkten und ist somit eine elementare Voraussetzung. Die in Kap. 2.3
beschriebene DIN ist in diesem Zusammenhang als Rahmenwerk zu sehen, bei dessen
Verwendung eine standardisierte und somit vergleichbare Messung von Leistung
sichergestellt werden kann. Bei jedem Vergleich ist darauf zu achten, dass die
Bedingungen und das Umfeld der Benchmarks bezüglich Hard- und Software identisch
oder sehr ähnlich sind, um aussagekräftige Schlüsse ziehen zu können. Es gibt eine
Vielzahl an Benchmarks, die unterschiedlichste Leistungsmerkmale unterschiedlichster
Komponenten messen. So werden zum Leistungsvergleich von Prozessoren
beispielsweise der Whetstone, Dhrystone oder der SPEC-Benchmark eingesetzt.
Prozessoren müssen im Rahmen dieser Benchmarks unter anderem umfangreiche
Gleitkommaoperationen und komplexe Instruktionen ausführen. Die Leistung von
Datenbanken kann ermittelt werden in dem auf vergleichbarer Hardware bei gleichem
Füllstand der Datenbank z. B. mehrere Millionen Zeilen geschrieben oder ausgelesen
werden [DB04]. Resultierende Antwortzeiten lassen dann auf die jeweilige Performance
schließen. Eine umfangreiche Auflistung verfügbarer Benchmarks für unterschiedliche
Systemkomponenten gibt das Schriftstück [MF03, S. 18]. [Ta02, S. 134]
Simulation
Die Simulation versucht Applikationen, Anwendungsszenarien, Konfigurationen und
Datenbestände real nachzubilden. Wie oben erwähnt ist es oftmals aus Zeit- und
Kostengründen nicht möglich, eine Vielzahl von Benutzern oder Computer in einen
Systemtest einzubeziehen. Ein alleiniger Test am isolierten Einzelplatzsystem könnte
8
Kapitel 3: Methoden, Testverfahren und Werkzeuge
jedoch dazu führen, dass Instabilitäten und Performance-Probleme solange unentdeckt
bleiben, bis die Software im realen Betrieb integriert wird. Durch Simulation besteht die
Möglichkeit, mit Hilfe von Lastgeneratoren und Testwerkzeugen eine realistische
Auslastung zu erzeugen, ohne zu tief in die Gebiete der Mathematik einsteigen zu
müssen [MF03]. Die Messung erfolgt genau und automatisch und wird nach Bedarf
ausgewertet. Sowohl eine tabellarische Übersicht der Ergebnisse im Vergleich mit den
Anforderungen, als auch eine grafische Auswertung, in der Größen wie Auslastung und
Benutzerzahl, oder Auslastung und Datenmenge zueinander in Bezug gesetzt werden,
ist denkbar. Mit der Beschreibung des Leistungstests in Kap. 3.2 und der Beschreibung
unterstützender Werkzeuge in Kap. 3.3 soll im Rahmen dieser Seminararbeit der
Bereich der Simulation exemplarisch genauer erläutert werden.
Bewertung
Sowohl durch den Einsatz analytischer Modelle, als auch durch die Simulation von
Systemen können der Aufwand und die Kosten, die mit dem Aufbau und der
Beobachtung eines realen Testszenarios für Multi-User-Systeme anfallen, stark
reduziert werden. Im Rahmen des Monitoring müsste zur realistischen Einschätzung des
Leistungsverhaltens ein wesentlich höherer Aufwand betrieben werden. Es ist
angemessenen für den Test von Software, die nur durch einen Benutzer genutzt wird.
Die generelle Schwierigkeit beim analytischen Vorgehen besteht in der Formulierung
und Aufstellung der abstrakten mathematischen Modelle. Die Modellierung realistischer
Ankunftsraten und des Benutzerverhaltens stellt sich sowohl beim analytischen Ansatz,
als auch bei der Simulation als problematisch dar. Ist dies jedoch gelungen, kann die
Leistungsbewertung schnell und genau erfolgen.
Als Vorteil des Benchmarking und der Simulation ist weiterhin anzuführen, dass diese
Leistungsbewertungen relativ einfach in der Anwendung sind. Ergebnisse können
jederzeit genau reproduziert werden. Eine identische Abbildung des realen Betriebs
kann allerdings nicht erreicht, sondern nur angenähert werden.
Jede Vorgehensweise besitzt somit Vor- und Nachteile, womit die konkrete Auswahl
von der individuellen Situation und den verfügbaren Ressourcen des Testers abhängig
ist.
3.2 Der Leistungstest
Nachdem in Kap. 3.1 die grundlegenden Methoden zur Messung und Bewertung von
Leistung dargestellt wurden, soll nun der Leistungstest erläutert werden. Ausgehend
von einer Einordnung des Leistungstest werden allgemeine Vorgehensweisen beim
9
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Testen sowie die spezifischen Bestandteile und Funktionsweisen des Leistungstest
dargestellt.
Bereits durch die Betrachtungsweise des zu testenden Objektes können verschiedene
Arten des Testens voneinander abgegrenzt werden. Neben dem White-Box-Test,
welcher interne Abläufe wie Daten- und Kontrollflüsse berücksichtigt, wird der
Leistungstest als Black-Box-Test durchgeführt. Der Leistungstest ist also kein
Strukturtest, sondern dient dem Testen quantifizierbarer Merkmale funktionaler
Anforderungen. Die zu testenden Objekte werden in diesem Zusammenhang „von
außen“ betrachtet [Tr93, S. 197]. Wird von der Betrachtung des Objektes abstrahiert, so
können weiterhin verschiedene Testarten entlang des Softwareentwicklungsprozesses
unterschieden werden. Das V-Modell als eines von vielen Modellen zur Strukturierung
des Entwicklungsprozesses bietet eine übersichtliche Darstellung der anwendbaren
Testarten in den unterschiedlichen Stadien der Softwareerstellung und wird zur besseren
Einordnung des Leistungstests exemplarisch in Abb. 3.3 betrachtet.
Anwendungsszenarien
Anforderungsdefinition
Abnahmetest
Testfälle
Grobentwurf
Feinentwurf
Modulimplementation
Testfälle
Testfälle
Systemtest
Integrationstest
Modultest
Abb. 3.3: Das V-Modell [Al94, S.101; Ba98, S. 101].
Für jede Stufe im Softwareentwicklungsprozess gibt es spezielle Ausprägungen des
Testens. Das dargestellte V-Modell unterscheidet die Teststufen Modultest,
Integrationstest, Systemtest und Abnahmetest. Der Leistungstest ist als ein spezieller
Untertest des Systemtests einzuordnen und erfolgt somit erst am Ende des
Entwicklungsprozesses, nachdem bereits Modul- und Integrationstests durchgeführt
wurden. Neben dem Leistungstest setzt sich der Systemtest aus dem Funktionstest, dem
Benutzbarkeitstest, dem Sicherheitstest und dem Interoperabilitätstest zusammen.
Ziel des Systemtests ist es, nachdem die einzelnen Module der Software per Modultest
und deren Zusammenspiel durch den Integrationstest sichergestellt wurden, das
10
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Gesamtsystem abschließend in der realen Umgebung zu testen. Unter realen
Einsatzbedingungen werden Fehler gesucht und die Anforderungserfüllung überprüft.
Auf diese Weise wird die Software-Qualität für den Endbenutzer sichergestellt. Die
Überprüfung der Leistung nach den in Kap. 2.2 definierten Kriterien ist Aufgabe des
Leistungstest. Als Basis für den System- und damit auch für den Leistungstest dient die
Produktdefinition, wobei insbesondere im Pflichtenheft wichtige Qualitätsziele
festgelegt sein sollten. Wie Abb. 3.3 zeigt, sind somit bereits aus dem Grobentwurf
einzelne Testfälle abzuleiten. Neben der Überprüfung der
ist auch eine Anwendung der Leistungsmessung
Softwareentwicklungsprozesses denkbar, beispielsweise
spätere Leistung kann dann frühzeitig abgeschätzt
Leistung des Gesamtsystems
in früheren Phasen des
auf der Modulebene. Die
und Handlungen
bzw.
Optimierungen eingeleitet werden [Ba98, S. 537ff].
Vorgehensweise beim Testen
Ein Vorgehensmodell für den Leistungstest lässt sich aus dem allgemeinen Vorgehen
beim Test von Software ableiten. In verkürzter Form ergeben sich die Phasen
Testplanung, Testvorbereitung, Durchführung und Auswertung [Tr93, S.196].
Die Testplanung beschäftigt sich mit Aspekten der Festlegung von Zeitplänen,
Werkzeugen, Verantwortlichkeiten und Zielen. Zur Festlegung der Ziele des
Leistungstests sind Qualitätsmerkmale, wie in Kap. 2.2 erläutert, auf meß- und
bewertbare Kenngrößen herunter zu brechen. Die Verantwortlichkeit obliegt den
Qualitätssicherern und Software-Entwicklern [Ba03].
In der Testvorbereitung werden Hard- und Software festgelegt und konfiguriert,
Testfälle entwickelt, sowie Testdaten generiert. Die Ableitung der Konfiguration und
der Testfälle für den Leistungstest ist dem Pflichtenheft zu entnehmen.
Die Durchführung kann auf Grund der Komplexität und des Zeitaufwandes nur mit
Hilfe von Testtools effizient durchgeführt werden. Besonders bei Multi-User-Systemen
und komplexen Datenbeständen ist eine Simulation und automatische
Testdatengenerierung durch Tools und Test-Treiber notwendig. Einzelne Testtools
werden in Kap 3.3 aufgeführt [Ba98].
Wurden alle Testfälle in Testläufen durchgeführt und dokumentiert, so kann der Test
ausgewertet werden. Dabei werden die Ergebnisse mit den erwarteten Werten
verglichen und nach Bedarf verdichtet, sowie Fehlermöglichkeiten bei negativen
Abweichungen identifiziert.
11
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Elemente des Leistungstests
Der Leistungstest selbst lässt sich in vier weitere Tests untergliedern. Unter diesen
Oberbegriff lassen sich der Massen-, der Zeit-, der Last- und der Stresstest unterordnen.
Die einzelnen Tests werden im Folgenden genauer dargestellt.
Massen- / Volumentest
Der Massen- oder auch Volumentest dient der Überprüfung des Verhaltens der Software
bei der Verarbeitung großer Datenmengen. Während im Laufe der Entwicklung nur
geringe Datenmengen für den Test zum Einsatz kommen, werden die SoftwareProdukte im realen Betrieb oftmals enormen Datenmengen ausgesetzt. Im Pflichtenheft
und der Produktbeschreibung finden sich oft spezielle Anforderungen. Dieser Test soll
sicherstellen, dass auch ein stark ausgelastetes System beim Ausführen von
Funktionssequenzen ein normales bzw. ein gefordertes Verhalten zeigt. Unerwartete
Probleme im laufenden Betrieb, sowie Abstürze und Instabilitäten sollen so aufgedeckt
werden [Nf03].
Eine zentrale Aufgabe beim Durchführen des Massentests ist die Bereitstellung der
großen Datenmengen. Eine manuelle Erfassung oder Eingabe der Daten in das System
ist sehr zeitaufwendig und damit teuer. Um das Personal nicht unnötig zu belasten und
um die Kosten zu senken, können entweder reale Daten vom Auftraggeber, oder
Testdatengeneratoren eingesetzt werden. Der Begriff Daten ist dabei sehr weit gefasst
und umschreibt sowohl verschiedenste Dateiarten wie ZIP-Dateien, PDF-Dokumente,
selbst definierte Formate etc., als auch Datensätze mit bestimmten Attributen in
Datenbanken.
Werden die Daten vom Auftraggeber geliefert, sind diese über entsprechende
Importschnittstellen des Software-Produktes in das System einzupflegen. Die
Importschnittstelle muss die realen Daten entgegennehmen und in das von der Software
benötigte Format konvertieren können. Der Vorteil dieser Vorgehensweise liegt auf der
Hand. Es kann mit realen Daten gearbeitet werden, die später auch im Betrieb mit der
Software verwendet würden. Jedoch ist die Beschaffung problematisch. Entweder
verfügen die Auftraggeber selbst noch nicht über entsprechende Datenmengen, oder es
ist ihnen aus datenschutzrechtlichen Gründen untersagt, diese preiszugeben.
Eine weitere Möglichkeit zur Erzeugung der Datenmengen sind Testdatengeneratoren.
Diese Tools können entweder selber programmiert werden, oder aber, sollte der
Aufwand zu hoch und nicht gerechtfertigt sein, am Markt beschafft werden.
Entsprechend konfiguriert, erzeugen solche Generatoren die gewünschten Datenmengen
im vorgegebenen Format. Vorteilhaft ist die Effizienz dieses Vorgehens. Daten werden
12
Kapitel 3: Methoden, Testverfahren und Werkzeuge
schnell, in großen Mengen, vor Ort und in gewünschten Formaten erstellt. Als Nachteil
wäre aufzuführen, dass es sich nicht um reale Daten handelt und keine 100%ige
Übereinstimmung mit diesen garantiert werden kann. Bei leicht abweichenden Daten im
realen Betrieb können also durchaus noch unerwartete Probleme auftreten. Es werden
also hohe Anforderungen an die Qualität der erzeugten Daten gestellt [Ba98, S. 539].
Einige kurze Beispiele sollen die Anwendungsmöglichkeit des Massentests
verdeutlichen. So könnte eine Anforderung im Pflichtenheft eines Software-Produktes
zur Verwaltung von Studenten und Vorlesungen lauten, dass maximal 100.000
Studenten und 5.000 Vorlesungen verwaltet werden sollen. Im Zuge des Massentests ist
es erforderlich, die maximal geforderten Datenmengen auch wirklich in das System
einzupflegen. Die Funktionsfähigkeit und Leistungsfähigkeit muss bei dieser Belastung
gewährleistet werden können, um den geforderten Pflichten gerecht zu werden. Auch
die Auffüllung von Warteschlangen für abzuarbeitende Aufträge kann im Rahmen des
Massentests getestet werden. Ist gefordert, dass an einem Server mindestens 10
Aufträge in einer Warteschlange gespeichert werden sollen bevor der erste verworfen
wird, so sollte das korrekte Verhalten durch entsprechende Generierung von Testdaten
überprüft werden [My91]. Bei der Speicherung von Daten auf Massenmedien kann das
Verhalten bei Überfüllung der Massenmedien getestet werden. Ist ein Massenspeicher
voll, so sollte dies nicht zum Absturz der Anwendung führen, sondern zum
automatischen Wechsel des Mediums, oder aber zu einer adäquaten Fehlermeldung.
Das korrekte Verhalten ist dabei wiederum durch einen Massentest überprüfbar [My91].
Zeittest
Beim Zeittest soll das Zeitverhalten als Leistungsmerkmal eines Software-Produktes
überprüft werden. Das Zeitverhalten bzw. die Zeitanforderungen sind dem Pflichtenheft
zu entnehmen. Die einzelnen Anforderungen können sich auf das Antwortzeitverhalten
und die Durchsatzraten des Software-Produktes bei normaler Arbeitslast und
Konfiguration beziehen. Als Synonym für diesen Test wird auch der Begriff
Performance-Test verwendet [My91; Al94].
Besonderes Augenmerk ist auf eine möglichst realistische Simulation der realen
Auslastung bezüglich Anzahl der Benutzer, Datenmengen, Netzwerkverkehr etc. zu
richten. Arbeiten im laufenden Betrieb mehrere Personen gleichzeitig mit einer
Software, so wird diese folglich stärker beansprucht. Jeder Benutzer wiederum hat ein
eigenes Arbeitsverhalten, eine individuelle Denkzeit und gibt Befehle in anderer
Reihenfolge ein. Ähnliche Überlegungen sind für parallel durch den Benutzer
ausgeführte Anwendungen zu machen, welche die Leistung der Software beeinflussen
könnten. Eine realitätsnahe Situation zu erzeugen ist eine komplexe und schwierige
13
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Aufgabe. Die in Kap. 3.3 vorgestellten Werkzeuge geben dem Tester dazu
weitreichende Hilfestellungen. Die Test-Treiber und Tools bedienen sich dabei an
Zufallskomponenten und Streuungen, um das Verhalten der Benutzer, den
Netzwerkverkehr etc. möglichst realistisch nachzubilden. Mittelwerte für Denkzeiten
und entsprechende Varianzen können dabei verschiedenste Benutzergruppen und
Situationen simulieren. Zudem übernehmen die Test-Treiber gleichzeitig die Messung
der entsprechenden Antwortzeiten und des Durchsatzes [HU00].
Auch für die Entwicklung von Testfällen zum Zeitverhalten lassen sich die notwendigen
Informationen aus dem Pflichtenheft einer Software entnehmen. So könnte eine
Anforderung eines Flugbuchungssystems lauten, dass die Antwortzeit für Buchungen in
40% der Fälle nicht schlechter als 5 Sekunden, in 80% der Fälle nicht schlechter als 15
Sekunden und nie schlechter als 30 Sekunden sein dürfen. Um solche
Wahrscheinlichkeiten garantieren zu können, müssen große Mengen passender
Buchungsdaten bzw. Datensätze generiert werden, mit denen das Buchungssystem
konfrontiert werden kann. Für jede Buchung wird dann die Zeit gemessen und
festgehalten. Durch umfangreiche Testreihen können dann aussagekräftige Statistiken
gewonnen werden [HU00]. Zur übersichtlichen Darstellung der Ergebnisse können
tabellarische Auswertungen verwendet werden. Sie enthalten die Funktionsnamen,
maximal erlaubte Antwortzeiten und gemessene Antwortzeiten. Die Überprüfung des
Zeitverhaltens sollte mit den maximal erlaubten Datenmengen aus dem Massentest
durchgeführt werden. So kann gewährleistet werden, dass die Zeiten auch bei höherer
Auslastung des Gesamtsystems noch garantiert sind.
Lasttest
Die Sicherstellung der Leistungsfähigkeit im erlaubten Grenzbereich des SoftwareProduktes soll der Lasttest gewährleisten. Insbesondere die Leistungsmerkmale
Zuverlässigkeit und Robustheit werden auf diese Weise geprüft. Der Unterschied zum
Zeittest besteht darin, dass nicht etwa eine normale Arbeitssituation vorausgesetzt wird,
sondern das System bezüglich Benutzeranzahl, Datenmengen, Netzwerkverkehr etc. an
seinen Anforderungsgrenzen betrieben wird. Auch bei starker Auslastung sollen
Antwortzeiten und Durchsatzraten möglichst innerhalb eines akzeptablen Bereiches
liegen.
Auch für diesen Test ist eine möglichst realistische Nachbildung der Arbeitssituation
des Software-Produktes nötig. Wie bereits beim Zeittest können Test-Treiber und Tools
zur Hilfe eingesetzt werden, welche die zu prüfenden Situationen mit den geforderten
Konfigurationen und Belastungen simulieren. Tools, wie der S_aturn Lasttreiber,
ermöglichen komfortable Einstellungsmöglichkeiten einer geforderten Last. Auch hier
14
Kapitel 3: Methoden, Testverfahren und Werkzeuge
ist es wichtig, die Konfiguration der Test-Treiber sehr genau zu planen und
durchzuführen, um einen hohen Grad an Realismus zu gewährleisten.
Neben der Prüfung des Software-Produktes im Grenzbereich werden beim Lasttest
Situationen getestet. So gilt es im Rahmen der Robustheit zu kontrollieren, wie das
Produkt auf unerwartete, im falschen Format vorliegende Daten, z. B. an den
Importschnittstellen, reagiert. Auch die Reaktion auf den Ausfall oder die
Nichtverfügbarkeit bestimmter Soft- und Hardwarekomponenten sind zu prüfen.
Systemzusammenbrüche, unverständliche Fehlermeldungen und Endlos-Antwortzeiten
sind auf diese Weise zu lokalisieren und zu eliminieren [Ba98; HU00; My91].
Beispiele für den Lasttest lassen sich wiederum aus den Anforderungen im Pflichtenheft
ableiten. Ist festgelegt, dass das System auch noch arbeitsfähig sein soll, wenn ein
bestimmtes Modul ausfällt oder stark belastet wird, so gilt es, dies mit dem Lasttest zu
überprüfen. Soll eine Buchhaltungssoftware auf Rechnungsdateien zugreifen und diese
auslesen, so könnte überprüft werden, wie sich das System verhält, wenn die Dateien
sehr groß oder gar nicht vorhanden sind. Angemessene Fehlermeldungen sollten
Benutzer auf die Situation hinweisen und Abstürze vermieden werden [Ba98]. Auch die
Überprüfung der Funktionsfähigkeit bei überdurchschnittlicher Prozessor- oder
Netzwerkauslastung können Elemente des Lasttests sein. Mit Hilfe von Werkzeugen,
wie dem in Kap 3.3 vorgestellten S_aturn Lasttreiber [Sa04], können entsprechende
Situationen definiert, überprüft und ausgewertet werden.
Stresstest
Der letzte Teiltest des Leistungstest ist der Stresstest. Im Vergleich zum Lasttest werden
dabei die Belastungsgrenzen des Software-Produktes bewusst überschritten. Auf diese
Weise soll die Zuverlässigkeit und vor allem die Robustheit in Extremfällen geprüft
werden. Es können im Rahmen dieses Tests bestimmte Ressourcen entzogen,
Benutzerzahlen über die maximal mögliche gesteigert, sowie unnötig große
Datenmengen eingesetzt werden.
Dieser Test kann nur durch den Einsatz von Test-Treibern und Tools effizient realisiert
werden. Können einzelne Module noch einzeln abgeschaltet und Ressourcen entzogen
werden, so ist die Simulation einer großen Benutzerzahl und die Generierung von
großen Datenmengen nur durch Tool-Unterstützung sinnvoll lösbar [Al94; Ba98]. Die
Last des Systems wird dabei schrittweise gesteigert, bis es zu Abstürzen oder
Fehlfunktionen kommt. Auf diese Weise können lastabhängige Fehler wie Race
Conditions oder Deadlocks aufgefunden werden [Gö01].
15
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Die Anforderungen aus dem Pflichtenheft sind im Rahmen des Stresstests bewusst zu
überschreiten. Ist z. B. für die Studentenverwaltung festgelegt worden, dass sie maximal
100.000 Studenten und 5.000 Vorlesungen handhaben können sollte, muss das System
weitaus größeren Datenvolumen ausgesetzt werden [Ba98]. Auch Multi-User-Systeme
können mit mehr Benutzern als maximal vorgesehen betrieben werden, um Änderungen
des Antwortzeit- und Leistungsverhaltens des Systems in Extremfällen zu überprüfen
und eventuell zu verbessern [Ta02]. Um Web-Anwendungen zu testen, können Zeiten
zwischen Transaktionen gekürzt werden, das heißt, die Bedenkzeit der Benutzer wird
ignoriert, um die Belastung zu erhöhen. So kann die maximale Anzahl an Anfragen, die
eine Web-Applikation in einer bestimmten Zeit bewältigen kann, und der Punkt, an dem
die Applikation zusammenbricht, festgestellt werden. Tools wie OpenSTA in Kap. 3.3
oder das Microsoft Web Application Stress Tool (WAS) [Ms04] unterstützen eine
leichte Simulation einer beliebigen Anzahl von Benutzern. Anwender können somit
durch den Entwickler vor gefährlichen Situationen im realen Betrieb gewarnt und die
Grenzen der Software genau ausgetestet werden.
3.3 Testtools
Merkmal / Produkt
S_aturn
RUBIS
OpenSTA
Weitere...
Testbarer
Multi-User-System, Internetauktion
Webanwendung
Datenbanken,
Anwendungstyp
Webanwendung,
Webanwendungen,
Netzwerk
Arbeitsplatzsoftware,
Netzwerk,...
Ja
Individuelles
eingeschränkt
Ja
unterschiedlich
Benutzerverhalten
einstellbar
Auswertung
Grafiken, Tabellen, Grafiken, Tabellen, Grafiken, Tabellen, Grafiken, Tabellen,
Protokolldateien
Protokolldateien
Protokolldateien
Protokolldateien,...
Tabelle 1: Übersicht der Merkmale unterschiedlicher Testtools.
Im letzten Teil dieser Seminararbeit werden drei Werkzeuge zur Unterstützung des
Leistungstestprozesses exemplarisch dargestellt. Auf dem Markt existiert eine Vielzahl
an Tools zur Messung von Leistung, deren vollständige Vorstellung hier zu
umfangreich ist [Pt04]. Es werden jedoch ähnliche Grundfunktionen bereitgestellt, so
dass die Beschränkung auf den S_aturn Lasttreiber, das Rice-University-BiddingSystem (RUBIS) Projekt und OpenSTA ausreichend ist. Erst sie ermöglichen einen
16
Kapitel 3: Methoden, Testverfahren und Werkzeuge
kosten- und zeiteffizienten Test von Software. Tabelle 1 gibt eine Übersicht über die
Merkmale der einzelnen vorgestellten Testtools.
S_aturn Lasttreiber
Der Lasttreiber soll überprüfen, inwieweit die Leistung eines zu vermessenden Systems
bei geforderten Belastungen den Anforderungen aus z. B. dem Pflichtenheft genügt. Die
Messungen werden streng nach der DIN 66273 durchgeführt, so dass sie sowohl
reproduzierbar, vergleichbar, als auch durch den Endnutzer selbst nachvollziehbar sind.
Durch Simulation können mit S_aturn vor allem Client / Server Systeme, verteilte
Anwendungen und Multi-User-Systeme getestet werden. Realistische Testszenarien
können durch anpassbare Benutzerzahlen, Benutzerverhalten und Auslastungen
definiert und modelliert werden. Die Messung erfolgt dann nach standardisierten
Kriterien. In der Auswertung können verschiedene Analysen und Korrelationen
betrachtet werden [HU00; Sa04].
S_aturn sieht das zu testende System als Black-Box an und erfordert keine Änderungen
des Codes zur Durchführung von Messreihen. Zu diesem Zweck werden die
Arbeitsschritte der Benutzer eines Systems simuliert. Die Anzahl der Benutzer kann
dabei in die Tausend gehen, wobei Anwendungsprofile, Benutzerverhalten und
individuelle Eingaben genau festgelegt werden können. Die einzelnen Aufträge, die
dem System durch die simulierten Benutzer übergeben werden, werden durch
Manuskripte mit den notwendigen Tastatureingaben definiert. Sie beschreiben die
Eingaben an der Benutzerschnittstelle. Dazu können Zeitvorgaben für das
Benutzerverhalten ergänzt werden, welche das Warten auf Ergebnisse am Bildschirm,
Denkpausen, Arbeitspausen oder andere Tätigkeiten simulieren. Zur Vereinfachung
können Benutzergruppen gebildet werden, die gleichartige Aufträge senden und
gleichartiges Zeitverhalten an den Tag legen. Um nicht alle Aufträge synchron in der
gleichen Reihenfolge zu senden, wird die Auftragsreihenfolge zufällig gemischt. Dazu
sind Mittelwerte und Streuungen anzugeben. Die Tatsache, dass manche Aufträge nur in
einer bestimmten Reihenfolge ausgeführt werden können, wird durch die Bildung von
Auftragsketten berücksichtigt. Beobachtungsfunktionen ermöglichen zur Vereinfachung
der Festlegung des Benutzerverhaltens auch die Aufzeichnung der Arbeitsvorgänge
realer Benutzer, welche dann einfach vervielfältigt werden kann. Das Testtool selber
läuft als Multithreaded-Multiuser-Applikation auf einem Unix- oder Linux-System. Es
simuliert die oben beschriebenen Benutzer mit ihren spezifischen Verhaltensweisen
und sendet die Anfragen der simulierten Benutzer an das zu testende Zielsystem. Zur
Kommunikation mit dem Zielsystem wird auf TCP/IP und Standarddienste oder
Client/Server-Protokolle zurückgegriffen. Der Testreiber wird dazu über ein Netzwerk
mit dem Testobjekt verbunden [Sa02].
17
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Während der Messung wird für jeden Benutzer ein Recordfile erzeugt, das sowohl die
Datenströme zum und vom System, als auch dazugehörige Zeitstempel enthält. Danach
können Größen zur Leistungsbewertung, wie z. B. Durchsatz, Termintreue oder
Antwortzeiten, ausgewertet und dargestellt werden. Neben der Darstellung in Tabellen,
können Zusammenhänge und Korrelationen grafisch abgebildet werden. Je nach Bedarf
können die ermittelten Größen dazu in Relation gebracht werden. Weitere Größen
dienen der Überprüfung der statistischen Qualität der Messungen, dies beinhaltet ob alle
Mittelwerte eingehalten, Auftragsketten richtig ausgeführt und Denkzeiten eingehalten
worden sind.
RUBIS Project
Das Rice-University-Bidding-System (RUBIS) Projekt [RU04] ist ein Werkzeug,
welches den Anwender dabei unterstützt, Web-Anwendungen auf ihr
Leistungsverhalten zu untersuchen. Dabei stehen Auktionsseiten im Stile von Ebay im
Fokus des Projektes. Ziel ist es, das Leistungsverhalten der zu testenden Website im
Sinne eines Benchmarks zu messen, um Verbesserungsmöglichkeiten im
Anwendungsdesign und der Server-Wahl aufzuzeigen.
Der Benchmark simuliert zu diesem Zwecke unterschiedliches Benutzerverhalten beim
Nutzen der Hauptfunktionalitäten einer Auktionsseite. Dazu gehören Funktionen wie
das Bieten, das Verkaufen, sowie das Suchen und Sortieren von Gegenständen nach
Kategorie, Name oder Region. Auch können Kommentare hinterlassen, die Bewertung
von Benutzern vorgenommen, sowie die Gebotsverläufe verschiedener Auktionen
eingesehen werden. Es können drei verschiedene Benutzer-Sessions unterschieden
werden. Besucher-Sessions bedürfen keiner Registrierung und können lediglich
innerhalb der Seiten der Anwendung Suchen und Browsen. Käufer- und VerkäuferSessions sind nur für simulierte Benutzer möglich, die in der Datenbank registriert sind.
Sie können die weiteren, oben aufgeführten Funktionen nutzen, wie z. B. Gegenstände
kaufen oder verkaufen. Jeder simulierte Benutzer führt seine Interaktionen dabei in
einer zufälligen Reihenfolge aus, die durch eine Zustands-Übergangs-Matrix festgelegt
wird. Denk- und Wartezeiten zwischen den einzelnen Interaktionen werden über eine
Negativ-Exponential-Verteilung ermittelt. Die Anzahl der registrierten Benutzer kann
über eine Million betragen. Zur realistischen Simulation der Server-Belastungen können
weiterhin zwei verschiedene Arbeitslasten definiert werden. Der so genannte BrowsingMix simuliert Nutzer, die lediglich Informationen abrufen und über die Seiten surfen.
Der Gebots-Mix enthält 15% Transaktionen, die einen schreibenden Zugriff auf die
hinterlegte Datenbank erfordern. Die Datenbank besteht aus 7 Tabellen, welche unter
anderem 33.000 zum Verkauf angebotene Gegenstände, 500.000 abgelaufene
Auktionen, über 330.000 Gebote und ca. eine Million registrierte Benutzer enthält. Die
18
Kapitel 3: Methoden, Testverfahren und Werkzeuge
Kommunikation wird über persistente HTTP-Verbindungen realisiert, die jeder
simulierte Nutzer am Server öffnet. Der Benchmark selbst ist in den Technologien PHP,
Java Servlets und EJB erhältlich. Um die Leistung der verschiedenen Technologien
vergleichen zu können, werden jeweils die gleichen SQL-Anfragen verwendet [RU04].
Nach der Durchführung ausreichender Messungen können die gewonnenen Daten
analysiert werden. Größen wie der Durchsatz oder die CPU-Auslastung können in
Zusammenhang mit der Benutzer- und Transaktionszahl grafisch oder tabellarisch
dargestellt werden [Ce03].
OpenSTA
Ein Tool zum Testen allgemeiner Web-Anwendungen wird durch das Open-SourceProdukt Open-System-Testing-Architecture (OpenSTA) [OS04] angeboten. Dieses
Werkzeug wurde speziell zur Messung des Leistungsverhaltens entwickelt und kann,
wie die oben beschriebenen Tools, ebenfalls Benutzer simulieren und realistische
Lasten erzeugen. Grundlage von OpenSTA stellt eine CORBA-Architektur dar [Kl03].
Zur Simulation von Benutzerverhalten werden Skripte eingesetzt, welche die jeweilige
Vorgehensweise eines Benutzer beschreiben. Sie enthalten Informationen über die
gemachten Eingaben, die Wartezeiten und das Navigationsverhalten. Erzeugt werden
die Skripte durch das Aufzeichnen des Verhaltens eines realen Benutzers an seinem
Internetbrowser oder direkt über die Script-Control-Language (SCL). Bei einer
Aufzeichnung des Verhaltens liest ein Skripteditor alle HTTP-Daten, die vom Browser
während einer „Muster-Session“ gesendet und empfangen werden mit und protokolliert
die Wartezeiten, welche z. B. für die benötigte Zeit zum Ausfüllen eines Formulars
einer Internetseite stehen könnten. Ein solches Skript kann dann beliebig modifiziert
und vervielfältigt werden, um eine Vielzahl von Benutzern mit unterschiedlichem
Verhalten zu simulieren.
Während des Tests werden eine Vielzahl von Ergebnissen und Messwerten gesammelt,
die eine umfassende Analyse des Leistungsverhaltens ermöglichen. Neben Timern zur
Messung von Antwort- und Bearbeitungszeiten, die selber in entsprechende Skripte
integriert werden können, gibt es Möglichkeiten, Daten des Simple Network
Management Protocol (SNMP) oder des Windows-Leistungs-Monitors zu
protokollieren. Dabei wird auch die direkte Verfolgung der Messung durch MonitoringProzesse unterstützt. Alle während des Tests gesammelten Daten werden zur
Auswertung in Dateien abgespeichert und können später grafisch ausgegeben oder zur
weiteren Analyse mit Tabellenkalkulationsprogrammen als CSV-Dateien exportiert
werden [Bi04].
19
Kapitel 4: Relevanz der Leistungsüberprüfung
4 Relevanz der Leistungsüberprüfung
Die Qualitätsanforderungen an Software-Systeme steigen mit der zunehmenden
Verbreitung und dem Einsatz von Software zur Unterstützung verantwortungsvoller
Aufgaben immer weiter an. Die Überprüfung und Gewährleistung von SoftwareQualität stellt somit eine wichtige Komponente des Software-Entwicklungsprozesses
dar.
Als ein wichtiges Qualitätsmerkmal wird im Rahmen dieser Arbeit die Leistung
herausgestellt. Um Leistung messen zu können, wird eine Aufteilung in Kenngrößen
wie die Antwortzeit, den Durchsatz oder die Auslastung vorgenommen. Die einzelnen
Kenngrößen können durch verschiedene Methoden der Leistungsbewertung erfasst
werden.
Mit den analytischen Modellen, der direkten Messung und der Simulation stehen drei
grundsätzliche Methoden zur Leistungsbewertung zur Verfügung. Die Auswahl einer
konkreten Methode kann durch einen Aufwand / Nutzen Vergleich durchgeführt
werden. Die ausführliche Betrachtung des Leistungstest und einiger ihn unterstützender
Testtools hat den Schwerpunkt dieser Arbeit auf den Bereich der Simulation gelegt.
Der Leistungstest als Untertest des Systemtests ist allein als eine von vielen
notwendigen Überprüfungen während der Software-Entwicklung anzusehen. Da das zu
testende System lediglich als Black-Box betrachtet wird, sind weitere
Qualitätsüberprüfungen auf Modulebene mit genauem Bezug auf interne
Programmverläufe im Zuge der Qualitätssicherung unabdingbar.
20
5 Literaturverzeichnis
[Al94]
Alper, M.: Professionelle Softwaretests. Praxis der Qualitätsoptimierung
kommerzieller Software. Braunschweig 1994.
[Ba03]
Balzert, H.: Software-Qualitätssicherung. 6 Produktqualität–Systeme:
System- und Abnahmetest. 2003. http://www.inf.fu-berlin.de/inst/agse/teaching/V-SWT-2003/66_2LE_19tw.pdf. Abrufdatum 19.03.2004.
[Ba98]
Balzert, H.: Lehrbuch der Software-Technik. Band 2. Heidelberg u. a. 1998.
[Bi04]
Bisson, S.: Saving software in distress.
http://www.appdevadvisor.co.uk/Downloads/ADA7_1/Bisson7_1.pdf.
Abrufdatum 15.03.2004.
[BR03]
Bennicke, M.; Rust, H.: Software-Produktanalyse. 2003. http://wwwsst.informatik.tu-cottbus.de/~db/doc/SoftwareEngineering/SoftwareProduktanalyse_Metriken_QA.pdf. Abrufdatum 19.03.2004.
[Ce03]
Cecchet, E. et. al.: Performance Comparison of Middleware Architectures
for Generating Dynamic Web Content. 2003.
http://rubis.objectweb.org/download/Middleware-2003.pdf. Abrufdatum
15.03.2004.
[DB04]
o. V.: Die MySQL-Benchmark-Suite. 2004.
http://www.mysql.de/doc/de/MySQL_Benchmarks.html. Abrufdatum
15.03.2004.
[Fe03]
Fey, D.: Leistungsbewertung. 2003. http://www2.informatik.unijena.de/~fey/ra1ws03/folien/ra1_kap5_1bis36.pdf. Abrufdatum 15.03.2004.
[Fr97]
Frühauf, K.; Ludewig, J.; Sandmayr, H.: Software-Prüfung. Eine Anleitung
zum Test und zur Inspektion. Zürich 1997.
[Gö01]
Göschel, S.: Testen verteilter Applikationen. Eine Einführung. 2001.
http://www.javausergroup.at/events/testDistrib.pdf. Abrufdatum 15.03.2004.
[He94]
Hennessy, J.; Patterson, D.: Rechnerarchitektur. Analyse, Entwurf,
Implementierung, Bewertung. San Mateo 1994.
[HU00]
Huber, M.; Ultsch, H.: Performance-Untersuchung mit dem Lasttreiber
s_aturn nach DIN 66273 / ISO 14756. 2000. http://www-wi.cs.unimagdeburg.de/pe2000/papers/ultsch.pdf. Abrufdatum 19.03.2004.
[Kl03]
Klosterberg, M.: EXCELSIS Open Source Testfactory – Kosten senken,
Qualität steigern. 2003.
http://www.excelsisnet.com/opencms/opencms/system/galleries/download/
whitepapers_pdf/WP_OpenSourceTestfactory.pdf. Abrufdatum 15.03.2004.
[LZ99]
o. V.: Bewertung der Leistung und Zuverlässigkeit. 1999.
http://www3.informatik.unierlangen.de/Lehre/OTRS_I/WS1999/folien/OTR16H.pdf. Abrufdatum
19.03.2004.
[MF03]
Müller-Clostermann, B.; Flüs, C.: Kapazitätsplanung und
Leistungsbewertung. 2003. http://www.icb.uniessen.de/SysMod/lehre/CapPlan/CapPDF/CapPlanB_2003.pdf. Abrufdatum
15.03.2004.
[Ms04]
o. V.: MS Web Application Stress Tool. 2004.
http://www.microsoft.com/technet/itsolutions/intranet/downloads/webstres.
mspx. Abrufdatum 15.03.2004.
[My91]
Myers, G.: Methodisches Testen von Programmen. 4. Aufl., München 1991.
[Nf03]
o. V.: Nicht-funktionale Testmethoden. 2003.
http://qse.ifs.tuwien.ac.at/courses/QS/ws0304/10S_Nonfunkt_wid_2003112
6.pdf. Abrufdatum 20.03.2004.
[OS04]
o. V.: Open System Testing Architecure - OpenSTA. 2004.
http://www.opensta.org/. Abrufdatum 15.03.2004.
[Pt04]
o. V.: Performance test tools.
http://www.opensourcetesting.org/performance.php. Abrufdatum
15.03.2004.
[RU04]
o. V.: RUBiS Rice University Bidding System. 2004.
http://rubis.objectweb.org/. Abrufdatum 18.03.2004.
[Sa02]
Zott + Co GmbhH: s_aturn-Report Lasttest im Internet. 2002.
http://www.zott.net/z-doc_de_demo_testbericht.pdf. Abrufdatum
15.03.2004.
[Sa04]
Zott + Co GmbhH : s_aturn 8000. Der professionelle Performance- und
Lasttest. http://www.zott.net/doc/z-wp_de-saturn.pdf. Abrufdatum
15.03.2004.
[Ta02]
Thaller, E.: Software-Test. Verifikation und Validation. Hannover 2002.
[Tr93]
Trauboth, H.: Software-Qualitätssicherung. Konstruktive und analytische
Maßnahmen. München u. a. 1993.