fbpx

Ladesimulation & Leistungstesttypen

Langsames Laden oder nicht reagierende Webseiten wirken sich auf den Finanzumsatz aus, da frustrierte Benutzer höchstwahrscheinlich nicht zurückkehren, 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/S, headless und echte browserbasierte. 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 reichen Web-Client-Technologie ist dieser Ansatz 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 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 getesteten 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.


//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 Skripts auf Protokollebene gut für Komponententests in kontinuierlichen Integrationsumgebungen und sind aufgrund ihres geringen Platzbedarfs an Lasteinspritzmaschinen 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, alle frei verfügbaren 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 8 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();
});

In Anbetracht dessen sind kopflose Browser der Weg, wenn Sie Programmierkenntnisse haben und eine Lösung verwenden, die eine visuelle Skriptwiedergabe ermöglicht.

 

Echte browserbasierte Lastsimulation

Web 2.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 werden.

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 100prozentrealistischen Reaktionszeiten liefert, kann man mit Fug und Recht sagen, dass echte browserbasierte Simulation die bevorzugte Methode zum Testen 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 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
  • 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

  • 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 Belastungstest durch, um die Bruchstelle Ihres Systems zu ermitteln.

Ziele

  • Nachweis der Skalierbarkeit und Stabilität
  • Simulieren von Spitzenlastbedingungen
  • Reproduzierbarkeit ist nicht wichtig

 

Vergleich

Offensichtlich gibt es gute Gründe für protokollarische, kopflose oder echte browserbasierte Benutzersimulation. Die folgende Matrix enthält einige Hinweise zur Auswahl des geeigneten Ansatzes.

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