Langsames Laden oder nicht reagierende Webseiten wirken sich auf den Finanzumsatz aus, da frustrierte Benutzer h\u00f6chstwahrscheinlich nicht zur\u00fcckkehren werden, sobald das Problem behoben ist. Daher sind Leistungstests zu einem grundlegenden Bestandteil der Entwicklungskette geworden und die Nachfrage w\u00e4chst weiter.<\/p>\n
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\u00fcr die Auswahl eines geeigneten Simulationsansatzes verwenden k\u00f6nnen.<\/p>\n
In den Anf\u00e4ngen des digitalen Zeitalters waren HTTP-basierte Tests sehr beliebt. Mit dem Aufkommen der Rich-Web-Client-Technologie sind die HTTP-basierten Simulationsans\u00e4tze zunehmend veraltet. Ein typischer HTTP-basierter Testtreiber f\u00fchrt Dienstanforderungen aus und analysiert Antworten. Moderne Web 2.0-Anwendungen bestehen aus vielen clientseitigen Skripten, die v\u00f6llig ignoriert und bei dieser Art von Testausf\u00fchrung nicht gemessen werden. Im schlimmsten Fall k\u00f6nnen komplexe Anwendungsf\u00e4lle auf Protokollebene aufgrund eines Mangels an vom Client generierten IDs nicht simuliert werden.<\/p>\n
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\u00e4lle k\u00f6nnen schwierig zu implementieren sein. Ein Leistungsingenieur muss sich mit Cookies, Sitzungs-IDs und anderen dynamischen Parametern befassen. Je nach Art des getesteten Systems \u00e4ndern sich einige Webformularnamen h\u00e4ufig, sobald eine neue Version bereitgestellt wurde, wodurch das HTTP-basierte Skript fehlschl\u00e4gt.<\/p>\n
Mit dem Aufstieg der Web 2.0-Technologien stand das Testgesch\u00e4ft vor gro\u00dfen Herausforderungen. Umfangreiche Browseranwendungen konnten aufgrund der fehlenden clientseitigen Logik w\u00e4hrend der Skriptwiedergabe nicht mehr auf Protokollebene getestet oder simuliert werden. Daher wurden mehrere kopflose Browser wie HtmlUnit, PhantomJS oder SlimerJS eingef\u00fchrt. Sie basieren oft auf WebKit, der Engine hinter Chrome und Safari.<\/p>\n
Headless Browser \u00e4hneln echten Browsern ohne GUI. Viele Testautomatisierungs- und Leistungstestplattformen verwenden kopflose Browser, um Datenverkehr zu simulieren.<\/p>\n
Headless-Browser haben ihre eigenen Fallstricke; Wenn neue Browser M\u00e4rkte betreten, m\u00fcssen headless Browser-Kits alle Leistungs- und Funktionsverbesserungen der echten Browser aufholen.<\/p>\n
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.<\/p>\n
Die Implementierung und Anpassung von Testskripten ist nicht allzu schwierig. Wenn Sie \u00fcber grundlegende Programmierkenntnisse verf\u00fcgen, k\u00f6nnen Sie einfache Skripte erstellen. Nicht alle headless-Browser bieten visuelle Wiedergabefunktionen und ohne visuelle Wiedergabe Skript-Debugging oder Fehleranalyse k\u00f6nnte sehr schwierig werden.<\/p>\n
Mit dem Aufstieg der Web 2.0-Technologien stand das Testgesch\u00e4ft vor gro\u00dfen Herausforderungen. Umfangreiche Browseranwendungen konnten aufgrund der fehlenden clientseitigen Logik w\u00e4hrend der Skriptwiedergabe nicht mehr auf Protokollebene getestet oder simuliert werden. Daher wurden mehrere kopflose Browser wie HtmlUnit, PhantomJS oder SlimerJS eingef\u00fchrt. Sie basieren oft auf WebKit, der Engine hinter Chrome und Safari.<\/p>\n
Headless Browser \u00e4hneln echten Browsern ohne GUI. Viele Testautomatisierungs- und Leistungstestplattformen verwenden kopflose Browser, um Datenverkehr zu simulieren.<\/p>\n
Headless-Browser haben ihre eigenen Fallstricke; Wenn neue Browser M\u00e4rkte betreten, m\u00fcssen headless Browser-Kits alle Leistungs- und Funktionsverbesserungen der echten Browser aufholen.<\/p>\n
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.<\/p>\n
Die Implementierung und Anpassung von Testskripten ist nicht allzu schwierig. Wenn Sie \u00fcber grundlegende Programmierkenntnisse verf\u00fcgen, k\u00f6nnen Sie einfache Skripte erstellen. Nicht alle headless-Browser bieten visuelle Wiedergabefunktionen und ohne visuelle Wiedergabe Skript-Debugging oder Fehleranalyse k\u00f6nnte sehr schwierig werden.<\/p>\n
In den letzten Jahren haben sich die Methoden der Softwareentwicklung in die agile Richtung entwickelt. Kurze Release-Sprints sind unerl\u00e4sslich. Entwickler und Testingenieure automatisieren ihre Qualit\u00e4tssicherung und Leistungspr\u00fcfungen. In der Regel implementieren sie dienstbasierte Leistungstests auf Protokollebene oder simulieren echte browserbasierte Leistungspr\u00fcfungen, um End-to-End-Antwortzeiten mit vereinbarten Leistungsgrenzen zu vergleichen.<\/p>\n
Ziele<\/p>\n
Aus mehreren Gr\u00fcnden sind Belastungstests die ideale Pr\u00fcfmethode, wenn es um die \u00dcberpr\u00fcfung nicht-funktionaler Anforderungen geht. Eine davon ist, dass die Reaktionszeiten unter reproduzierbaren Bedingungen \u00fcberpr\u00fcft werden k\u00f6nnen. Ein weiterer Teil davon ist, dass diese Tests die \u00dcberpr\u00fcfung der Reaktionszeitschwellen erm\u00f6glichen. Realistische Reaktionszeitmessungen sind in Auslastungstestszenarien unerl\u00e4sslich. Daher verwenden Testingenieure f\u00fcr ihre Auslastungstesteinstellungen eine kopflose oder echte browserbasierte Benutzersimulation.<\/p>\n
Ziele<\/p>\n
Wenn Sie die Zuverl\u00e4ssigkeit Ihrer Anwendung unter Spitzenlastbedingungen testen m\u00fcssen, f\u00fchren Sie einen Stresstest durch. In diesem Testtyp geben Sie haupts\u00e4chlich die maximale Anzahl von Benutzern und die Zeit an, \u00fcber die der Hochlauf und die Konstante-State-Last f\u00fcr Ihre Anwendung sein sollte. Das Ziel besteht darin, die Bruchstellen Ihrer zu testenden Anwendung zu identifizieren.<\/p>\n
Ziele<\/p>\n
Offensichtlich gibt es gute Gr\u00fcnde f\u00fcr Protokoll, kopflos oder echte Browser-basierte Benutzersimulation. Die folgende Matrix enth\u00e4lt einige Hinweise zur Auswahl des geeigneten Ansatzes.<\/p>\n