Lasttest Definition, Ziele und Best Practices

Definition - Was ist ein Lasttest bzw. Last- und Performancetest

Ein Lasttest prüft die Leistung von Systemen unter unterschiedlichen Arbeitslasten. Dies kann beispielsweise vor der Veröffentlichung (Produktivsetzung) oder während der Entwicklung oder des Betriebs einer Software notwendig sein. Oder vor bestimmten Events, z.B. wenn aufgrund eines anstehenden Events eine intensive Nutzung der Services oder der Webseite erwartet wird.

Um herauszufinden, wo die Schwächen und Grenzen in einem System liegen, wird es einer kontinuierlich steigenden Belastung ausgesetzt bis es irgendwann der Beanspruchung nicht mehr standhält (Lasttest-Art: Stresstest / Überlastszenario). Das funktioniert, indem eine hohe Nutzlast simuliert wird, die entweder in Form von vielen gleichzeitigen (konkurrierenden) Nutzern oder das schnelle Wiederholen von Aktionen (hoher Durchsatz durch kleine Thinktime) erreicht wird. Dadurch kann man möglichen Fehlern auf die Schliche kommen, die nur unter hoher Auslastung des Systems auftreten. Im Fokus des Lasttests steht das Zeit- und Verbrauchs-Verhalten zu messen.

Der Lasttest bzw. Performancetest beschäftigt sich eben damit, er misst, wie sich die Antwort- und Verarbeitungsgeschwindigkeit bei verschiedenen Belastungen auf das System verhält.

Im Software Lebenszyklus (Application Lifecycle) befindet sich der Last- und Performancetest meistens in der Software-Entwicklungsphase im Bereich der Qualitätssicherungs-Aktivitäten (Softwaretest), im Integrationstest bzw. Systemtest. Ein Lasttest umfasst in der Regel immer eine Art der Testautomatisierung, da man die Last im Normalfall nicht mit zig-tausend manuellen Testern aufbringen möchte, sondern dies lieber „Virtuellen Usern“ in Form von Lasttestskripten überlässt, welche über dedizierte Lasttest-Software auf Lastgeneratoren ausgeführt werden.

Der Performancetest ist allgemein in die „nicht-funktionalen Testverfahren“ im Softwaretest einzusortieren.

Gängige Abkürzungen für  den Last- und Performancetest sind "LuP" und "LPT", wobei letzterer von uns eher als Abkürzung propagiert wird.

Ziele - Warum der Lasttest wichtig ist

© everythingpossible - stock.adobe.com

Zeit ist Geld - das gilt in der heutigen Geschäftswelt mehr denn je und das gilt im World Wide Web noch mehr als in der realen Welt. Deshalb ist es wichtig zu gewährleisten, dass Systeme unabhängig von Dauer und Nutzungslast problemlos arbeiten. Problemlos, das heißt in diesem Kontext schnell und zuverlässig, denn lange Wartezeiten kosten dem Unternehmen sowohl intern als auch extern enorm viel Geld.

So bestätigt beispielsweise Amazon, dass eine langsame Reaktion der Website deutlich negative Auswirkungen auf die Verkaufszahlen hat. Damit also eine reibungslose Arbeit mit dem System gewährleistet ist, gilt es, die Wartezeiten der Anwender auf ein Minimum zu beschränken. Genau dort setzt der Performancetest ein, indem er die Geschwindigkeit prüft, mit der das System funktioniert. Ist das Ergebnis nicht zufriedenstellend, liegt es am Unternehmen Performance-Verbesserungen vorzunehmen.

Das getestete System sollte mit all seinen Komponenten möglichst optimal und effizient laufen. Genau dies sollte der Last- und Performancetest beweisen.

Ein weiterer Artikel über den Stellenwert von Lasttests und weiteren Beispielen ist in folgendem Artikel zu finden: Warum Last- und Performancetest? Gute Performance macht den Unterschied!

Arten von Lasttests und Last-Profile / Workloads

Um herauszufinden, welches Last-Profil bzw.  welche Workload (Arbeitslast) verwendet werden sollte, muss man zuerst definieren, welches Ziel angestrebt wird. Je nach Anforderungsprofil kann der Test das System auf unterschiedliche Szenarien prüfen.

Die Begriffe werden je nach Unternehmen bzw. Literatur etwas unterschiedlich genutzt. Im Kern ist oft aber das gleiche gemeint.

So gibt es den Stresstest, bei diesem wird die Last, ausgehend von einem kleinen Startwert, stetig erhöht, bis das System Fehler aufweist und der Last nicht mehr Stand hält. Während die Beanspruchung linear steigt, flacht die Leistung irgendwann meist ab. Gesucht wird der Moment, in dem die Antwortleistung exponentiell sinkt, wenn die Arbeitslast erhöht wird. An diesem Punkt ist die maximale Kapazität des Systems erreicht.

Der Dauerlasttest hingegen prüft die Stabilität, den Ressourcenbedarf und das Antwortzeitverhalten indem er auf eine längere Zeit (12h bis hin zu mehreren Tagen) läuft. Hier sind auch Memory Leaks (Arbeitsspeicher-fressende Speicherlecks) gut identifizierbar.

Der Skalierbarkeitstest wird verwendet um herauszufinden, wie intensiv ein System genutzt werden kann und ob es mit Zunahme weiterer Hardware gut „skaliert“. Sprich, ob mit mehr Hardware auch mehr Arbeitslast bei weiterhin guten Antwortzeiten verarbeitet wird.

Der Performancetest wird oft als Oberbegriff für Testarten verwendet bei denen es um Zeitverhalten geht. Nach ISTQB und im korrekten Deutsch, würde man es Performanztest oder Effizienztest nennen, dies ist aber in der Praxis eher seltener genutzt. Nach ISTQB ist der Lasttest eine Art des Performanztests.

In der realen Welt des Softwaretests, unabhängig von Lehrplänen, wird "Last- und Performancetest" bei weitem am meisten als allgemeiner Oberbegriff für Performance-Test-Arten verwendet. In Unternehmen oft ganz pragmatisch mit den bereits vorgestellten Abkürzungen "LPT" oder "LuP".

Nach ISO 9126 ist Effizienz auch eines der sechs übergeordneten Qualitäts-Merkmale, unter welchen auch der Performanztest fällt.

Ein ausführlicher, weiterer Artikel über Performance-Testing-Profile und Workloads ist hier zu finden.

Außerdem kann ein Lasttest an verschiedenen Schnittstellen ansetzen, per GUI, per API (HTTP, Webservices, REST) oder beispielsweise per SQL direkt auf der Datenbank.

Praxistipps- Checkliste zu Last- und Performancetests

Bevor man einen Last- und Performancetest durchführen lässt, sollte man Folgendes tun.

Ziele formulieren:

• Was möchte ich mithilfe des Tests herausfinden?
• Wie schnell soll mein System antworten und ist dies abhängig von verschiedenen Bedingungen?
• Gibt es SLAs (Service-Level-Agreements) oder NFR /NFA (none-functional-requirements / Nicht-funktionale-Anforderungen)?
• Welche Last-Arten sollte ich demnach zur Prüfung meines Systems auswählen und wie sind die Ziele der verschiedenen Test-Arten?

Erwartungen festlegen:

• Welche Ergebnisse erhoffe ich von diesem Softwaretest?
• Geht es vor allem um Gewinnmaximierung, Server-Ressourcen-Einsparung oder um Arbeitserleichterung und Kundenzufriedenheit?

Timeline und Termine festlegen:

• Wann – in welchem Schritt der Systementwicklung ist es sinnvoll, den Test zu machen?
• Soll der Test einmalig oder kontinuierlich durchgeführt werden - gegebenenfalls inkludiert in ein CI (Continuous Integration) Verfahren?

Lasttest Tool, Personal, Aufwand und Techniken bestimmen:

• Welche Ressourcen bin ich bereit zu investieren?
• Welche Last bzw. welcher Durchsatz wird benötigt?
• Über welche Schnittstelle möchte ich den Test ansetzen?
• Welche Testdaten benötige ich bzw. wie sollen meine Basisdaten der Datenbank aussehen und wo kommen diese her?
• Welche Technologien und Architekturen werden genutzt?
  - Flex, Flash, Push und Pull Verfahren, Cloud, dynamisches HTML5, AJAX, Web 2.0, Industrie 4.0, das Internet-of-Things, Wearables, Mobile Apps und Mobile Devices,  ... zum Teil sind es Technologien zum Teil eher Buzzwords. Sie alle haben jedoch enormen Einfluss auf das geforderte Knowhow und Anforderungen an das Lasttest-Tool und das Lasttest-Konzept, bzw. den nötigen Aufwand für den Last- und Performancetest.
• Wie sehr soll bzw. darf die Testumgebung der Produktionsumgebung ähneln? Meist ist es eine Budgetfrage. Grundsätzliche sollte die Testumgebung bei Performance-Testing der Produktionsumgebung möglichst nahe sein.

All diese Punkte sollten einem Lasttest Konzept festgehalten werden. Weitere Ideen dazu finden sie in den Artikeln Sieben vermeidbare Fehler bei Lasttests und Umfang von Last- und Performancetests.

Open Source und kommerzielle Performance-Testing Tools

Aufgrund der Vielzahl an Lasttest Tools kann es schwer sein, sich für das Richtige in dem jeweiligen Fall zu entscheiden. Grundsätzlich sind Open Source Tools kostengünstiger, aber verlangen meist auch mehr Arbeitsaufwand. Sie bieten im HTTP Umfeld meist Unterstützung und sind dort durchaus gut einsetzbar. Allerdings lassen sich nicht alle Systeme gut damit testen und die Lasttest-Skripte sind meist nur mit erfahreneren Programmierer-Skills realisierbar. Auch das Reporting ist oft nur unter großem manuellem Aufwand möglich oder ist es ein eigenes automatisiertes Reporting-System aufzusetzen.

Kommerzielle Testwerkzeuge bringen hingegen eigene Reporting-Möglichkeiten mit und bieten meist auch Unterstützung beim Monitoring der Server und Infrastruktur. Sie bieten oft Schnittstellen zu APM-Tools und Unterstützungen vielfältige Protokolle und Schnittstellen. Weitere Details dazu sind in unserem Listing von Lasttest Software zu finden.

Neben dem Lasttest-Tool sind meist noch Testmanagement Software und/oder ALM-Tools in der Tool-Landschaft des Softwaretests vorhanden. Die Lasttest-Tools, insbesondere die kommerziellen Testwerkzeuge, bieten meist Schnittstellen zu bestimmten Testmanagement- und ALM-Tools.

Herausforderungen bei der Lasttest Durchführung

Um den Lasttest repräsentativ zu gestalten, liegt die große Herausforderung darin die Last auf das System möglichst realistisch zu gestalten. Dabei sind einige Aspekte besonders wichtig: Die Anzahl der gleichzeitigen Nutzer, deren Aktivität und wie diese das System verwenden (Szenarien, Geschäftsprozesse bzw. Use-Cases).  Dazu ist auch das Mengengerüst bedeutend.

Auch welcher Browser benutzt wird kann relevant sein. Beispielsweise nutzen Browser unterschiedliche Parallelisierung von Verbindungen beim Aufruf einer Webseite, was wiederum pro User zu unterschiedlicher Anzahl offenen Server Connections führt.

Um dies einschätzen zu können, ist es sinnvoll, Daten zu sammeln: Protokolldaten analysieren, Monitoringdaten auswerten, mit den Projektmitarbeitern, Anwendern und Managern kommunizieren und Informationen aus Tools, Konzepten und Produktionsdaten ziehen.

Weiterhin ist es relevant, bei der Testung mit einer geringen Belastung zu starten und diese dann auf die gewünschte Menge zu steigern. Da Fehler beim Start mit einer zu hohen Nutzerinterkation übersehen werden könnten und dadurch der Test an Sinnhaftigkeit verliert. Außerdem ist es wichtig, die Lastgeneratoren auf die erwartete Last zu skalieren, um falsche Ergebnisse bzw. Probleme bei den Tests zu vermeiden.

Wie man bereits erahnen kann, ist das Durchführen von Last- und Performancetests kein Einfaches. Deshalb ist es wichtig, diese Arbeit Personen zu überlassen, die sich sowohl dieser Herausforderungen bewusst sind als auch den dafür nötigen technischen Background besitzen.

Besondere Herausforderungen bei Performance-Testing für mobile devices – mobile apps

© Victoria - stock.adobe.com

Die Nutzung von mobilen Apps ist aufgrund von Smartphone und Tablet stark gestiegen. Daher besteht auch die Anforderung an den Lasttest, die daraus resultierenden Faktoren miteinzuberechnen z.B.:

• Emulation unterschiedlicher Bandbreiten,
• verschiedene Verbindungsqualitäten,
• potenzielle Verbindungsabbrüche,
• Paketloss,
• wechselnde Funkmasten bei schneller Bewegung
• und Latenzen.

Außerdem muss berücksichtigt werden, dass je nach verwendetem Browser, verschiedene Datenvolumina geliefert werden. Deshalb ist es sinnvoll, Testgruppen mit typischen unterschiedlichen Browser Präferenzen zusammenzustellen, um im Last- und Performancetest diese Schwankungen zu simulieren und miteinzuberechnen.

Weiterhin erhöhen Mobile Devices stark die Vielfalt an Display-Auflösungen. Durch Responsive Designs und Implementierungen für verschiedene Devices kann es ein großer Unterschied sein, von welchem Device  bzw. mit welcher Auflösung eine Webanwendung aufgerufen wird. Denn der Response (die Antworten vom Server) kann durch das Responsive Design ganz unterschiedlich sein. Ggf. werden bestimmte Images (Bilder) nur in kleinen Auflösungen oder gar nicht geladen. Oder vielleicht werden bestimmte Java-Skripte gar nicht ausgeführt, sodass bestimmte asynchrone JSON Request (die beispielsweise Widgets nachladen) bei niedrigen Auflösungen oder auf bestimmten Devices gar nicht versandt werden.

Wenn man End-to-End Performance bewerten will und damit auch die Client-Zeiten mit einbeziehen will, also die Zeit die der Client braucht um Skripte der Webseite auszuführen und die Webseite darzustellen (Rendering), wird es noch weitaus komplizierter. Da hierbei das Zeit- und auch das Verbrauchsverhalten der verschiedenen Devices betrachtet werden muss. Was durch die hohe Fragmentierung der Clienten somit eine große Herausforderung darstellt.

Wir wünschen viel Spaß beim Stöbern durch unsere weiteren Last- und Performancetest Artikel!

Fragen, Feedback, Ergänzungen, Wünsche?

Haben Sie Fragen rund um das Thema Lasttest / Performancetest ? Oder möchten Sie gerne eine Beigabe aus Ihrem Lasttester-Knowhow beisteuern? Gerne Feedback, Ideen und Fragen in den Kommentaren weiter unten.