Overview
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.
HTTP-basierte Auslastungssimulation
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.
Headless Browser Based Load Simulation
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.
Headless Browser Based Load Simulation
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.
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 |
| Script-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 |
| Footprint 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. |
Webseiten, die für dieses Dokument verwendet werden:
- 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/