Zielbasierte Leistungstests

Zielbasierte Leistungstests sind eine Strategie, die beim Testen von Software, insbesondere bei Leistungstests, eingesetzt wird, um sicherzustellen, dass Softwaresysteme bestimmte Leistungsziele unter verschiedenen Bedingungen erfüllen. Bei zielbasierten Leistungstests wird der Testprozess von vordefinierten Zielen oder Vorgaben gesteuert und nicht nur um ihrer selbst willen.

Zielbasiertes Testen funktioniert mit den folgenden Schritten:

1. Definition von Leistungszielen: Im ersten Schritt wird definiert, welche Leistungsziele für das zu testende Softwaresystem wichtig sind. Zu diesen Zielen können Schwellenwerte für die Antwortzeit, Durchsatzanforderungen, Ressourcenauslastungsziele und Skalierbarkeitsbenchmarks gehören.
2. Entwerfen von Testszenarien: Testszenarien werden basierend auf Ihren definierten Leistungszielen entworfen. Diese Szenarien simulieren unterschiedliches Benutzerverhalten, Lasten und Systemkonfigurationen, um die Leistung der Software unter verschiedenen Bedingungen zu bewerten. Szenarien können z. B. Spitzenauslastungszeiten, hohe Transaktionslasten oder plötzliche Spitzen in der Benutzeraktivität umfassen.
3. Ausführen von Tests: Testszenarien werden für das Softwaresystem unter den Testanforderungen ausgeführt. In dieser Phase werden Leistungskennzahlen wie Antwortzeiten, Durchsatz, Ressourcenauslastung und Systemskalierbarkeit gemessen und überwacht.
4. Analyse der Ergebnisse und Verbesserungen: Die gesammelten Leistungsdaten werden analysiert, um zu beurteilen, ob das System die vordefinierten Ziele erreicht. Diese Analyse hilft bei der Identifizierung von Leistungsengpässen, Skalierbarkeitseinschränkungen und Bereichen, in denen das System die Leistungsanforderungen möglicherweise nicht erfüllt. Nehmen Sie auf der Grundlage der Analyse der Testergebnisse alle erforderlichen Verbesserungen und Optimierungen an Ihrem Softwaresystem vor.
5. Wiederholung des Vorgangs: Zielbasierte Leistungstests sind ein iterativer Prozess. Nachdem Verbesserungen vorgenommen wurden, wird der Testzyklus wiederholt, um zu überprüfen, ob die Leistungsziele erreicht wurden, und um neue Leistungsprobleme zu identifizieren, die möglicherweise aufgetreten sind.

Performance-Tests konzentrieren sich in erster Linie auf die Überprüfung der Geschwindigkeit und Zuverlässigkeit einer Anwendung, unterteilt in Lasttests (die zielorientiert sind) und Stresstests. Mit dem Aufkommen agiler Entwicklungsmethoden ist es entscheidend geworden, sicherzustellen, dass die Ergebnisse von Lasttests leicht reproduziert werden können.

Die Bedeutung der Definition von Leistungszielen

Die Definition von Leistungszielen ist der Eckpfeiler zielorientierter Leistungstests. Diese Ziele dienen als Maßstab, an dem die Leistung der Software gemessen wird. Sie bieten einen greifbaren Rahmen für die Beurteilung, ob die Software ihre Leistungsanforderungen unter verschiedenen Bedingungen erfüllt, einschließlich normaler Nutzung, Spitzenlasten und Belastungsszenarien.

Hauptgründe für zielbasierte Leistungstests

• Ausrichtung auf die Erwartungen der Stakeholder: Durch die Definition spezifischer Leistungsziele stellen Sie sicher, dass die Leistung Ihrer Software mit den Erwartungen der Beteiligten, einschließlich Endbenutzern, Kunden und Projektsponsoren, übereinstimmt.
• Validieren der Leistungsanforderungen: Zielbasierte Tests helfen bei der Überprüfung, ob Ihre Software die Leistungsanforderungen erfüllt, und liefern konkrete Metriken zur Bewertung der Leistungsangemessenheit.
• Optimierung der Ressourcenauslastung: Zielbasiertes Testen hilft bei der Optimierung der Ressourcenauslastung, indem Ineffizienzen oder eine Überauslastung der Systemressourcen identifiziert werden, was zu einer effizienteren Ressourcenzuweisung und Kosteneinsparungen führt.
• Skalierbarkeit: Durch die Messung der Leistung bei zunehmender Auslastung oder Benutzerparallelität wird bei zielbasierten Tests die Skalierbarkeit Ihrer Software bewertet, um sicherzustellen, dass sie wachsende Benutzergruppen und Workloads bewältigen kann.
• Minderung von Risiken: Proaktives Testen anhand vordefinierter Leistungsziele hilft dabei, leistungsbezogene Risiken vor der Bereitstellung der Software zu identifizieren und zu mindern, wodurch die Wahrscheinlichkeit von Ausfallzeiten, Benutzerunzufriedenheit oder finanziellen Verlusten verringert wird.

Zielbasierter Anwendungsfall: Problemstellung

Angenommen, 20 gleichzeitige Benutzer generieren stündlich 2.000 Transaktionen in Ihrer neuen CRM-Anwendung. Ihr Ziel ist es, einen Leistungstest zu entwickeln, der eine Reaktionszeit von acht Sekunden für die nächsten vier Versionen sicherstellt. Belastungstests replizieren möglicherweise nicht genau den erwarteten Durchsatz in diesen kommenden Versionen, da die Antwortzeiten von der aktuellen Version abweichen können.

Zielbasierter Anwendungsfall: Lösung

1. Integrieren Sie ThinkTimes in Ihre Skripte, um Pausen zwischen Benutzeraktionen einzuführen.
2. Bestimmen Sie die Baseline, und messen Sie die Laufzeit von Einzelbenutzerskripts, um die Sitzungszeit zu berechnen.
3. Konfigurieren Sie die Workload-Parameter, einschließlich der maximalen Benutzerzahl, der zielbasierten Transaktionsrate und der zielbasierten Transaktionszeit.
4. Führen Sie den zielbasierten Leistungstest aus, um die erwartete Auslastung der Anwendung zu simulieren.
5. Überprüfen Sie den Testbericht, um zu überprüfen, ob die Anwendung die Last innerhalb der vordefinierten Antwortzeitgrenzen bewältigen konnte.
6. Wiederholen Sie den Testlauf in den folgenden vier Versionen, um zu bewerten, ob die Anwendung die Schwellenwerte für Durchsatz und Antwortzeit im Laufe der Zeit beibehält.

Empfehlungen und Tipps für die Konfiguration des EveryStep-Tools von LoadView

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 es sich bei den zulässigen Werten um Gleitkommazahlen von 0,0 bis 999,99 handelt.
• Erlauben Sie Benutzern, ThinkTimes manuell zu Skripten hinzuzufügen.
• Denken Sie daran, dass ThinkTimes Wartezeiten darstellt und von EveryStep Web Recorder während der Aufzeichnung von Benutzeraktionen automatisch hinzugefügt wird.
• In einem Skript können mehrere ThinkTimes vorhanden sein.
• ThinkTimes werden in einzelnen Skript-Testläufen nicht berücksichtigt.
• ThinkTimes wird in Calibration/Get Baseline verwendet.
• ThinkTimes tragen nicht zur Messung der Reaktionszeit bei.
• ThinkTimes werden in Stresstests ignoriert.

Benutzerparallelität (optional):

• Führen Sie ein neues Schlüsselwort “WaitFor (Anzahl der Benutzer)” im EveryStep Web Recorder ein.
• Dieser globale Wartepunkt blockiert simulierte Benutzer in einem bestimmten Skriptabschnitt, bis die erwartete Anzahl von Benutzern diesen Teil des Skripts erreicht.

Schwellenwerte für die Reaktionszeit (optional):

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

Baseline/Kalibrierung (erforderlich):

• LoadView führt einen Testlauf für einen einzelnen Benutzer aus.
• ThinkTimes wird als Skript verwendet.
• LoadView berechnet die Sitzungszeit: Sitzungszeit = Skriptausführungszeit + ThinkTime.

Konfigurieren des Workload-/Ausführungsplans (erforderlich):

• Kunden geben die Anlaufzeit an.
• Kunden definieren ihre Zieltransaktionsrate.
• Kunden legen die Zielsitzungszeit fest.
• Das System berechnet die Anzahl der Benutzer.
• Kunden entscheiden, ob sie die Reaktionszeiten während des Hochlaufs berechnen oder nicht.

Test ausführen (erforderlich):

• LoadView führt den Test gemäß dem konfigurierten Workload-/Ausführungsplan aus.
• LoadView sammelt Antwortzeiten von simulierten Skripts oder Transaktionen.
• LoadView passt ThinkTime dynamisch an, um den erwarteten Durchsatz zu erreichen. Wenn die zu testende Anwendung langsamer wird, werden die ThinkTimes reduziert. Wenn ThinkTimes Null ist und die Sitzungszeit die Zielsitzungszeit überschreitet, wird eine Fehlermeldung ausgegeben, die angibt, dass der erwartete Durchsatz nicht erreicht werden konnte.
• LoadView berechnet Die Antwortzeiten aktueller Transaktionen und Timer ohne ThinkTimes.

Empfehlungen und Tipps für die Integration mit Dotcom-Monitor

EveryStep Web Recorder

• Wir stellen neue ThinkTime-Schlüsselwörter vor.
• Ignorieren Sie ThinkTime während Einzelbenutzer-Testläufen.
• Fügen Sie ThinkTime während der Skriptaufzeichnung hinzu.
• Führen Sie das neue Schlüsselwort WaitFor(Number user) ein.
• Führen Sie das neue Schlüsselwort SetBoundary(TimerName, B1, B2) ein.
• Das WaitFor-Schlüsselwort muss manuell zu erstellten Skripts hinzugefügt werden.
• Verwenden Sie das Schlüsselwort SetBoundary.

Kalibrierung/Basislinie abrufen

• Berechnen Sie die Sitzungszeit während der Kalibrierung.

Ausführungsplan/Workload

Option 1:

• Fügen Sie eine neue Workload-Konfigurationsfunktion hinzu.
• Ersetzen Sie den Ausführungsplan durch die Workload-Funktion.
• Erstellen Sie ein Dialogfeld für die Workload-Konfiguration, um Belastungstests, Transaktionsziele und andere Typen zu unterstützen.
• Geben Sie die Anlaufzeit an.
• Aktivieren Sie das Kontrollkästchen zur Berechnung der Antwortzeiten während des Hochlaufs (ja/nein).

Option 2:

• Verwenden Sie die erweiterte Konfigurationsfunktion für Ausführungspläne.
• Wählen Sie den Testtyp (Stress, zielbasiert) aus.
• Legen Sie die Details des Transaktionsziels fest.
• Geben Sie die Anlaufzeit an.
• Aktivieren Sie das Kontrollkästchen zur Berechnung der Antwortzeiten während des Hochlaufs (ja/nein).

Ausführen des Tests

• Berechnen Sie die tatsächliche Skriptausführungszeit/Sitzungszeit.
• Passen Sie ThinkTimes dynamisch an die tatsächliche Sitzungszeit an.
• Geben Sie eine Warnung aus, wenn der erwartete Durchsatz nicht erreicht werden konnte.

Bericht

• Konfigurieren Sie einen Abschnitt für die Reaktionszeit, Ist- und Schwellenwerte pro Timer.
• Konfigurieren Sie einen Abschnitt für den Durchsatz, den tatsächlichen und den erwarteten Durchsatz.

Tipps zur Integration mit Dotcom-Monitor: FAQ

Was sind die Benutzereingaben?

• ThinkTimes (Floating Point, > 0)
• Zieltransaktionen pro Stunde (Ganzzahl)
• Maximale Anzahl von Benutzern (Ganzzahl)
• Ramp-Up-Zeit (Minuten)
• Berechnen der Reaktionszeit während des Hochfahrens (Ja / Nein)

Was ist Baseline?

Eine Ausführung des Geräts oder Skripts durch einen einzelnen Benutzer, die ThinkTimes enthält. Die Ausführungszeit des Skripts wird als Sitzungszeit berechnet und gespeichert, zusammen mit zusätzlichen Details wie den erforderlichen Ausführungsressourcen.

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

• Berechnen der Sitzungszeit während der Kalibrierung
• Verwenden von ThinkTimes zum Erreichen der angeforderten Zielsitzungszeit
• Aktuelle Sitzungszeit während der Testausführung neu berechnen
• Dynamischeanpassung von ThinkTimes in Abhängigkeit von der tatsächlichen Sitzungszeit
• Protokollmeldung, wenn die Skriptausführungszeit > Zielsitzungszeit ist
• Geben Sie die Anzahl der maximalen Benutzer in der Arbeitsauslastungsberechnung an.

Was ist das WaitFor-Schlüsselwort?

Dadurch werden komplexe Benutzerszenarien simuliert, insbesondere Parallelitätssituationen, was nützlich ist, um zu testen, ob bestimmte Funktionen ordnungsgemäß funktionieren, wenn mehrere Benutzer gleichzeitig auf eine Ressource zugreifen.

Was ist das SetBoundary-Schlüsselwort?

Hilft bei der Überprüfung der tatsächlichen Geschwindigkeit einer bestimmten Aktion oder eines bestimmten Timers anhand der angegebenen SLA-Antwortzeitgrenzen. Wenn die zulässige Grenze verletzt wird, wird eine Fehlermeldung angezeigt und im Testbericht protokolliert, wodurch die SLA-Überprüfung vereinfacht wird.

Was sollten Ihre Ziele für Ihren Auslastungstest sein?

• Stellen Sie 100 Prozent vergleichbare Leistungstests über verschiedene Releases/Ausführungen hinweg sicher.
• Fügen Sie Funktionen zur Simulation von normalen oder Spitzenlastmustern hinzu.
• Schaffen Sie Gewissheit, dass das zu testende System die erwartete Last innerhalb der vereinbarten Grenzen bewältigen kann.
• Konzentrieren Sie sich bei der Leistungsoptimierung auf Benutzeraktionen, die vereinbarte Grenzen verletzen.

Welche Art von Berichten sollten Sie konfigurieren?

• Erstellen Sie Berichte, die den aktuellen Berichten ähneln.
• Schließen Sie durchschnittliche, minimale, maximale, stddev- und Perzentil-Antwortzeiten ein.
• Verfolgen Sie Transaktionen in Ordnung, fehlgeschlagene Transaktionen und Fehlerrate.
• Alle Antwortzeiten sollten ohne die Einbeziehung von ThinkTimes angegeben werden.

Einschränkungen

Hohe Zielsitzungszeiten können zu Sitzungszeitüberschreitungen und Fehlalarmen führen. Es ist wichtig, Szenarien in Betracht zu ziehen, in denen die Zeitüberschreitungen für Websitzungen niedrig sind, um sicherzustellen, dass die ThinkTimes angemessen platziert sind, um Fehler aufgrund von Sitzungszeitüberschreitungen zu vermeiden.

Was passiert, wenn wir das Ziel nicht erreichen?

• Wenn sich die Antwortzeit einer Anwendung, die einem Auslastungstest unterzogen wird, verlangsamt und die Sitzungszeit die Zielsitzungszeit überschreitet, kann die erwartete Transaktionsrate nicht erreicht werden.
• LoadView überwacht die tatsächliche Sitzungszeit während der Testausführung und passt ThinkTimes an, um zu versuchen, die erwartete zielbasierte Transaktionsrate zu erreichen.
• LoadView zeigt Fehlermeldungen auf dem Überwachungsbildschirm an, wenn die Sitzungszeit die Zielsitzungszeit überschreitet.
• LoadView setzt die Testausführung fort, wenn die angestrebte Transaktionsrate nicht erreicht werden kann, markiert den Testlauf als fehlgeschlagen und zeigt betroffene Geräte im Bericht an.

Wie sieht eine beispielzielbasierte Workload aus?

• Anlaufzeit: 15 Minuten
• Messen Der Reaktionszeiten während des Hochfahrens: Ja / Nein
  ST: Sitzungszeit
• GST: Zielsitzungszeit
• TPH: Transaktionen pro Stunde
• Benutzer: Berechnet von LoadView (3600 / TPH) * GST = 72