Langsames Laden oder nicht reagierende Webseiten haben direkte Auswirkungen auf den Finanzumsatz. Es ist von entscheidender Bedeutung, dass Sie Ihre Leistungstests mit der richtigen Lastsimulation einrichten. Wenn dies nicht richtig geschieht, könnte dies katastrophale Auswirkungen haben. Frustrierte Benutzer werden höchstwahrscheinlich aufgeben, was auch immer sie taten und nicht zurückkehren. Selbst wenn Sie und Ihr Team dieses Problem behoben haben, ist es wahrscheinlich zu spät. Sie haben wahrscheinlich bereits eine alternative Lösung gefunden. Und wenn sie es einmal haben, ist es unwahrscheinlich, dass sie zurückschalten werden.

Sie müssen sich nicht nur Sorgen über Umsatzeinbußen machen, sondern auch andere Faktoren wie Verbrauchervertrauen, Markenintegrität usw. sind wahrscheinlich schädlicher für das Geschäft. Je länger das Thema andauert, desto schwieriger ist es, das Vertrauen der Verbraucher zurückzugewinnen. Nicht nur das, die Rendite der Investitionen, die Sie in Ihr Produkt, Ihre Teams und Ihre Organisation getätigt haben, wird länger dauern, wenn überhaupt. Daher sind Leistungstests (und -überwachung) zu einem grundlegenden und kritischen Bestandteil der Software und Anwendungsentwicklungskette geworden. Die Notwendigkeit einer Lösung, die Leistungstests ordnungsgemäß und genau durchführen kann, ist sehr gefragt.

Leistungstestplattformen bieten eine breite Palette von Lastsimulationsmethoden wie HTTP/S, headless und echte browserbasierte Tests. In diesem Artikel werden die wichtigsten Aspekte der einzelnen beschrieben, gefolgt von einer Vergleichsmatrix, die Sie für die Auswahl eines geeigneten Simulationsansatzes verwenden können.

HTTP-basierte Auslastungssimulation

In den Anfängen unseres digitalen Zeitalters waren HTTP-basierte Tests sehr beliebt. Mit dem Aufkommen der Rich-Web-Client-Technologie ist dieser Ansatz zunehmend veraltet (und auch das Testen von Leistungstests mit Tools wie JMeter ist etwas veraltet). Ein typischer HTTP-basierter Testtreiber führt Dienstanforderungen aus und analysiert Antworten. Moderne Web 2.0-Anwendungen bestehen aus vielen clientseitigen Skripten, die bei dieser Art von Testausführung völlig ignoriert und nicht gemessen werden. Aufgrund eines Mangels an clientseitig generierten Sitzungs-IDs können komplexe Anwendungsfälle nicht auf Protokollebene simuliert werden.

Aufgrund ihrer Anforderungs- und Antwort-basierten Natur ist der Overhead an der Lastspritzmaschine sehr gering. Ein typischer Auslastungstestserver kann bis zu 800 gleichzeitige Sitzungen simulieren. Komplexe protokollbasierte Anwendungsfälle können schwierig zu implementieren sein. Ein Leistungsingenieur muss sich mit Cookies, Sitzungs-IDs und anderen dynamischen Parametern befassen. Abhängig von der Technologie des zu testenden Systems ändern sich einige Webformularnamen häufig, sobald eine neue Version bereitgestellt wurde, was dazu führt, dass das HTTP-basierte Skript fehlschlägt.

Das folgende Beispielskript zeigt den sehr technischen Charakter dieser Skripte. Wenn sich ein technisches Attribut Ihrer Anwendung ändert, müssen Sie das gesamte Skript neu schreiben, was einfacher gesagt als getan ist.


//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;

dclform
CONTINUE001:
“name” := “jack”,
“New-Name-Button” := “Weiter”;

SEARCH001:
“suche” := “boot”;

Schließlich eignen sich Skripte auf Protokollebene gut für Tests auf Komponentenebene in Continuous-Integration-Umgebungen und sind aufgrund ihres geringen Platzbedarfs auf Lastinjektionsmaschinen die perfekte Einstellung für Stresstests.

Headless Browser-Based Load Simulation
Mit dem Aufstieg der Web 2.0-Technologien stand das Testgeschäft vor großen Herausforderungen. Umfangreiche Browseranwendungen konnten nicht mehr auf Protokollebene getestet oder simuliert werden, da während der Skriptwiedergabe eine clientseitige Logik fehlte. Daher wurden mehrere kopflose Browser eingeführt, wie HtmlUnit, PhantomJS oder SlimerJS. Sie basieren oft auf WebKit, der Engine hinter Chrome und Safari.

Headless-Browser haben alle Vorteile von echten Browsern und sie laufen schneller ohne die schwere GUI. Viele Testautomatisierungs- und Leistungstestplattformen verwenden kopflose Browser, da sie eine realistische Benutzersimulation ermöglichen.

Einige Anbieter haben ihre eigenen kopflosen Browser-Engines gebaut, sind aber in Wartungs-Tücken geraten, weil sie mit neuen Browser-Versionen Schritt halten müssen. In dieser Situation wird dringend empfohlen, frei verfügbare Headless-Browser-Kits zu verwenden, da es eine breite Community gibt, die an Verbesserungen arbeitet.

Die Simulation des clientseitigen Renderings ist nicht kostenlos. Ein typischer Lastinjektionsserver kann bis zu acht gleichzeitige headless Browser-Sitzungen simulieren.

Die Implementierung und Anpassung von Testskripten ist nicht allzu schwierig. Wenn Sie über grundlegende Entwicklerkenntnisse verfügen, können Sie einfache Skripts erstellen. Nicht alle kopflosen Browser bieten visuelle Wiedergabefunktionen und ohne visuelle Wiedergabe können Skript-Debugging und Fehleranalyse sehr schwierig werden.

Im Beispielskript unten wird eine einfache Postanforderung ausgeführt. Sie benötigen Java-Programmierkenntnisse, um solche Testskripte anzupassen.


//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=42';

page.open(Server, ‘post’, Daten, Funktion (Status)
if (Status !== ‘Erfolg’)
console.log(‘Nicht zu posten!’);
. . . . . . . . . . .
console.log(page.content);
}

phantom.exit();
});

Mit dieser Überlegung im Hinterkopf, kopflose Browser sind der Weg zu gehen, wenn Sie Programmierkenntnisse haben und Sie eine Lösung verwenden, die visuelle Skript-Wiedergabe ermöglicht.

 

Echte browserbasierte Lastsimulation

Web 2.0-Anwendungen sind voll von JavaScript, Flash, AJAX, CSS, etc. Ohne einen vollständigen Browser ist es nicht möglich, die tatsächlichen End-to-End-Antwortzeiten der gesamten Anwendung oder Webseite zu messen. Echte browserbasierte Leistungstests ermöglichen es Ihnen, die Funktionalität und Geschwindigkeit der Website so zu überprüfen, wie sie vom Endbenutzer wahrgenommen wird, was, wie oben besprochen, der Punkt ist, an dem es wirklich zählt.

Eine typische echte Browser-Performance-Testlösung erfasst Ladezeiten von Bildern, JavaScript, CSS und mehr. Häufig stellen sie Wasserfalldiagramme bereit, die die Ladezeit dieser Komponenten visualisieren.

Der Platzbedarf eines echten browserbasierten Browsers ist etwas höher. Da die kopflose Browsersimulation keine 100 Prozent realistischen Reaktionszeiten liefert, kann man mit Fug und Recht sagen, dass echte browserbasierte Simulation die bevorzugte Testmethode sein sollte.

Die Implementierung und Wartung von Testskripts ist einfach, da Benutzeraktionen direkt widergespiegelt werden und die visuelle Wiedergabe das Debuggen erleichtert. Im folgenden Beispielskript öffnet der Browser eine URL, fügt das Kennwort des Benutzers ein und klickt auf die Anmeldeschaltfläche.


//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

Navigieren Sie zur Anmeldewebsite
BrowserNavigate(“https://demo.com/TestSite/LoginForm.html”);
Festlegen der Authentifizierung für den sicheren Standort
BrowserSetText(“/INPUT[@name=’user’]”, “User1”);
BrowserSetPassword(“/INPUT[@name=’pwd’]”, “Password1”);
einloggen
BrowserClick(“/INPUT[@value=’Login’]”, BUTTON_Left);
Ende TMain;

Schließlich ist eine echte Browsersimulation für realistische End-to-End-Lasttests nützlich. Verwenden Sie es jedoch nicht für Stresstests, da der Platzbedarf auf dem Lastinjektionsserver zu hoch ist.

 

Verschiedene Arten von Last- und Leistungstests

Komponentengeschwindigkeitstests

In den letzten Jahren haben sich Die Methoden der Softwareentwicklung in die agile Richtung entwickelt. Kurze Release-Sprints sind unerlässlich. Entwickler und Testingenieure automatisieren ihre Qualitätssicherung und Leistungsprüfungen. In der Regel implementieren sie servicebasierte Leistungstests (und manchmal API-Tests) auf Protokollebene, oder sie simulieren echte browserbasierte Leistungsprüfungen, um End-to-End-Antwortzeiten mit vereinbarten Leistungsgrenzen zu vergleichen.

Ziele von Komponentengeschwindigkeitstests:

  • Überprüfen und wiederholen Sie das Eingabe-/Ausgabeverhalten.
  • Automatisierte Schnittstellen- und End-to-End-Leistungsprüfungen.
  • Vergleich der Reaktionszeiten mit vereinbarten Schwellenwerten.

Auslastungstests

Lasttests die ideale Einstellung, wenn es um die Überprüfung nicht-funktionaler Anforderungen geht. Ein Grund dafür ist, dass die Reaktionszeiten unter reproduzierbaren Bedingungen überprüft werden können. Ein weiterer Teil ist, dass diese Tests die Überprüfung der Reaktionszeitschwellen ermöglichen. Realistische Reaktionszeitmessungen sind in Auslastungstestszenarien unerlässlich. Daher verwenden Testingenieure für ihre Auslastungstesteinstellungen eine kopflose oder echte browserbasierte Benutzersimulation.

Ziele von Lasttests:

  • Reproduzierbare Lastsimulation.
  • Überprüfung der Reaktionszeitschwellen.
  • Identifizieren von Engpässen unter produktionsähnlichen Belastungsbedingungen.
  • Erstellen realistischer End-to-End-Testszenarien.

Stresstests

Wenn Sie die Zuverlässigkeit Ihrer Anwendung unter Spitzenlastbedingungen nachweisen müssen, führen Sie einen Stresstest durch, um die Bruchstelle Ihres Systems zu ermitteln.

Ziele der Stressprüfung:

  • Beweisen Sie Skalierbarkeit und Stabilität bei Spitzenverkehrsbedingungen.
  • Beobachten Sie, wie das System ausfällt und wieder online geht.
  • Reproduzierbarkeit ist nicht wichtig.

 

Vergleich

Offensichtlich gibt es gute Gründe und Situationen für Protokoll-, Kopflos- und echte browserbasierte Benutzersimulationen. Die folgende Matrix enthält einige Hinweise, wann Der geeignete Testansatz gewählt werden soll.

Kriterien HTTP Headless Browser Real Browser
Benutzersimulation (1) Kein clientseitiges Rendering (2) Einige clientseitige Elemente werden simuliert (3) Reale Benutzersimulation
Skriptimplementierung und -anpassung (1) Schwierig, wenn Websites komplex sind (2) Entwicklerkenntnisse, die zum Erstellen robuster Skripte erforderlich sind (3) Einfache Skripte, einfach anzupassen
Skriptwiedergabe (1) Low-Level-Analyse erforderlich (2) Je nach verwendeter Engine ist eine visuelle Wiedergabe möglich (3) Sie sehen, was Sie bekommen
Skript-Wartungsfreundlichkeit (1) Erforderliche Programmierkenntnisse (2) Fehler in nicht gerenderten Abschnitten sind schwierig zu lösen (3) Einfach, weil Sie Fehler während der Wiedergabe sehen
Multi-Browser-Unterstützung (1) Einige Tools emulieren Webbrowser, aber dies ist nicht vergleichbar (2) Ja, aber einige Elemente fehlen oft (2) Einige unterstützen andere Versionen und verschiedene Browser
Fußabdruck auf Derlast-Einspritzmaschine (3) Niedrig, bis zu 800 Sitzungen pro Server (2) Mittel, bis zu 8 Sitzungen pro Server (1) Hoch, bis zu 6 Sitzungen pro Server
Empfohlen für DevOps (2) Abhängig vom tatsächlichen Testszenario (1) Nein, oft komplexe Skripte (3) Ja, einfach zu bedienen und realistische Zahlen
Empfohlen für Auslastungstests (1) Nein, die clientseitige Verarbeitung wird übersprungen (2) Ja, besser als HTTP-Simulation (3) Ja, realistische Benutzersimulation
Empfohlen für Stresstests (3) Ja, weil es einen geringen Overhead auf Lastgeneratormaschine (2) Nein, der Overhead auf der Lastgeneratormaschine ist zu hoch (1) Nein, höchster Overhead auf Lastgeneratormaschine
Kosten (3) Niedrig (2) Mittel (1) Hoch
Gesamtpunktzahl 17 19 24

Hoffentlich hat dieser Artikel über Auslastungssimulations- und Leistungstesttypen Ihnen einen zusätzlichen Einblick in Ihre Leistungstests gegeben. Wenn Sie Fragen zum Ausführen von Last- und Belastungstests oder zur LoadView-Lösung im Allgemeinen haben, wenden Sie sich an unser Team oder melden Sie sich für eine Demo mit einem unserer Leistungsingenieure an.