Software-Test / Testautomatisierung / Testmanagement

Last- und Performancetest in 5 Tagen – Dienstag 3/6

Der Lasttester beginnt am Dienstag mit der Erstellung des Skripts. Als Basis dient die Szenarienbeschreibung und der Proof-Of-Concept von Montag. Am Ende des Tages hat sich der Lasttester in die Applikation eingearbeitet und es existiert eine erste Version des Skripts.

Last- und Performancetest Dienstag_Testskipt

Dienstag Vormittag

Der Dienstag ist der Scripting Day. Das Szenario (oder die Szenarien) werden umgesetzt und dabei der Proof-of-Concept erweitert. Das Tagesziel ist, dass das Testskript als Ganzes fehlerfrei abläuft. Für das Skripten an sich sind insgesamt zwei Tage eingeplant (Dienstag und Mittwoch).

Das Szenario wurde am Vortag in aussagekräftige Fragmente geteilt, wie z.B. „LOGIN“ oder „WARENKORB ANZEIGEN“. Die Fragmente werden nun Step-By-Step umgesetzt. Ich gehe dabei so vor, dass ich mit LOGIN und LOGOUT beginne. Das ist der Rumpf meines Skriptes. Innerhalb dieses Rumpfes werden die anderen Fragmente nach und nach eingefügt. Jedes Fragment kann als kleiner Meilenstein gesehen werden. Ein Fragment kann in kleinere Arbeitspakete unterteilt werden.

Zur Illustration ein Beispiel:

Die Darstellung hier ist sehr an Neoload bzw. JMeter angelehnt, die Vorgangsweise in anderen Tools ist aber ähnlich.

Es soll ein Webshop für Mineralwasser getestet werden. Ein mögliches Szenario könnte so ausschauen:

  1. Login
  2. Suche nach „Niederösterreichisches Mineralwasser“
  3. Bestellen von je 10 Flaschen Mineralwasser Prickelnd und Still.
  4. Warenkorb aufrufen und bezahlen; Zahlart ist „Auf Rechnung“
  5. Logout

Dieses Szenario wird nun in die folgenden Fragmente unterteilt:

  • LOGIN
    • SUCHE
    • BESTELLEN
      • PRICKELND
      • STILL
  • WARENKORB
  • BESTELLEN
  • LOGOUT

Jedes Fragment wird nun in kleinere Arbeitspakete unterteilt. Diese so entstehenden Subfragmente haben zwei Aufgaben: Sie teilen das Fragment in weniger komplexe Bereiche, dienen so der Gliederung des Szenarios, und sind so designed, dass man die Subfragmente vor einem Testlauf an- und abschalten kann.

Schauen wir uns das Fragment „SUCHE“ einmal näher an. Eine Webseite  besteht im Allgemeinen aus mehreren Dateien, wie HTML Code, JavaScript Dateien, CSS Dateien und Bilder. Dazu kommen noch Requests (wie bei AJAX), die im Hintergrund Daten mit dem Server austauschen.

Die Webseite ist komplett geladen, wenn auf alle Requests die jeweiligen Antworten am Client angekommen sind und der Browser die Seite darstellen kann.  In der SUCHE-Seite wird nun ein Suchbegriff eingegeben. Der Client schickt die Suchanfrage an den Server und bekommt als Antwort das Suchergebnis. Diese Seite besteht aus einem statischen und einem dynamischen Teil. Bei dem ersten Aufruf der SUCHE Seite, werden Daten geladen und dargestellt. Erst wenn der Benutzer etwas sucht, werden wieder Daten zum Server und wieder zurück gesendet. Ein Teil dieser Daten wird vermutlich gleich sein, wie zum Beispiel ein Webshop Logo oder ein Hintergrundbild, aber auch das JavaScript Framework. Ein anderer Teil der Daten ist allerdings dynamisch und ändert sich bei jedem Zugriff. Zum Beispiel die Suchanfrage eines Benutzers oder die Session ID.

Ich teile daher diese Fragmente in einen statistischen und einen dynamischen Teil. Den statischen Teil nenne ich der Einfachheit halber RESOURCEN. In diesen gebe ich alle Requests, die statische Bilder, Javascripts, CSS usw. vom Server abrufen. Die dynamischen Requests sind bei mir direkt unterhalb des Fragment-Ordners. In diesem werden nun alle Requests eingefügt, die für den kompletten Aufruf der Seite notwendig sind und dynamische Parameter haben, wie Session ID, Such Anfrage oder Timestamps.

  • SUCHE
    • RESOURCEN
      • Enthält statistische BILDER, JavaScripts, CSS etc.
  • getSearchPage
  • searchFor
    • Request mit POST „search=Niederösterreich“ und „jsessionid=98asd7a70“
    • Die Antwort dieses Request ist das Suchergebnis

 

In diesem Beispiel werden die RESOURCEN nur einmal geladen und anschließend werden zwei Requests abgesetzt. Man könnte nun die RESOURCEN nochmals vor dem „searchFor“ Request kopieren. Wenn das Caching ausgeschaltet ist, würde dies der Realität näher kommen. Je genauer man bei der Strukturierung vorgeht, desto besser ist das Skript wartbarer und bleibt verständlich.

Während der Skripterstellung muss das Skript immer wieder mit nur einem virtuellen User getestet werden, damit sichergestellt ist, dass das Skript fehlerfrei ist. Die Fragmente LOGIN und LOGOUT sollten zu Beginn entwickelt werden und wenn diese 100% funktionieren, werden die weiteren Fragmente erstellt. Ich würde sogar so weit gehen hier schon einmal die Last aufzudrehen, um zu testen, wie viele User sich einloggen können. Dieser Start-Test sollte aber unbedingt mit der Projektleitung abgesprochen werden, da der Server ausfallen kann. Dieser Test zeigt eventuelle Mängel der Infrastruktur auf, z.B. wenn der Server nur 10 Verbindungen akzeptiert, man aber einen Test mit 1000 Usern machen will.

Wenn das LOGIN und LOGOUT einwandfrei funktionieren kann man sich eine Mittagspause gönnen :-).

 

Checkliste für Dienstag Vormittag

  • Szenario wurde umgesetzt (Scripting Day)
  • Skript wurde immer wieder getestet
  • Rumpf des Szenarios wurde umgesetzt

 

Dienstag Nachmittag

Nach dem Mittagessen konzentriert man sich auf die Entwicklung weiterer Fragmente. Wenn wir bei dem Beispiel bleiben, dann erkennt man schnell, dass hier viele Fragen auftauchen werden. In dem Beispiel SUCHE müssen zwei Daten an den Server gesendet werden, damit wir ein Suchergebnis erhalten. Das wäre „search=“ und „jsessionid=“. Während „search=“ der Suchstring ist und einfach zu handeln ist, wird die Session ID „jsessionid=“ ein wenig komplexer. Die ID muss womöglich aus der Antwort auf das LOGIN Request extrahiert werden oder sie ist im Cookie abgespeichert und muss von dort ausgelesen werden.

Bei der Modellierung von Business Cases werden Parameter benötigt. Diese müssen in den meisten Fällen aus den Antworten der vorgehenden Requests extrahiert werden. Die meisten Tools bieten dafür die Möglichkeit, Regular Expressions einzusetzen. In unserem Beispiel wäre das die Session ID, die ich durch das LOGIN erhalte. Diese muss ich extrahieren und in jedem weiteren Request verwenden. Die Verwendung von Variablen, die für alle Requests verfügbar sind, ist daher wichtig. Die Variablen sollten eindeutige Namen haben, dies erleichtert die Wartung und Wiederverwendbarkeit enorm.

In vielen Projekten erstelle ich, wenn LOGIN und LOGOUT funktionieren, mehrere Variablen mit denen ich den Test schnell konfigurieren kann. Wie zum Beispiel Login Daten (Username, Password), oder die URL des Servers.

Soll die Anwendung mit verschiedenen Benutzern getestet werden, werden diese in einer Liste erfasst. Dies kann über eine CSV Datei oder einer Datenbankabfrage geschehen. Als Ergebnis erhalte ich einen Username und das zugehörige Passwort. Mit z.B. 100 Userdaten können sich 100 verschiedene User an der Anwendung anmelden. Die meisten Tools können mit solchen Listen umgehen.

Zurück zu den Request Variablen: Wenn die Anwendung AJAX verwendet, muss der Last-und Performance Lasttester wissen, was zum Server übertragen wird. Die Client Anwendung schickt einen Request an den Server und erhält eine Antwort, welche die angefragten Daten enthält. Die Antworten müssen ausgewertet werden. Dies funktioniert aber nur dann, wenn man die JSON oder XML Daten auch versteht. Hier ist die Zusammenarbeit mit dem Entwickler essenziell. Einige Daten kann man mit Erfahrung selbst herausfinden, andere überhaupt nicht.

Ein Last- und Performance Testskript kann über zwei Arten erstellt werden:

  • Aufnahme mit einem Proxy
  • Manuelles Erstellen der Requests

Man startet am besten mit der Aufnahme (Recording Funktion des LPT Tools) und bearbeitet die Requests einzeln. Das funktioniert in den meisten Fällen sehr gut. Bei AJAX Requests, bei denen die meisten Daten ähnlich sind, kann man den Browser nehmen und sich die übertragenen Daten (über z.B. Firebug oder Google Developer Tools) eines Requests anschauen. Die Daten können nun händisch in das Last- und Performance Tool übertragen werden. Bei einem Projekt hat dies bei mir sehr gut funktioniert und war sauberer und schneller als wenn ich das per Aufnahme der Requests gemacht hätte. Vor allem hat man die Kontrolle über die einzelnen Requests und schickt nur diejenigen, die gerade wichtig sind.

Während dieser Entwicklungsphase sollte man immer wieder den Test starten um zu kontrollieren ob dieser auch läuft und das macht, was er machen soll.

Sind wir hier angelangt, darf sich die Anwendung nicht mehr ändern! Jede Änderung erfordert ab diesem Zeitpunkt eine Änderung des Skriptes! Dieser Umstand sollte dem Projektleiter und dem Team klar sein.

 

Die Checkliste für Dienstag Nachmittag

  • Szenario wurde weiterentwickelt
  • Offene Fragen wurden mit der Projektleiter besprochen
  • Es wurde kommuniziert, dass eine Änderung in der Anwendung mit großer Wahrscheinlichkeit eine Änderung im Lasttestskript zur Folge hat (Zeitfaktor beachten)
  • Testskript läuft fehlerfrei ab

 

Ist bisher alles gut nachvollziehbar für Sie? Falls etwas unklar ist schreiben Sie gerne einen Kommentar.  Am nächsten Tag wird das Last- und Performance Testskript weiter optimiert und stabilisiert. Das Ziel für Mittwoch ist, dass das Skript fehlerfrei abläuft. Und wir widmen uns bereits dem Testreport und der Terminplanung. Bis nächste Woche!

 

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

Kommentare gesperrt.