Software-Test / Testautomatisierung / Testmanagement

Last- und Performancetest in 5 Tagen – Prolog 1/6

Für manche Projekte möchte man einen kurzen Last- und Performancetest durchführen, um ein Release schnell und effizient zu überprüfen. Doch wie gehe ich an einen solchen Test heran? Ich möchte Ihnen im Laufe der nächsten Wochen in einer 6-teiligen Beitragsreihe aufzeigen, wie man einen Last- und Performancetest in 5 (Personen-)Tagen umsetzen kann. Heute starten wir mit Teil 1 – den Vorbereitungen.

Last- und Performancetest Prolog

Eine moderne Webapplikation muss aus Benutzersicht ein ansprechendes Design und eine hervorragende Bedienbarkeit (siehe ISO/IEC 25000 bzw. ISO 9126) haben. Außerdem werden Webapplikationen immer komplexer und gleichen sich klassischen Desktopanwendungen immer mehr an, sowohl im Funktionsumfang als auch im Design.

Mit AJAX und verwandten Technologien können dynamische Webapplikationen erstellt werden. Die Kommunikation mit dem Server geschieht im Hintergrund und die Daten werden in kleinen Häppchen übertragen. Der Client ist für die Darstellung und die Verarbeitung der Daten zuständig.

Reagiert die Anwendung langsamer als es der Benutzer gewohnt ist, verliert er schnell die Lust an der Applikation. Das  Image der Applikation und damit auch des Anbieters leidet. Leider ist es so, dass schlechte Nachrichten schneller und intensiver verbreitet werden als gute. Dem Benutzer ist egal, was oder wer an der schlechten Performance schuld ist, ob Datenbank, Webserver oder sonstiges – ihn interessiert nur das Endergebnis. Daher sollte für die Überprüfung der Antwortzeiten ein Last- und Performancetest durchgeführt werden.

Für manche Projekte möchte man einen kurzen Last- und Performancetest durchführen, sozusagen einen Load-Smoke-Test, damit kann eine Release schnell und doch effizient überprüft werden. In dieser Beitragsreihe möchte ich Ihnen zeigen, wie ein solcher Test in 5 (Personen-)Tagen umgesetzt werden kann.

 

Prolog

In der Vorbereitungsphase des Last- und Performancetests müssen die Vorbedingungen besprochen und festgelegt werden. In einem Erstgespräch setzen sich der Projektleiter und der Lasttest-Spezialist zusammen um den Testverlauf zu besprechen:

  • Welche Applikation ist zu testen?
  • Wie ist die Infrastruktur aufgebaut?
  • Welche Technologien werden eingesetzt (z. B. JSF, Java, Spring, Webserver oder Datenbankserver)?

Der Projektleiter erklärt das Ziel des Last- und Performancetests, d.h.

  • Wie viele Benutzer (Anzahl der maximalen virtuellen Benutzer) sollen die Applikation später verwenden?
  • Welche Antwortzeiten sind noch akzeptabel?

Es ist ein Unterschied ob ein Login „lange“ dauert oder das Verschieben von Einträgen in einem Terminkalender „lange“ dauert. Bei Ersterem ist der Benutzer toleranter (5-8s), das Verschieben von Terminen muss allerdings sofort gehen (<200ms). Der Projektleiter wird den wichtigsten Pfad durch die Applikation, d.h. die wichtigsten Geschäftsfälle, vorstellen. Dieser Pfad ist Grundlage für die Entwicklung des Testszenarios.

Das Testszenario

Im Szenario sollen vor allem die wichtigsten Geschäftsfälle beachtet werden, diese müssen funktionieren (d.h. Bugfree sein), sonst kann ein Last- und Performance nicht durchgeführt werden. Das Szenario sollte nicht allzu komplex sein, damit der Rahmen des Tests nicht gesprengt wird. 5 Personentage für einen Load-Smoke Test sehe ich als sinnvoll an. Ein Szenario für den Admin Bereich muss nicht unbedingt berücksichtigt werden. Ein Last- und Performancetest ist eben kein funktionaler Test, in dem diverse Fehlerfälle überprüft werden sollen, wie z.B. ungültiger Login, Sperrung des Users, etc..

Nach Projektende kann das Szenario wiederverwendet bzw. leicht an neue und optimierte Versionen der Applikation angepasst werden.

Bei der Besprechung des Szenarios wird auch das Last- und Performancetest Tool festgelegt. Entweder gibt es einen unternehmensweiten Standard oder der Lasttester hat freie Hand. Der Funktionsumfang des Tools hat Einfluss auf die Gestaltung des Szenarios, da bestimmte Funktionen vorhanden sind oder nicht. Müssen im Laufe des Tests Javascript-Methoden aufgerufen werden, z.B. um ein Passwort zu verschlüsseln. Wenn das gewählte Tool das aber nicht kann, muss der Lasttester auf ein anderes Tool zurückgreifen.

Das Tool legt in gewissem Maße auch die maximale Anzahl an virtuellen Benutzern fest. Bei vielen Tools kann die Cloud als Lastgenerator verwendet werden; dies ist jedoch nur dann ein Vorteil, wenn die Anwendung von der Cloud aus aufrufbar ist. Für den Test braucht der Lasttester einen oder mehrere Zugänge zur Applikation und einen Zugang pro virtuellen Benutzer. Die Erzeugung der Login-Daten kann sehr lange dauern, wenn die Erzeugung nur manuell erfolgen kann. Es ist deshalb zu klären, ob  eine Handvoll Testuser ausreichend wäre und ob die Testaussage dadurch leiden würde

Sind alle diese Fragen geklärt und die Aufgaben erledigt, können sich der Projektleiter und der Lasttester einen Termin für den Teststart ausmachen. In diesem Zeitraum sollten keine Deployments oder manuelle Tests auf dem gleichen System stattfinden. Ein Lasttester wird keine Freude haben, wenn das System nur noch schwerfällig reagiert. Bei einem Deployment können sich (neue) Bugs in das System einschleichen oder es können sich HTML IDs ändern, die der Lasttest benötigt.

Der Testdurchführungstermin muss mit einem Systemverantwortlichen (Administrator) koordiniert werden, denn wer startet sonst das System neu, wenn es nicht mehr reagiert?

Vorbedingungen und Maßnahmen eines Last- und Performancetests, die unbedingt durchgeführt werden müssen, habe ich in Form einer Checkliste nochmals zusammengestellt:

 

Die Checkliste: Vorbereitung Last- und Performancetest

Infrastruktur

  • Zugänge vorhanden: Benutzer, URL, etc.
  • Infrastruktur und Infrastrukturplan ist vorhanden
  • Infrastruktur (Loadbalancer, Webserver, DB Server) ist korrekt konfiguriert

Applikation

  • Applikation ist in einem testbaren Zustand, d.h. die funktionalen Anforderungen, die im LPT Szenario verwendet werden, müssen erfüllt sein
  • Applikation ist „Last-und Performancetest Ready“, d.h. es müssen sich auch 100 Benutzer anmelden können, wenn der Test mit 100 Benutzern durchgeführt werden soll

Termin

  • Termin der Durchführung ist festgelegt
  • Infrastrukturverantwortlicher ist über den Test informiert und erreichbar, falls der Server auf Grund der Überlastung seine Funktion aufgibt geht und neu gestartet werden muss.
  • In dieser Zeit dürfen keine funktionalen Tests oder Deployments stattfinden

Szenario

  • Szenario ist bekannt und umsetzbar
  • Szenario enthält die wichtigsten Geschäftsprozesse

Lasttest Tool

  • Testtool ist vorhanden
  • Testtool kann auf Testinfrastruktur zugreifen

Virtuelle Benutzer

  • Falls notwendig: Die zu verwendeten Benutzer sind angelegt

Umgebung

  • Entwickler ist informiert; Ansprechpartner der Entwicklung bei Applikationsfragen ist dem Lasttester bekannt
  • Projektleiter: Leitet die LPT Aufgabe, Definiert den Termin (Wann?), Welche Infrastruktur (Wo?) und das Szenario (Was?). Außerdem muss er alle involvierten Personen informieren
  • Last Test Spezialist: Entwickelt zusammen mit PL das Szenario und setzt dieses in einem Tool um, führt Analysen und den Test durch, liefert Optimierungsvorschläge
  • Infrastrukturverantwortlicher: Wird durch PL informiert wann der Test durchgeführt wird und bleibt mit dem Lasttester in Kontakt

 

Können Sie alle Punkte der Checkliste abhaken? Dann steht einem erfolgreichen Start des Last- und Performancetests nichts im Wege.  Am Montag geht es los und ich zeige Ihnen in Teil 2 der Beitragsreihe, wie Projektleitung und Lasttester am besten ein Szenario erarbeiten und Testziele festlegen. Bis dann!

 

Die Blogreihe:
Last- und Performancetest in 5 Tagen – Prolog 1/6
Last- und Performancetest in 5 Tagen – Montag 2/6
Last- und Performancetest in 5 Tagen – Dienstag 3/6
Last- und Performancetest in 5 Tagen – Mittwoch 4/6
Last- und Performancetest in 5 Tagen – Donnerstag 5/6
Last- und Performancetest in 5 Tagen – Freitag 6/6

Passende Artikel

Ein Kommentar

  1. Pecenka sagt:

    Sehr guter Artikel, der einfach und verständlich die nötigen Schritte beschreibt, sodass diese auch für nicht Techniker verständlich und nachvollziehbar sind. Bin gespannt auf den nächsten Artikel!