Software-Test / Testautomatisierung / Testmanagement

Last- und Performancetest in 5 Tagen – Freitag 6/6

Am Freitag werden die Testergebnisse analysiert und in einem Testreport zusammengefasst. In dem Report werden die Testresultate und vor allem die beobachteten Fehler beschrieben. Im Anschluss an die Analyse wird der Testreport dem Projektleiter präsentiert.

Last- und Performancetest Freitag_Testreport

Freitag

Wo sind wir am Donnerstag stehen geblieben? Das Skipt läuft fehlerfrei ab, der Startschuss für den Test durch den Projektleiter ist erfolgt, Daten wurden anaylsiert und gesichert sowie die Dauer jedes Tests erfasst.

Heute, am letzten Tag unseres Projekts „Last- und Performancetest in 5 Tagen“, werden die Lasttestergebnisse vom vorherigen Tag nochmals überprüft. Das Wichtigste hier ist die Beantwortung der Frage: „Wurden alle Tests durchgeführt?“. Die Testdurchläufe, die Fehler enthalten (wie „http Status Code 500“ o.ä.), werden nochmalig kurz angetestet. Sinn darin ist es sicherzugehen, dass das Resultat auch wirklich ein Fehler und nicht „einfach“ so passiert ist. Sollte es trotzdem funktionieren, kann man den einen (oder auch anderen) Test nochmals durchführen. Der Projektleiter wird informiert, dass ein Fehler gefunden wurde. Eine Fehlerkorrektur erfordert einen neuen Testdurchlauf.

Für die Analyse werden alle Lasttestergebnisse gesichtet und geordnet. Einige Tools (wie HP Loadrunner oder Neotys Neoload) bieten die Möglichkeit, Analysen im Tool selber durchzuführen. Bei anderen Tools (wie Apache JMeter) müssen (sollten) die Analysen mit einem externen Tool (wie Microsoft Excel) durchgeführt werden. Das Ziel der Analyse sind Grafiken bzw. Diagramme, die den Verlauf des Last- und Performancetests wiederspiegeln. Je nach geforderten Metriken, wie „Antwortzeiten“, “Fehlerrate“ oder „Durchsatz“, werden Diagramme bzw. Grafiken erzeugt. Ich persönlich finde, dass die Präsentation der Lasttestergebnisse genauso wichtig ist, wie der Test und die Vorbereitung. Schlecht gestaltete Diagramme, auf denen niemand etwas erkennt, sind auf jeden Fall zu unterlassen.

Grafiken (wie auch Screenshots) und Diagramme müssen immer erklärt werden. Der Leserin oder dem Leser muss sofort klar sein, worum es sich bei der Abbildung handelt. Es muss sofort erkennbar sein, ob es sich um „Antwortzeiten“ oder „Durchsatz Werte“ handelt. Die Abbildung sollte daher einen Titel haben und in der Achsenbeschriftung werden die verwendeten Einheiten (wie Millisekunden, kByte/sec, etc.)  genannt. Weiters wird im Fließtext die Abbildung erklärt; dazu reichen in den meisten Fällen ein paar Sätze aus.

Diagramme sollen verständlich sein, zum Beispiel sollten bei einem Verlauf von 30 Benutzern, nicht 30 Kurven in eine Grafik eingefügt werden, das macht das Diagramm unverständlich. Wird so eine Grafik trotzdem benötigt, könnte man daraus zwei Grafiken machen – eine zeigt den Verlauf der wichtigsten Ergebnisse (z.B.: Ausreißer und Durchschnittswerte), dazu kann man eine Klasseneinteilung machen, wie Antwortzeiten zwischen 0 und 1 Sekunde, zwischen 1 Sekunde und 2 Sekunden, etc.. Die zweite Grafik zeigt alle Benutzer – sie ist zwar weniger verständlich, wird aber durch die erste Grafik unterstützt und erklärt.

Im Report muss man unbedingt auf Fehler und verdächtige Vorkommnisse hinweisen und diese erklären. Zum Beispiel woran es liegen kann, wenn die Antwortzeit alle 5 Minuten für einen kurzen Moment stark ansteigt. Die Gründe können vielfältig sein, wie z.B. dass die Applikation die Datenbank reorganisiert, die Java Garbage Collection oder der Cache geleert wird, etc.. Das Ziel der Mutmaßungen ist, dem Projektleiter und der Entwicklung zu helfen, die grundlegenden Probleme zu erkennen. Auf jeden Fall sind Informationen wie Uhrzeit, Datum der Tests sowie Zeitpunkt des Auftretens des Problems zu nennen, denn nur so haben Entwickler eine Chance, in den Log Files den Zeitpunkt des Performanceeinbruchs zu lokalisieren. Der Testreport ist neben der dokumentarischen Funktion auch als Hilfestellung für Entwickler und Projektleiter zu sehen. Dabei soll jedes Problem aufgezeigt bzw. dargestellt werden.

Der Report beginnt mit einem Management Summary. Hier wird auf maximal 2 Seiten der Test plakativ analysiert. Die Erkenntnisse der wichtigsten Ergebnisse, zusammen mit 3 bis 5 Grafiken, werden hier präsentiert. Es werden nur die (wichtigsten) Ergebnisse beschrieben, wie z.B. Fehler oder Ausreißer, dabei kann das Szenario kurz präsentiert werden.

Das nächste Kapitel beinhalte eine detaillierte Beschreibung der Testdurchläufe. Der erste Punkt ist die Darstellung und genaue Beschreibung des Testszenarios inklusive der verwendeten Infrastruktur. Danach folgt eine Beschreibung der durchgeführten Tests, hier werden die Anzahl der Benutzer, Testwiederholungen und verwendete Infrastruktur der einzelnen Testdurchläufe beschrieben. Dabei sollte man besonders auf Probleme eingehen.

Das letzte Kapitel des Reports sollte „Nächste Schritte“ heißen und Tipps sowie Empfehlungen enthalten, welche Aufgaben bzw. Änderungen durchzuführen sind, damit das System stabiler bzw. performanter wird.

Der letzte Schritt ist es, den Testreport an den Projektleiter zu schicken und die Ergebnisse zu präsentieren.

 

Die Checkliste für Freitag

  • Daten wurden analysiert
  • Vorbereitung für Management Summary und Testreport sind abgeschlossen
  • Verbesserungsvorschläge sind erarbeitet worden
  • Dokumente wurden finalisiert
  • Ergebnisse wurden präsentiert
  • Dokumente wurden versendet

 

Epilog

Nach dem Abschluss der Tests ist es Zeit, die erfolgten Tätigkeiten nochmals Revue passieren zu lassen. Dieses Review dient dazu, Probleme zu identifizieren. Aus diesen leitet man Verbesserungsvorschläge ab. Die kontinuierliche Einarbeitungen der Verbesserungen dient dazu, den Last- und Performancetest zu optimieren. Die Optimierungen dienen einer generellen Qualitätsverbesserung der Tests.  Eine weitere Qualitätssteigerung wird mit dem Ausarbeiten der Lessons-Learned Erkenntnisse erreicht. Die Erkenntnisse über mehrere Last- und Performanceprojekte hinweg, führen zu neuen Ideen, wie die Tests strukturell verbessert werden können. Die erarbeiteten Best-Practice Methoden dienen als Grundlage für nächste Projekte, sie beschreiben bewährte und optimale Vorgehensweisen.

Ein 5-Tage Last- und Performancetest dient vor allem dazu, eine Anwendung in kurzer Zeit zu überprüfen, damit das Projektteam ein Feedback bekommt, wie sich die Anwendung unter Last verhält. Zukünftige Benutzer wollen keine „Stunden“ auf ein Ergebnis der Anwendung warten. Lange Wartezeiten sind zu vermeiden und können mit einem Last- und Performancetest erkannt werden. Dies erhöht das Image der Anwendung und des Projektteams und damit die Chance, dass die Benutzer die Anwendung weiterhin benutzen. Vor dem Live-Gang sollte man die Applikation auf dem Echtsystem mit einem „großen“ Last- und Performancetest auf Herz und Nieren testen.

Last- und Performancetests in 5 Tagen können überaus gewinnbringend sein. Haben Sie bereits welche durchgeführt? Teilen Sie hier gerne mit den Lesern und mir Ihre Erfahrungen – ich freue mich auf einen Austausch!

 

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.