Leistungstests überprüfen hauptsächlich die Geschwindigkeit und Zuverlässigkeit einer Anwendung und sind in Belastungstests (zielbasiert) und Belastungstestsunterteilt. Seit dem Aufkommen agiler Entwicklungsmethoden hat die Reproduktion von Auslastungstestergebnissen oberste Priorität.

Was sind Gründe für Stresstests?

Die einfachste Möglichkeit zum Konfigurieren von Leistungstests besteht darin, dass eine Reihe von Benutzern Testskripts iterativ ausführen können. Diese Art von Test wird als Stresstest bezeichnet und wird häufig verwendet, um Sollbruchstellen in Geschäftsanwendungen zu identifizieren. Der Nachteil ist, dass die tatsächliche Reaktionszeit Ihrer Anwendung hauptsächlich für die simulierte Last verantwortlich ist und Sie den tatsächlichen Durchsatz nicht steuern können. Bei Skalierbarkeitstests ist dies kein Problem, aber für einen Leistungsvergleich zwischen verschiedenen Versionen kann es problematisch sein.

Was sind die Gründe für zielbasierte Leistungstests?

Der Hauptvorteil dieser Art von Tests besteht darin, dass sie Geschwindigkeitsmessungen unter realistischen, reproduzierbaren Bedingungen und Durchsatzgrenzen ermöglicht. Zielbasierte Leistungstests werden häufig verwendet, um Service Level Agreements in produktionsähnlichen Umgebungen zu validieren.

Berücksichtigen Sie die folgende Situation:

Nehmen wir an, dass 20 gleichzeitige Benutzer 2.000 Transaktionen in Ihrer neuen CRM-Anwendung pro Stunde erstellen. Sie haben die Aufgabe, einen Leistungstest zu erstellen, der überprüft, ob die Antwortzeit von acht Sekunden für diese Anwendung in den nächsten vier Versionen erreicht werden kann. Ein Stresstest lässt höchstwahrscheinlich keine genaue Simulation des erwarteten Durchsatzes in Den vier Release-Leistungstests zu, da Sie nicht davon ausgehen können, dass die Reaktionszeit die gleiche bleibt wie in Ihrer tatsächlichen Version.

Lösung:

1. Hinzufügen von ThinkTimes zu Ihren Skripts
2. Suchen der Baseline- und Einzelbenutzerskriptlaufzeit, um die Sitzungszeit zu erhalten
3. Konfigurieren der Arbeitsauslastung, einschließlich maximaler Benutzer, zielbasierter Transaktionsrate und zielbasierter Transaktionszeit
4. Führen Sie den zielbasierten Leistungstest aus, um die erwartete Last zu simulieren
5. Überprüfen Sie den Testbericht, und überprüfen Sie, ob die zu testende Anwendung in der Lage war, die Last innerhalb der vereinbarten Reaktionszeitgrenzen zu bewältigen
6. Wiederholen Sie diesen Testlauf in den nächsten vier Versionen, und überprüfen Sie, ob Ihre Anwendung Inder- und Reaktionszeitschwellen halten konnte.

Tipps zum Konfigurieren des EveryStep-Tools

ThinkTime (erforderlich)

Erstellen Neuer Keywords im EveryStep Web Recorder (ThinkTimes) oder Wiederverwenden vorhandener Keywords

Sicherstellen, dass zulässige Werte Gleitkommawerte 0,0 – 999,99 sind

Sicherstellen, dass Benutzer ThinkTimes manuell zu Skripts hinzufügen können

Denken Sie daran, dass ThinkTimes Wartezeiten sind und von EveryStep Web Recorder automatisch während der Aufzeichnung von Benutzeraktionen hinzugefügt werden.

Es kann N ThinkTimes in einem Skript geben

ThinkTimes werden in einzelnen Skripttestläufen ignoriert

ThinkTimes wird in Calibration / Get Baseline verwendet

ThinkTimes sind nicht Teil von Reaktionszeitmessungen

ThinkTimes werden in Stresstests ignoriert

Benutzerparallelität (optional)

Neues Schlüsselwort “WaitFor (Anzahl der Benutzer)” im EveryStep Web Recorder

Dies ist ein globaler Wartepunkt, der simulierte Benutzer an einem bestimmten Punkt in den Skripts blockiert, bis die erwartete Anzahl von Benutzern diesen Abschnitt des Skripts erreicht hat.

Reaktionszeitschwellenwerte (optional)

Neues SetBoundary-Schlüsselwort im EveryStep Web Recorder

Syntax: SetBoundary(Timername, Bound 1, Bound 2)

Baseline/Kalibrierung (erforderlich)

LoadView führt einen einzelnen Benutzertestlauf aus

ThinkTimes wird als Skript verwendet

LoadView berechnet die Sitzungszeit

Sitzungszeit = Skriptausführungszeit + ThinkTime

Konfigurieren des Workload-/Ausführungsplans (erforderlich)

Kunde stellt Anlaufzeit ein

Kunde legt Zieltransaktionsrate fest

Kunde legt Zielsitzungszeit fest

System berechnet Anzahl der Benutzer

Der Kunde entscheidet, ob die Reaktionszeiten während des Hochfahrens berechnet werden sollen oder nicht.

Ausführen des Tests (erforderlich)

LoadView führt den Test gemäß konfigurierten Workload-/Ausführungsplan aus

LoadView erfasst Antwortzeiten simulierter Skripts oder Transaktionen

LoadView passt ThinkTime dynamisch an, um den erwarteten Durchsatz zu erreichen, wenn die zu testende Anwendung die Reduzierung von ThinkTimes verlangsamt. Wenn ThinkTimes Null sind und Sitzungszeit > Zielsitzungszeit erhält, wird eine Fehlermeldung ausgelöst, die angibt, dass der erwartete Durchsatz nicht erreicht werden konnte.

LoadView berechnet Die Antwortzeiten aktueller Transaktionen und Timer ohne ThinkTimes.

Tipps für die Integration mit Dotcom-Monitor

EveryStep Web Recorder

Einführung neuer ThinkTime-Schlüsselwörter

Ignorieren von ThinkTime während der Testläufe mit nur einem Benutzer

Hinzufügen von ThinkTime während der Skriptaufzeichnung

Einführung des neuen WaitFor-Schlüsselworts (Number user)

Einführung des neuen SetBoundary-Schlüsselworts SetBoundary (TimerName, B1, B2)

WaitFor-Schlüsselwort muss den erstellten Skripts manuell hinzugefügt werden

SetBoundary-Schlüsselwort verwenden

Kalibrierung/Basislinie abrufen

Berechnen der Sitzungszeit während der Kalibrierung

Ausführungsplan/Workload

Option 1:

Hinzufügen einer neuen Workload-Konfigurationsfunktion

Ausführungsplan durch Workload-Funktion ersetzen

Erstellen des Workload-Konfigurationsdialogs zur Unterstützung von Stresstests, Transaktionsziel und anderen Typen

Angeben der Anlaufzeit

Aktivieren Sie das Kontrollkästchen zur Berechnung der Reaktionszeiten während des Hochfahrens (ja/nein)

Option 2:

Verwenden der erweiterten Ausführungsplankonfigurationsfunktion

Testtyp auswählen (Stress, zielbasiert)

Festlegen der Transaktionszieldetails

Angeben der Anlaufzeit

Aktivieren Sie das Kontrollkästchen zur Berechnung der Reaktionszeiten während des Hochfahrens (ja/nein)

Ausführen des Tests

Berechnen der tatsächlichen Skriptausführungszeit/Sitzungszeit

Dynamischeanpassung von ThinkTimes basierend auf der tatsächlichen Sitzungszeit

Warnung erhöhen, wenn der erwartete Durchsatz nicht erreicht werden konnte

Bericht

Konfigurieren eines Abschnitts für Reaktionszeit, tatsächliche Vs. Schwellenwerte pro Timer

Konfigurieren eines Abschnitts für Durchsatz, ist im Vergleich zu erwarteten

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 einzelne Benutzerausführung des Geräts oder Skripts. Denkzeiten werden im Parameter verwendet. Die Skriptausführungszeit wird berechnet und als Sitzungszeit gespeichert. Zusätzliche Details werden ebenfalls berechnet, z. B. erforderliche 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?

Auf diese Weise können komplexe Benutzerszenarien wie Parallelitätssituationen simuliert werden. Es ist sehr nützlich, wenn Sie testen müssen, ob bestimmte Funktionen ordnungsgemäß funktionieren, wenn die x Anzahl der Benutzer gleichzeitig auf eine Ressource zugreift.

Was ist das SetBoundary-Schlüsselwort?

SLAs geben Antwortzeitgrenzen für Benutzeraktionen an, z. B. die Suche nach einem Kunden. Das SetBoundary-Schlüsselwort hilft Ihnen, die tatsächliche Geschwindigkeit einer bestimmten Aktion oder eines bestimmten Timers zu überprüfen. Wenn die zulässige Grenze verletzt wird, wird eine Fehlermeldung angezeigt, die im Testbericht protokolliert wird. Mit diesem neuen SetBoundary-Schlüsselwort ist die SLA-Überprüfung viel einfacher

Was sollten Ihre Ziele für Ihren Auslastungstest sein?

• 100 Prozent vergleichbare Leistungstests für verschiedene Releases/Ausführungen
• Funktion zur Simulation von regulären oder Spitzenlastmustern
• Vertrauen, dass das getestete System die erwartete Last innerhalb der vereinbarten Grenzen bewältigen kann
• Fokussierung der Leistungsoptimierung auf Benutzeraktionen, die gegen vereinbarte Grenzen verstoßen haben

Welche Art von Berichten sollten Sie konfigurieren?

• Erstellen von Berichten, die Ihren aktuellen Berichten ähneln
• Avg, Min, Max, Stddev, Perzentil Antwortzeiten
• Transaktionen ok, Transaktionen fehlgeschlagen
• Fehlerrate
• Alle Antwortzeiten sollten ohne thinkTimes

Einschränkungen

Hohe Zielsitzungszeiten können zu Sitzungstimeouts und Falsch-Positivführen führen. Berücksichtigen Sie Situationen, in denen das Zeitout für Die Websitzung sehr niedrig ist, z. B. 10 Minuten. Wenn Sie einen zielbasierten Leistungstest mit einem einfachen Skript ausführen, das eine Anmeldung und eine Kundensuche ausführt, sollten Sie die ThinkTime zwischen Login und Suche platzieren. In dieser hypothetischen Situation sollte die Sitzungszeit 10 Sekunden der Zielsitzungszeit 700 Sekunden betragen. In diesem Szenario ist ThinkTime höher als das Sitzungstimeout Ihrer zu testenden Anwendung. Alle simulierten Transaktionen schlagen fehl, da Ihr Skript im Zeitfenster für Websitzungen ausgeführt wird und die Kundensuche nicht durchführen kann.

Was passiert, wenn wir das Ziel nicht erreichen?

Wenn sich die Antwortzeit einer Anwendung verlangsamt, die sich im Auslastungstest befindet, und die Sitzungszeit höher als die Zielsitzungszeit wird, kann die erwartete Transaktionsrate nicht erreicht werden.

LoadView beobachtet die tatsächliche Sitzungszeit während der Testausführung und passt ThinkTimes an, um die erwartete zielbasierte Transaktionsrate zu erreichen.

LoadView zeigt auch eine Fehlermeldung im Überwachungsbildschirm an, wenn die Sitzungszeit höher ist als die Zielsitzungszeit.

LoadView wird auch mit der Testausführung fortgesetzt, wenn die Zieltransaktionsrate nicht erreicht werden kann. In diesem Fall wird der Testlauf mit dem fehlgeschlagenen Status markiert. Der Test würde eindeutig zeigen, dass der erwartete Durchsatz aufgrund von Verlangsamung der Reaktionszeiten nicht erreicht werden konnte, und würde angeben, welche Geräte betroffen sind.

Wie sieht eine beispielzielbasierte Workload aus?

Skript / Gerät	ST (Sek.) Nicht editierbar	GST (Sek.) Benutzereingabe	Tph Benutzereingabe	Benutzer Nicht editierbar
Search_User	25	10	500	72
Inser_User	25	60	1000	216

Ramp-Up-Zeit: 15 Minuten

Messen Der Reaktionszeiten während des Hochfahrens: Ja / Nein
ST: Sitzungszeit

GST: Zielsitzungszeit

TPH: Transaktionen pro Stunde

Benutzer: Berechnet durch LoadView (3600 / TPH ) * GST = 72