Lasttest (Computer)

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Unter einem Lasttest (Lehnübersetzung von Load Testing) versteht man einen Softwaretest, der eine in der Regel sehr hohe Last auf dem zu testenden System erzeugt und dessen Verhalten untersucht. Dazu kann eine Simulation eingesetzt werden. Ziel ist

  1. die Aufdeckung im funktional orientierten Systemtest/Integrationstest nicht gefundener Fehler,
  2. Erfüllung nichtfunktionaler Anforderungen, wie z. B. geforderte Antwortzeiten sowie Mengenverarbeitungen, für den Produktivbetrieb nachzuweisen.
  3. Die Dimensionierung der Hardwareausstattung zu überprüfen.

Der Lasttest ist demnach dem funktionalen Test nachgelagert, d. h. das (Teil-)System muss in einem funktional stabilen Zustand sein, um überhaupt auf Lastbewältigung getestet werden zu können.

Ausprägungen[Bearbeiten | Quelltext bearbeiten]

Die Last kann darin bestehen, dass Funktionen sehr schnell hintereinander ausgeführt werden, oder dass parallele Aktivitäten von virtuellen Benutzern (Multiuser, vUser) ausgeführt werden. In der Regel wird dabei direkt auf Protokollebene (Netzwerkprotokoll) gearbeitet.

Grundsätzlich lässt sich unterscheiden zwischen (1) Performancemessungen und (2) Lasttests. Performancemessungen wiederholen ausgewählte Testfälle bzw. Einzelprozesse aus dem Systemtest unter einer Grundlast: dadurch werden einzelne Funktionen auf ihre Performanzeigenschaften geprüft, d. h. sämtliche User führen den gleichen Prozess aus, wodurch die Skalierbarkeit für die Einzelfunktion(en) getestet wird. Man spricht in dem Zusammenhang auch von Transaktionen. Lasttests im engeren Sinne testen gesamte Prozessketten sowie den Prozessmix auf Performanz, d. h. die Verknüpfungen der Einzelprozesse; damit simulieren sie konkrete Vorgänge aus dem tatsächlichen Wirkbetrieb und stellen einen nicht zu unterschätzenden Schritt zur Erreichung der Wirkbetriebstauglichkeit dar. Auch hier ist die Skalierbarkeit von entscheidender Bedeutung, jedoch jetzt für den gesamten Prozessmix. Eine dabei häufige auftretende Fehlerwirkung sind Deadlocks beim Datenbankzugriff, die sonst nur schwer testbar sind.

Wird das System bewusst über die definierte Lastgrenze hinaus beansprucht, spricht man vom Stresstest. Dabei sollte die Last (Anzahl der virtuellen User) schrittweise bis über die definierte Lastgrenze hinaus erhöht werden.

Damit werden folgende Fragestellungen untersucht:

  • Wie ändert sich das Antwortzeitverhalten in Abhängigkeit von der Last?
  • Kann mit dem System auch unter hoher Last noch akzeptabel gearbeitet werden?
  • Zeigt das System undefiniertes Verhalten (z. B. Absturz)?
  • Kommt es zu Dateninkonsistenz?
  • Geht das System nach Rückgang der Überlast wieder in den normalen Bereich zurück?

Im Gegensatz dazu dient der Niederlasttest, der absichtlich mit einer geringen Intensität betrieben wird, der Untersuchung des Interaktionsverhaltens der virtuellen Benutzer und des von ihnen erzeugten Nachrichtenverkehrs auf dem System.

Einen Lasttest über einen längeren Zeitraum (z. B. 48–72 Stunden) nennt man Dauerlasttest; er dient in erster Linie zur Aufdeckung von Speicherlecks.

Die destruktivste Form eines Lasttests ist der Fail-Over-Test. Dabei geht es um die Überprüfung des Systemverhaltens unter Last bei Ausfall von Systemkomponenten. Im Idealfall werden damit Notfallszenarien überprüft, wie z. B. das rechtzeitige Zuschalten von Zusatzressourcen, um einen totalen Systemausfall zu verhindern.

Durchführung[Bearbeiten | Quelltext bearbeiten]

Generierung der Testdaten[Bearbeiten | Quelltext bearbeiten]

Das Testverhalten wird meist über eine Skriptsprache definiert. Viele Tools erlauben die Aufzeichnung über einen Webbrowser, ähnlich einem Makro in Excel. Dies wird zumeist über einen Proxy realisiert, welcher die Requests etc. in die Skriptsprache übersetzt. Ein wichtiges Kriterium ist hier die Benutzerfreundlichkeit bei der Testerstellung, aber auch die Variabilität und die unterstützten Protokolle (HTTP, HTTPS etc.). Vor allem in Bereichen wo die Quantität der Daten wichtiger als deren genauer Inhalt ist, werden auch so genannte Testdaten-Generatoren eingesetzt. Dies sind Programme, die eine große Datenmenge nach einem vorbestimmten Muster erzeugen, wobei die genaue Größe der Datenmenge in der Regel konfiguriert werden kann. Ein häufiger Anwendungsfall ist hier die Geschwindigkeitsmessung von Datenbanken.

Testlauf[Bearbeiten | Quelltext bearbeiten]

Im Testlauf wird mittels des erstellten Skriptes das aufgezeichnete Verhalten (eventuell ergänzt durch zufällige Elemente bzw. zählerabhängigen Variablen) in beliebig hoher Anzahl (Virtual Users) nebenläufig ausgeführt und somit die Anwendung unter Last gesetzt. Ein wichtiges Kriterium ist hierbei die maximal erzeugbare Last, sowie die Hardwareanforderungen, die damit einhergehen.

Sinnvoll ist auch die Möglichkeit die Lasterzeugung auf mehrere Rechner zu verteilen, welche einige Tools anbieten. Hierdurch kann der Einfluss der Netzwerk-Kapazität, sowie der Hardware-Beschränkungen des lasterzeugenden Rechners, minimiert werden. In letzter Zeit integrieren einige kommerzielle Tools die Möglichkeit, zusätzliche Lastgeneratoren in einer Cloud einzubinden.

Während des Testlaufs sammelt das Tool möglichst viele Daten. Grundsätzlich geschieht dies direkt auf der Seite der lasterzeugenden Anwendung (Antwortzeiten, Fehlercodes etc.). Einige Tools bieten auch zusätzliche Möglichkeiten, um bestimmte Web-/Datenbank-Server (z. B. IIS, Apache, MSSQL) oder Anwendungsserver (Tomcat etc.) zu überwachen, um direkt Zusammenhänge (z. B. hohe Antwortzeit vs. Datenbankzugriffe) zu analysieren. Die Datengewinnung kann jedoch auch modularisiert stattfinden (Hilfsprogramme z. B. auf dem Server der zu testenden Anwendung). Entscheidend ist, dass möglichst viele Möglichkeiten zur Sammlung verschiedener Daten geboten werden.

Auswertung[Bearbeiten | Quelltext bearbeiten]

Zur Auswertung stehen meist gewisse Kennzahlen (z. B. Antwortzeit vs. Zeit, Timeouts vs. Benutzerzahl etc.) in Logdateien bzw. zeitabhängigen Graphen zur Verfügung. Gute (meist kommerzielle) Tools bieten auch Möglichkeiten, z. B. über (Auto-)Korrelationsfunktionen, die Abhängigkeiten im Verhalten zu analysieren (z. B. hohe Antwortzeit vs. Aufruf einer bestimmten Seite etc.).

Normen[Bearbeiten | Quelltext bearbeiten]

Als Orientierung für die Planung eines Last- und Performancetests ist die DIN 66273 ein geeigneter Ausgangspunkt. Diese ist in der internationalen Norm ISO 14756 enthalten und standardisiert Begriffe sowie Mess- und Bewertungsverfahren der Leistung von komplexen DV-Systemen.

Für die Instrumentierung von Anwendungen zur Performance- bzw. Antwortzeitmessung wurde innerhalb der Open Group der Application Response Measurement (ARM) Standard verabschiedet. Dieser Standard definiert eine Programmierschnittstelle für die Programmiersprachen C und Java.

Softwaretools[Bearbeiten | Quelltext bearbeiten]

Zur Durchführung von Lasttests bieten sich sog. Lasttesttools an. Im Allgemeinen wird ein Lastserver installiert, der die Last auf dem zu testenden System erzeugt. Die Lasttesttools können entweder selbst hergestellt werden, oder man verwendet Standardsoftware, die eine Fülle an Funktionen und Auswertungsmöglichkeiten bietet.

  • Kommerzielle Anbieter von Lasttest-Softtware sind beispielsweise Hewlett-Packard, RadView, Micro Focus Borland, IBM, Microsoft und Compuware.
  • Freie Softwareprodukte sind beispielsweise das für Client-Server-Anwendungen konzipierte Apache JMeter sowie speziell für SOAP-Webservices soapUI.
  • Diese Anbieter von Lasttest Software sind beispielhaft, denn der Markt an Lasttest Software ist sehr groß und vielfältig. Eine Übersicht an gängigen Lasttest-Tools befindet sich hier: Lasttest-Tools

Weblinks[Bearbeiten | Quelltext bearbeiten]

Literatur[Bearbeiten | Quelltext bearbeiten]

  • Röhrle, Jörg: Ein regelbasierter Testdatengenerator für das Rapid Prototyping von Datenbankanwendungen, Hamburg : Kovač, 1995
  • Stefan Asböck: Load Testing for eConfidence. Segue Software Deutschland GmbH, Hamburg 2001.
  • Mike Loukides, Gian-Paolo Musumeci: System Performance Tuning. 2. Auflage. O’Reilly & Associates, Sebastopol 2002.
  • Harry Sneed, Manfred Baumgartner, Richard Seidl: Der Systemtest - Von den Anforderungen zum Qualitätsnachweis. 3. Auflage. Carl Hanser Verlag, 2011, ISBN 978-3-446-42692-4.
  • Richard Seidl, Manfred Baumgartner, Thomas Bucsics: Basiswissen Testautomatisierung - Konzepte, Methoden und Techniken. 1. Auflage. dpunkt.verlag, 2011, ISBN 978-3-89864-724-3.