Software-Test / Testautomatisierung / Testmanagement

Last- und Performancetest in 5 Tagen – Mittwoch 4/6

Am Mittwoch wird das Testskript von Dienstag weiter optimiert und stabilisiert. Das Ziel ist es, dass das Skript fehlerfrei abläuft. Weitere Aufgaben sind den Testreport zu beginnen und Termine für die Lasttests an sich zu definieren.

Last- und Performancetest Mittwoch_Testskript

Mittwoch Vormittag

Der Mittwoch, also Tag 3, gehört wieder dem Skripting. Der erste Schritt in der Früh – nach einem Kaffee – ist, das Skript vom Vortag einem Test zu unterziehen. Es muss immer wieder überprüft werden, dass das Skript auch funktioniert. In der kurzen Zeit, die dem Lasttester zur Verfügung steht, ist dies essenziell.

Bei diesem kurzen Test wird auch überprüft, ob sich die Anwendung gegenüber dem Vortag verändert hat. Die verwendeten Variablen müssen auf jeden Fall funktionieren. Die Regular Expressions müssen greifen, dazu dürfen sich z.B. die HTML Element IDs nicht verändern. Die Gefahr dabei ist nämlich, dass sich mehr als nur die IDs geändert haben bzw. sich die IDs immer wieder ändern.  In JSF können Teile einer ID dynamisch sein, diese ändern sich nach jedem Deployment. Hier müssen andere eindeutige Merkmale gefunden werden, z.B. CSS Class Namen in Kombination mit dem Name-Attribut etc. Wenn der Aufwand für eine Korrektur und ein Deployement relativ gering ist, d.h. innerhalb von 30 Minuten erledigt werden kann, kann die Entwicklung gebeten werden einen Quick Fix zu machen.

Die Komplexität des Fragments bestimmt den Aufwand der Anpassung wenn sich die Anwendung ändert. Wegen der Kürze des Projektes, muss der Aufwand für den Last- und Performance Lasttester so gering wie möglich gehalten werden. Auch die Zeit für ein Refactoring bzw. Anpassen des Testskripts vor jedem Testlauf ist nicht vorhanden und auch nicht erstrebenswert! Die Projektleitung muss sicherstellen, dass die Anwendung bis zum Abschluss der Tests testbar bleibt. Neue Funktionalitäten, die das Lasttestskript ändern, müssen verschoben werden.

Bei der Entwicklung der Fragmente muss der Lasttester immer wieder die Schritte am Testobjekt ausprobieren. Kleine Fehler in der Anwendung können dazu führen, dass man Workarounds basteln muss oder dass der Last-und Performancetest nicht durchgeführt werden kann wie geplant. Werden Fehler gefunden muss man sofort den Projektleiter informieren. Sind die Fehler gravierend, das bedeutet hier, dass der LPT nicht durchgeführt werden kann, muss der LPT verschoben werden.

Wird ein Anwendungsfehler gefunden, muss dieser korrigiert werden. Die Korrektur wird eine gewisse Zeit benötigen. In dieser Zeit muss der Lasttester andere Aufgaben erledigen.

Eine solche Aufgabe wäre es, das Skript zu optimieren. Der Lasttester kann das Verhalten verbessern, d.h. das Skript realitätsnäher machen. Pausen zwischen den virtuellen Clicks können eingefügt werden, dies ermöglicht eine bessere Modellierung der Realität, z.b. nach dem Senden eines Requests wird eine zufällige Zeit pausiert.

Eine weitere Aufgabe ist es, die Testreports vorzubereiten, dem widmen wir uns am Nachmittag.

 

Mittwoch Nachmittag

Was alles in den Testreport eingefügt werden soll, ergibt sich aus dem Test Scope und den Wünschen der Projektleitung. Eine Frage, die ich persönlich immer bereits zu Beginn eines Projektes stelle,  ist: „Sekunden oder Millisekunden?“. Dies scheint auf den ersten Blick seltsam, aber wenn man nach einer Kurzanalyse den Satz „Die Antwortzeiten sind alle unter 125“ formuliert, dann wird wahrscheinlich der Projektleiter nervös weil in den Anforderungen „gefordert ist eine maximale Antwortzeit von 2 Sekunden“ steht. Hätte man sich am Anfang auf die Einheiten geeinigt, dann hätte ich „0.125s“ geschrieben.  Auch ergibt sich damit ein einheitliches Bild und man spricht immer über die gleiche Zahlengröße.

Der Report sollte so vorbereitet werden, dass alle Tests, die man am nächsten Tag machen will, bereits beschrieben werden. Darunter fallen Beschreibung der Infrastruktur, Anzahl der Benutzer, Anzahl der Wiederholungen usw.

Anhand der Aufstellung des Tests, kann man planen, wieviel Zeit man benötigt und wie man am nächsten Tag vorgeht.

Bevor der Tag zu Ende geht, setzte man sich mit dem Projektleiter zusammen und zeigt ihm das Skript. Vielleicht erkennt der Projektleiter, dass etwas vergessen wurde oder es wurde was zu viel gemacht. Beides kann (aber muss nicht) korrigiert werden.

Mit dem Projektleiter werden die Termine für den Last- und Performancetest festgelegt. Ich würde nochmals wegen der Kontakte zu Entwicklern und Infrastrukturverantwortlichen nachfragen. Die Telefonnummern oder Email Adresse wird man vielleicht brauchen, wenn der Server ausfällt.

Ein weiterer wichtiger Punkt ist, dass der Projektleiter alle Beteiligten informiert. Denn während des Tests wären einige Dinge kontraproduktiv, wie z.B. Deployments oder ein Neustart des Datenbankservers.

Der Projektleiter wird sicher auch fragen: „Wie lange dauert der Test denn?“. Diese Frage zu beantworten ist recht schwierig. Durch die permanenten Tests des Skriptes bekommt man schnell ein Gefühl, wie lange der gesamte Test dauern wird. Die Rechnung „Testdauer-mit-einem-User mal Wiederholungen mal Anzahl User“ ist zu ungenau. Das Ergebnis entspricht sicher nicht der Realität, man kann das Ergebnis aber dazu verwenden ungefähr abzuschätzen, wie lange der Testdurchlauf dauern wird. In einem Projekt dauerte der Test mit 10 Benutzern und einem Durchlauf 65 Sekunden, laut Berechnung würde der Test mit 50 Benutzern und 5 Durchläufen  1625 Sekunden (etwa 27 Minuten) dauern. Tatsächlich waren es aber knapp 45 Minuten, da die Last höher war.

Bevor man sich in den Feierabend verabschiedet, sollte man nochmals das nun optimierte und fertige Skript mit der fehlerbereinigten Anwendung testen.

 

Checkliste für den Vormittag und Nachmittag

  • Testskript ist fertiggestellt und optimiert
    • Regular Expression sind verbessert
    • Timing Verhalten der Realität angepasst (je nach Anforderung)
    • Timing Verhalten ist konfigurierbar
    • AJAX Request Variablen wurden kontrolliert
    • Dokumente (Reports) sind vorbereitet
    • Termine für die Tests sind festgelegt

     

Donnerstag nächste Woche geht es weiter – Donnerstag ist Testtag!

 

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.