Zielbasierte Leistungstests

Zielorientiertes Performancetesting ist eine Strategie, die im Softwaretesting, insbesondere Performancetesting, eingesetzt wird, um sicherzustellen, dass Softwaresysteme unter verschiedenen Bedingungen bestimmte Leistungsziele erfüllen. Beim zielorientierten Performancetesting wird der Testprozess von vordefinierten Zielen oder Vorgaben gesteuert und nicht einfach nur zum Testzweck durchgeführt.

Zielorientiertes Testing funktioniert mit den folgenden Schritten:

1. Definition von Performance-Zielen: Der erste Schritt besteht darin, festzulegen, welche Performance-Ziele für das zu testende Softwaresystem wichtig sind. Diese Ziele können Antwortzeitgrenzen, Durchsatzanforderungen, Ressourcennutzungsvorgaben und Skalierbarkeitskennzahlen umfassen.
2. Design von Testszenarien: Basierend auf den definierten Leistungszielen werden Testszenarien entworfen. Diese Szenarien simulieren verschiedene Nutzerverhaltensweisen, Lasten und Systemkonfigurationen, um zu bewerten, wie die Software unter unterschiedlichen Bedingungen funktioniert. Beispielhafte Szenarien umfassen Spitzenlastzeiten, hohe Transaktionslasten oder plötzliche Anstiege der Benutzeraktivität.
3. Durchführung der Tests: Die Testszenarien werden auf das Softwaresystem entsprechend den Testanforderungen ausgeführt. Dabei werden Leistungskennzahlen wie Antwortzeiten, Durchsatz, Ressourcenauslastung und Systemskalierbarkeit gemessen und überwacht.
4. Analyse der Ergebnisse und Optimierung: Die gesammelten Leistungsdaten werden analysiert, um zu prüfen, ob das System die vordefinierten Ziele erfüllt. Diese Analyse hilft, Engpässe, Skalierbarkeitsgrenzen und Bereiche zu erkennen, in denen das System die Leistungsanforderungen nicht erreichen kann. Basierend auf der Analyse der Testergebnisse werden notwendige Verbesserungen und Optimierungen des Softwaresystems vorgenommen.
5. Wiederholung des Prozesses: Zielorientiertes Performancetesting ist ein iterativer Prozess. Nach den Verbesserungen wird der Testzyklus wiederholt, um zu validieren, ob die Leistungsziele erreicht wurden und um neue potenzielle Leistungsprobleme zu identifizieren.

Performance-Tests konzentrieren sich hauptsächlich auf die Überprüfung der Geschwindigkeit und Zuverlässigkeit einer Anwendung, aufgeteilt in Lasttests (die zielorientiert sind) und Stresstests. Mit dem Aufkommen agiler Entwicklungsmethoden ist es entscheidend geworden, dass Lasttestergebnisse leicht reproduzierbar sind.

Die Bedeutung der Definition von Performance-Zielen

Die Definition von Performance-Zielen ist der Grundpfeiler des zielorientierten Performancetests. Diese Ziele dienen als Maßstab, anhand dessen die Leistung der Software gemessen wird. Sie bieten einen greifbaren Rahmen, um zu bewerten, ob die Software ihre Leistungsanforderungen unter verschiedenen Bedingungen erfüllt, einschließlich Normalbetrieb, Spitzenlasten und Stresssituationen.

Wesentliche Gründe für zielorientiertes Performancetesting

• Ausrichtung an den Erwartungen der Stakeholder: Durch die Definition spezifischer Leistungsziele wird sichergestellt, dass die Leistung der Software den Erwartungen der Stakeholder entspricht, einschließlich Endnutzern, Kunden und Projektförderern.
• Validierung der Leistungsanforderungen: Zielorientiertes Testing hilft dabei zu überprüfen, ob die Software ihre Leistungsanforderungen erfüllt und liefert konkrete Kennzahlen zur Bewertung der Angemessenheit der Leistung.
• Optimierung der Ressourcennutzung: Zielorientiertes Testing hilft, die Ressourcennutzung zu optimieren, indem Ineffizienzen oder Überbeanspruchung von Systemressourcen erkannt werden, was zu effizienterer Ressourcenzuteilung und Kosteneinsparungen führt.
• Skalierbarkeit: Durch die Messung der Leistung bei zunehmenden Lasten oder gleichzeitigen Benutzern bewertet das zielorientierte Testing die Skalierbarkeit Ihrer Software und stellt sicher, dass sie wachsende Benutzerzahlen und Lasten bewältigen kann.
• Risikominderung: Durch proaktives Testen anhand vordefinierter Leistungsziele lassen sich leistungsbezogene Risiken vor der Softwareeinführung identifizieren und mindern, was die Wahrscheinlichkeit von Ausfällen, Unzufriedenheit bei Nutzern oder finanziellen Verlusten reduziert.

Zielorientierter Anwendungsfall: Problem

Angenommen, 20 gleichzeitige Benutzer generieren in Ihrer neuen CRM-Anwendung stündlich 2.000 Transaktionen. Ihr Ziel ist es, einen Performancetest zu entwickeln, der eine Antwortzeit von acht Sekunden für die nächsten vier Releases sicherstellt. Stresstests können den erwarteten Durchsatz in diesen kommenden Releases nicht exakt nachbilden, da die Antwortzeiten von der aktuellen Version abweichen können.

Zielorientierter Anwendungsfall: Lösung

1. Integrieren Sie ThinkTimes in Ihre Skripte, um Pausen zwischen Benutzeraktionen einzufügen.
2. Bestimmen Sie die Basislinie und messen Sie die Laufzeit der Einzelnutzerskripte, um die Sitzungsdauer zu berechnen.
3. Konfigurieren Sie die Lastparameter, einschließlich der maximalen Benutzerzahl, der zielbasierten Transaktionsrate und der zielbasierten Transaktionszeit.
4. Führen Sie den zielorientierten Performancetest durch, um die erwartete Last auf die Anwendung zu simulieren.
5. Überprüfen Sie den Testbericht, um zu verifizieren, ob die Anwendung die Last innerhalb der vordefinierten Antwortzeitgrenzen bewältigt hat.
6. Wiederholen Sie den Testlauf in den folgenden vier Releases, um zu beurteilen, ob die Anwendung die Durchsatz- und Antwortzeitgrenzen im Zeitverlauf einhält.

Empfehlungen und Tipps zur Konfiguration des LoadView EveryStep Tools

ThinkTime (erforderlich):

• Erstellen Sie neue Schlüsselwörter im EveryStep Web Recorder (ThinkTimes) oder verwenden Sie vorhandene Schlüsselwörter wieder.
• Stellen Sie sicher, dass zulässige Werte Fließkommazahlen von 0.0 bis 999.99 sind.
• Ermöglichen Sie Benutzern, ThinkTimes manuell zu Skripten hinzuzufügen.
• Denken Sie daran, dass ThinkTimes Wartezeiten darstellen und automatisch vom EveryStep Web Recorder während der Aufzeichnung von Benutzeraktionen hinzugefügt werden.
• Mehrere ThinkTimes können in einem Skript existieren.
• ThinkTimes werden bei Einzel-Skript-Testläufen ignoriert.
• ThinkTimes werden bei Kalibrierung/Ermittlung der Basislinie verwendet.
• ThinkTimes zählen nicht zur Messung der Antwortzeiten.
• ThinkTimes werden in Stresstests ignoriert.

Benutzer-Konkurrenz (optional):

• Fügen Sie ein neues Schlüsselwort „WaitFor (Anzahl Benutzer)“ im EveryStep Web Recorder hinzu.
• Dieser globale Wartepunkt blockiert simulierte Benutzer an einer bestimmten Skriptstelle, bis die erwartete Benutzeranzahl diese Stelle erreicht hat.

Antwortzeit-Grenzwerte (optional):

• Implementieren Sie das neue SetBoundary-Schlüsselwort im EveryStep Web Recorder.
• Syntax: SetBoundary(Timername, Grenze 1, Grenze 2).

Basislinie/Kalibrierung (erforderlich):

• LoadView führt einen Einzelbenutzertest durch.
• ThinkTimes werden wie im Skript verwendet.
• LoadView berechnet die Sitzungsdauer: Sitzungsdauer = Skriptausführungszeit + ThinkTime.

Konfiguration der Last/Ausführungsplans (erforderlich):

• Kunden geben die Hochfahrzeit (Ramp-up) an.
• Kunden definieren ihre Ziel-Transaktionsrate.
• Kunden legen die Ziel-Sitzungszeit fest.
• Das System berechnet die Benutzeranzahl.
• Kunden entscheiden, ob die Antwortzeiten während der Hochfahrzeit berechnet werden sollen.

Testlauf (erforderlich):

• LoadView führt den Test gemäß der konfigurierten Last/Ausführungsplan aus.
• LoadView sammelt Antwortzeiten der simulierten Skripte oder Transaktionen.
• LoadView passt ThinkTime dynamisch an, um den erwarteten Durchsatz zu erreichen; wenn die zu testende Anwendung langsamer wird, werden ThinkTimes reduziert. Sind ThinkTimes null und die Sitzungsdauer überschreitet die Ziel-Sitzungszeit, erscheint eine Fehlermeldung, dass der erwartete Durchsatz nicht erreicht werden konnte.
• LoadView berechnet die Antwortzeiten der tatsächlichen Transaktionen und Timer ohne ThinkTimes.

Empfehlungen und Tipps zur Integration mit Dotcom-Monitor

EveryStep Web Recorder

• Neue ThinkTime-Schlüsselwörter einführen.
• ThinkTime während Einzelbenutzertestläufen ignorieren.
• ThinkTime während der Skripterstellung hinzufügen.
• Neues WaitFor(Anzahl Benutzer)-Schlüsselwort einführen.
• Neues SetBoundary(TimerName, B1, B2)-Schlüsselwort einführen.
• Das WaitFor-Schlüsselwort muss manuell in erstellte Skripte eingefügt werden.
• SetBoundary-Schlüsselwort verwenden.

Kalibrierung/Ermittlung der Basislinie

• Sitzungsdauer während der Kalibrierung berechnen.

Ausführungsplan/Arbeitslast

Option 1:

• Neue Workload-Konfigurationsfunktion hinzufügen.
• Ausführungsplan durch Workload-Funktion ersetzen.
• Ein Workload-Konfigurationsdialog zur Unterstützung von Stresstests, Transaktionszielen und anderen Typen erstellen.
• Hochfahrzeit (Ramp-up) angeben.
• Checkbox für Berechnung der Antwortzeiten während Ramp-up (Ja/Nein) setzen.

Option 2:

• Erweiterte Ausführungsplankonfigurationsfunktion nutzen.
• Testtyp (Stress, zielorientiert) auswählen.
• Transaktionsziel-Details festlegen.
• Hochfahrzeit angeben.
• Checkbox für Berechnung der Antwortzeiten während Ramp-up (Ja/Nein) setzen.

Testlauf

• Tatsächliche Skript-Ausführungszeit/Sitzungsdauer berechnen.
• ThinkTimes basierend auf der tatsächlichen Sitzungsdauer dynamisch anpassen.
• Warnung ausgeben, wenn der erwartete Durchsatz nicht erreicht werden konnte.

Bericht

• Abschnitt für Antwortzeit, tatsächlich vs. Grenzwerte pro Timer konfigurieren.
• Abschnitt für Durchsatz, tatsächlich vs. erwartet konfigurieren.

Tipps zur Integration mit Dotcom-Monitor: FAQ

Was sind die Benutzereingaben?

• ThinkTimes (Fließkommazahl, >0)
• Ziel-Transaktionen pro Stunde (Ganzzahl)
• Maximale Benutzeranzahl (Ganzzahl)
• Ramp-up-Zeit (Minuten)
• Berechnung der Antwortzeit während Ramp-up (Ja / Nein)

Was ist die Basislinie?

Einzelbenutzer-Ausführung des Geräts oder Skripts unter Einbeziehung von ThinkTimes. Die Skript-Ausführungszeit wird berechnet und als Sitzungszeit gespeichert, zusammen mit weiteren Details wie benötigten Ausführungsressourcen.

Wie können Sie den Lasttest dynamisch anpassen, wenn sich die Transaktionsgeschwindigkeit auf dem Zielsystem ändert?

• Sitzungsdauer während der Kalibrierung berechnen
• ThinkTimes verwenden, um die gewünschte Ziel-Sitzungszeit zu erreichen
• Tatsächliche Sitzungsdauer während der Testdurchführung neu berechnen
• ThinkTimes dynamisch abhängig von der tatsächlichen Sitzungsdauer anpassen
• Fehlermeldung protokollieren, wenn die Skriptausführungszeit die Ziel-Sitzungszeit überschreitet
• Maximale Benutzerzahl in der Workload-Berechnung angeben

Was ist das WaitFor-Schlüsselwort?

Dies simuliert komplexe Benutzerszenarien, insbesondere Konkurrenzsituationen, die nützlich sind, um zu testen, ob bestimmte Funktionen korrekt arbeiten, wenn mehrere Benutzer gleichzeitig auf eine Ressource zugreifen.

Was ist das SetBoundary-Schlüsselwort?

Hilft, die tatsächliche Geschwindigkeit einer bestimmten Aktion oder eines Timers gegen festgelegte SLA-Antwortzeitgrenzen zu überprüfen. Wird eine erlaubte Grenze verletzt, erscheint eine Fehlermeldung, die im Testbericht protokolliert wird, was die SLA-Überprüfung vereinfacht.

Was sollten Ihre Ziele für Ihren Lasttest sein?

• 100 Prozent vergleichbare Performance-Tests über verschiedene Releases/Ausführungen hinweg sicherstellen.
• Funktionen zur Simulation von regulären oder Spitzenlastmuster einschließen.
• Vertrauen gewinnen, dass das System unter Test die erwartete Last innerhalb der vereinbarten Grenzen bewältigt.
• Performance-Optimierung auf Benutzeraktionen fokussieren, die vereinbarte Grenzen überschreiten.

Welche Art von Berichten sollten Sie konfigurieren?

• Berichte ähnlich zu aktuellen Berichten erstellen.
• Enthalten Sie Durchschnitts-, Minimal-, Maximal-, Standardabweichungs- und Perzentil-Antwortzeiten.
• Verfolgen Sie Transaktionen erfolgreich, Transaktionen fehlgeschlagen und Fehlerrate.
• Alle Antwortzeiten sollten ohne Einbeziehung von ThinkTimes sein.

Beschränkungen

Hohe Ziel-Sitzungszeiten können zu Sitzungstimeouts und falsch-positiven Ergebnissen führen. Es ist wichtig, Szenarien zu berücksichtigen, in denen Websitzungstimeouts kurz sind, und sicherzustellen, dass ThinkTimes sinnvoll gesetzt sind, um Ausfälle durch Sitzungstimeouts zu verhindern.

Was passiert, wenn das Ziel nicht erreicht wird?

• Wenn die Antwortzeit einer Anwendung unter Last langsamer wird und die Sitzungszeit die Ziel-Sitzungszeit überschreitet, kann die erwartete Transaktionsrate nicht erreicht werden.
• LoadView überwacht die tatsächliche Sitzungszeit während der Testdurchführung und passt die ThinkTimes an, um die erwartete zielbasierte Transaktionsrate zu erreichen.
• LoadView zeigt Fehlermeldungen auf dem Überwachungsbildschirm an, wenn die Sitzungszeit die Ziel-Sitzungszeit überschreitet.
• LoadView führt den Test weiter aus, wenn die Ziel-Transaktionsrate nicht erreicht werden kann, markiert den Testlauf jedoch als fehlgeschlagen und weist im Bericht betroffene Geräte aus.

Wie sieht eine Beispiel-Workload für zielorientiertes Testing aus?

•  Hochfahrzeit: 15 Minuten
• Antwortzeiten während Hochfahrt messen: Ja / Nein
  ST: Sitzungszeit
• GST: Ziel-Sitzungszeit
• TPH: Transaktionen pro Stunde
• Benutzer: Von LoadView berechnet (3600 / TPH) * GST = 72