Auslastungstests:
HTTP vs Headless vs Real Browser
Langsames Laden oder nicht reagierende Webseiten wirken sich auf den Finanzumsatz aus, da frustrierte Benutzer höchstwahrscheinlich nicht zurückkehren werden, sobald das Problem behoben ist. Daher sind Leistungstests zu einem grundlegenden Bestandteil der Entwicklungskette geworden und die Nachfrage wächst weiter.
Leistungstestplattformen bieten eine breite Palette von Lastsimulationsmethoden wie HTTP, headless und echte browserbasierte. In diesem Beitrag werden wir die Hauptaspekte der folgenden Aspekte einer Vergleichsmatrix skizzieren, die Sie für die Auswahl eines geeigneten Simulationsansatzes verwenden können.
In den Anfängen des digitalen Zeitalters waren HTTP-basierte Tests sehr beliebt. Mit dem Aufkommen der Rich-Web-Client-Technologie sind die HTTP-basierten Simulationsansätze zunehmend veraltet. Ein typischer HTTP-basierter Testtreiber führt Dienstanforderungen aus und analysiert Antworten. Moderne Web 2.0-Anwendungen bestehen aus vielen clientseitigen Skripten, die völlig ignoriert und bei dieser Art von Testausführung nicht gemessen werden. Im schlimmsten Fall können komplexe Anwendungsfälle auf Protokollebene aufgrund eines Mangels an vom Client generierten IDs nicht 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. Je nach Art des getesteten Systems ändern sich einige Webformularnamen häufig, sobald eine neue Version bereitgestellt wurde, wodurch das HTTP-basierte Skript fehlschlägt.
Skript auf Beispielprotokollebene
Transaktion TMain
Var
hContext: Zahl;
Beginnen
WebPageUrl(“http://lab3/st/”, “Grüße”);
WebPageStoreContext(hContext);
WebPageLink(“Join the experience!”, ” – Neuer Besucher”);
WebPageSubmit(“Continue”, CONTINUE001, “Main menu”);
WebPageLink(“Produkte”, “ShopIt – Produkte”);
WebPageLink(NULL, “ShopIt – Produkt”, 3);
WebPageSubmit(“Search”, SEARCH001, ” – Search”, 0, NULL, hContext);
Ende TMain;
dclform
CONTINUE001:
“name” := “jack”,
“New-Name-Button” := “Weiter”;
SEARCH001:
“suche” := “boot”;
Schließlich eignen sich Skripts auf Protokollebene gut für Komponententests in kontinuierlichen Integrationsumgebungen und die perfekte Einstellung für Belastungstests aufgrund ihres geringen Platzbedarfs an Lasteinspritzmaschinen.
Mit dem Aufstieg der Web 2.0-Technologien stand das Testgeschäft vor großen Herausforderungen. Umfangreiche Browseranwendungen konnten aufgrund der fehlenden clientseitigen Logik während der Skriptwiedergabe nicht mehr auf Protokollebene getestet oder simuliert werden. Daher wurden mehrere kopflose Browser wie HtmlUnit, PhantomJS oder SlimerJS eingeführt. Sie basieren oft auf WebKit, der Engine hinter Chrome und Safari.
Headless Browser ähneln echten Browsern ohne GUI. Viele Testautomatisierungs- und Leistungstestplattformen verwenden kopflose Browser, um Datenverkehr zu simulieren.
Headless-Browser haben ihre eigenen Fallstricke; Wenn neue Browser Märkte betreten, müssen headless Browser-Kits alle Leistungs- und Funktionsverbesserungen der echten Browser aufholen.
Die Simulation des clientseitigen Renderings von ist nicht kostenlos. Ein typischer Load-Injection-Server kann bis zu 10-12 gleichzeitige headless-Browsersitzungen simulieren, im Vergleich zu 500 HTTP-basierten Sitzungen.
Die Implementierung und Anpassung von Testskripten ist nicht allzu schwierig. Wenn Sie über grundlegende Programmierkenntnisse verfügen, können Sie einfache Skripte erstellen. Nicht alle headless-Browser bieten visuelle Wiedergabefunktionen und ohne visuelle Wiedergabe Skript-Debugging oder Fehleranalyse könnte sehr schwierig werden.
Phantomjs-Beispielskript
“streng verwenden”;
var page = require(‘webseite’).create(),
Server = ‘http://posttestserver.com/post.php?dump’,
daten = ‘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();
});
Im Beispielskript, das hier zu sehen ist, wird eine einfache Postanforderung ausgeführt. Sie benötigen Java-Programmierkenntnisse, um solche Testskripte anzupassen.
Web2.0-Anwendungen sind voll von JavaScript, Flash, Ajax und CSS. Ohne einen vollständigen Browser ist es nicht möglich, die tatsächlichen End-to-End-Antwortzeiten der gesamten Webseite zu messen. Mit echten browserbasierten Leistungstests können Sie die Funktionalität und Geschwindigkeit der Website überprüfen, wie sie vom Endbenutzer wahrgenommen wird.
Eine typische echte Browser-Performance-Testlösung erfasst Ladezeiten von Bildern, JavaScript, CSS und mehr. Oft stellen sie Wasserfalldiagramme bereit, die die Ladezeit dieser Komponenten visualisieren.
Der Platzbedarf eines echten browserbasierten Browsers ist etwas höher. In Anbetracht der Tatsache, dass headless Browser-Simulation nicht 100% realistische Reaktionszeiten liefert, ist es fair zu sagen, dass echte browserbasierte Simulation bevorzugt werden sollte. In realen Szenarien, kopflose Browser führen nur 20% besser als echte Browser. Wenn also ein Einzelnerlastinjektor in mittlerer Größe 10-12 headless Browser-Sitzungen ausführen kann, kann derselbe Lastinjektor 8-10 echte Browsersitzungen ausführen.
Die Implementierung und Wartung von Testskripts ist einfach, da Benutzeraktionen direkt widergespiegelt werden und die visuelle Wiedergabe das Debuggen erleichtert. Im Beispielskript unten öffnet der Browser eine URL, fügt Benutzer und Passwort ein und klickt auf die Anmeldeschaltfläche.
Beispiel für echtes browserbasiertes Skript
Transaktion TMain
Beginnen
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);
Navigieren Sie zur Anmeldewebsite
BrowserNavigate(“http://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, aber sie kann für Stresstests mit hohen Benutzervolumina teuer werden, da der Platzbedarf auf dem Lastinjektionsserver zu hoch ist.
Performance Test Types
Component Speed Tests
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 dienstbasierte Leistungstests auf Protokollebene oder simulieren echte browserbasierte Leistungsprüfungen, um End-to-End-Antwortzeiten mit vereinbarten Leistungsgrenzen zu vergleichen.
Ziele
+ Wiederholbarkeit
+ Automatisierte Schnittstellen- und End-to-End-Leistungsprüfungen
+ Vergleichder Reaktionszeiten mit vereinbarten Schwellenwerten
Load Tests
Aus mehreren Gründen sind Belastungstests die ideale Prüfmethode, wenn es um die Überprüfung nicht-funktionaler Anforderungen geht. Eine davon ist, dass die Reaktionszeiten unter reproduzierbaren Bedingungen überprüft werden können. Ein weiterer Teil davon 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
+ Reproduzierbare Lastsimulation
+ Überprüfung der Reaktionszeitschwellen
+ Engpässe in der Produktion wie Belastungsbedingungen identifizieren
+ Realistische End-to-End-Testszenarien
Stress Test
Wenn Sie die Zuverlässigkeit Ihrer Anwendung unter Spitzenlastbedingungen testen müssen, führen Sie einen Stresstest durch. In diesem Testtyp geben Sie hauptsächlich die maximale Anzahl von Benutzern und die Zeit an, über die der Hochlauf und die Konstante-State-Last für Ihre Anwendung sein sollte. Das Ziel besteht darin, die Bruchstellen Ihrer zu testenden Anwendung zu identifizieren.
Ziele
+ Nachweis Skalierbarkeit und Stabilität
+ Spitzenlastbedingungen simulieren
+ Exakte Reproduzierbarkeit ist nicht wichtig
Vergleich
Offensichtlich gibt es gute Gründe für Protokoll, kopflos oder echte Browser-basierte Benutzersimulation. Die folgende Matrix enthält einige Hinweise zur Auswahl des geeigneten Ansatzes.
Kriterien
HTTP
Headless Browser
Real Browser
Benutzersimulation
Kein
Client-Seiten-Rendering
Einige clientseitige Elemente werden simuliert
Reale Benutzersimulation
Skriptimplementierung
und -anpassung
Schwierig, wenn Websites komplex sind
Entwicklerkenntnisse zum Erstellen robuster Skripts erforderlich
Einfache Skripte, einfach anzupassen
S
cript Wiederholung
Low-Level-Analyse erforderlich
Je nach verwendeter Engine ist eine visuelle Wiedergabe möglich
Sie sehen, was Sie bekommen
Skript-Wartungsfreundlichkeit
Programmierkenntnisse erforderlich
Fehler in nicht gerenderten Abschnitten sind schwierig zu lösen
Einfach, weil Sie Fehler während der Wiedergabe sehen
Multi-Browser-Unterstützung
Einige Tools emulieren Webbrowser, aber dies ist nicht vergleichbar
Ja, aber einige Elemente fehlen oft
Einige unterstützen andere Versionen und verschiedene Browser
F
ootprint auf Derlast-Injektionsmaschine
Niedrig,
bis zu 800 Sitzungen pro Server
Mittel
, bis zu
10-12
Sitzungen pro Server
Hoch,
bis zu 6 Sitzungen pro Server
Empfohlen
für
DevOps
Abhängig vom tatsächlichen Testszenario
Nein, oft komplexe Skripte
Ja, einfach zu bedienen und realistische Zahlen
Empfohlen für Auslastungstests
Nein
, die clientseitige Verarbeitung wird übersprungen
Ja, besser als HTTP-Simulation
Ja, realistische Benutzersimulation
Empfohlen für Stresstests
Ja, da es einen geringen Overhead auf der Lastgeneratormaschine gibt
Nein, der Overhead auf der Lastgeneratormaschine ist zu hoch
Nein,
höchster Overhead auf Lastgeneratormaschine
kosten
Niedrig
Hoch
Hoch
Empfohlen für Hochvolumen-, Low-Cost-Tests Webserver-Stresstests (wo möglich)
Nicht empfohlen
Empfohlen für reale komplexe Anwendungssimulationen.
Stresstest
Wenn Sie die Zuverlässigkeit Ihrer Anwendung unter Spitzenlastbedingungen testen müssen, führen Sie einen Stresstest durch. In diesem Testtyp geben Sie hauptsächlich die maximale Anzahl von Benutzern und die Zeit an, über die der Hochlauf und die Konstante-State-Last für Ihre Anwendung sein sollte. Das Ziel besteht darin, die Bruchstellen Ihrer zu testenden Anwendung zu identifizieren.
Ziele
+ Nachweis Skalierbarkeit und Stabilität
+ Spitzenlastbedingungen simulieren
+ Exakte Reproduzierbarkeit ist nicht wichtig
Vergleich
Offensichtlich gibt es gute Gründe für Protokoll, kopflos oder echte Browser-basierte Benutzersimulation. Die folgende Matrix enthält einige Hinweise zur Auswahl des geeigneten Ansatzes.
| Kriterien | HTTP | Headless Browser | Real Browser |
| Benutzersimulation | Kein Client-Seiten-Rendering | Einige Client-Seitenelemente werden simuliert | Reale Benutzersimulation |
| Skriptimplementierung und -anpassung | Schwierig, wenn Websites komplex sind | Entwicklerkenntnisse zum Erstellen robuster Skripts erforderlich | Einfache Skripte, einfach anzupassen |
| Skriptwiedergabe | Low-Level-Analyse erforderlich | Je nach verwendeter Engine ist eine visuelle Wiedergabe möglich | Sie sehen, was Sie bekommen |
| Skript-Wartungsfreundlichkeit | Programmierkenntnisse erforderlich | Fehler in nicht gerenderten Abschnitten sind schwierig zu lösen | Einfach, weil Sie Fehler während der Wiedergabe sehen |
| Multi-Browser-Unterstützung | Einige Tools emulieren Webbrowser, aber dies ist nicht vergleichbar | Ja, aber einige Elemente fehlen oft | Einige unterstützen andere Versionen und verschiedene Browser |
| Fußabdruck auf Derlast-Einspritzmaschine | Niedrig, bis zu 800 Sitzungen pro Server | Mittel, bis zu 10-12 Sitzungen pro Server | Hoch, bis zu 6 Sitzungen pro Server |
| Empfohlen für DevOps | Abhängig vom tatsächlichen Testszenario | Nein, oft komplexe Skripte | Ja, einfach zu bedienen und realistische Zahlen |
| Empfohlen für Auslastungstests | Nein, die Client-Seitenverarbeitung wird übersprungen | Ja, besser als HTTP-Simulation | Ja, realistische Benutzersimulation |
| Empfohlen für Stresstests | Ja, weil es einen geringen Overhead auf Lastgenerator-Maschine | Nein, der Overhead auf der Lastgeneratormaschine ist zu hoch | Nein, höchster Overhead auf Lastgeneratormaschine |
| kosten | Niedrig | Hoch | Hoch |
| Empfohlen für Hochvolumen-, Low-Cost-Tests Webserver-Stresstests (wo möglich) | Nicht empfohlen | Empfohlen für reale komplexe Anwendungssimulationen.
|
- https://developers.google.com/web/tools/chrome-devtools/device-mode/testing-other-browsers
- https://watirmelon.blog/2015/12/08/real-vs-headless-browsers-for-automated-acceptance-tests/
- http://news.softpedia.com/news/what-is-a-headless-browser-and-what-s-it-good-for-485162.shtml
- https://github.com/dhamaniasad/HeadlessBrowsers
- https://circleci.com/
