In diesem Artikel vergleichen wir LoadRunner und LoadView anhand eines praxisnahen Testszenarios in der Beispielanwendung PhoneNumberMonitoring.com. Der Testablauf ist einfach:
Anwendung starten → Einloggen → Zu einem Tab navigieren → Ausloggen
Die Umsetzung dieses Ablaufs in LoadRunner vs. LoadView unterscheidet sich jedoch grundlegend – insbesondere hinsichtlich Einrichtungsaufwand, Flexibilität, Skalierbarkeit und Genauigkeit der realitätsnahen Simulation.
Mit LoadRunner: Protokollebene mit hoher Komplexität
LoadRunner bietet tiefe Kontrolle auf Protokollebene mithilfe von VuGen (Virtual User Generator) und unterstützt Protokolle wie HTTP/HTML, SAP, Web Services, TruClient usw. Dies bietet zwar Flexibilität für Unternehmenstests, jedoch ist der Aufwand selbst für einfache Abläufe sehr hoch.
Für diesen Test verwendeten wir das Web HTTP/HTML-Protokoll, das für Webanwendungen ohne vollständiges Browser-Rendering geeignet ist.
Was wir in LoadRunner gemacht haben
- Protokollauswahl: HTTP/HTML gewählt; die Entscheidung zwischen HTML-basiertem und URL-basiertem Aufnahmemodus ist jedoch kritisch und erfordert oft Trial-and-Error für korrekte Skripterstellung.
- Aufnahme mit VuGen: Port-Mapping konfiguriert (siehe Screenshot) und Aufnahme-Level (z. B. WinInet oder Socket) ausgewählt – jedes mit eigenem Verhalten.
- Korrelationskonfiguration: Dynamische Sitzungsdaten manuell mit web_reg_save_param_ex und JSON-Pfaden extrahiert. Bei fehlender Korrelation schlägt der Test fehl – keine Auto-Vorschläge oder UI-Hinweise.
- Parametrisierung: Feste Werte durch Daten aus Dateien ersetzt, mithilfe von LoadRunners Datenparametrisierungstool.
- Denkzeiten & Transaktionen: Kritische Aktionen in lr_start_transaction() gekapselt und mit lr_think_time() Benutzerverzögerungen simuliert.
- Sitzungsverwaltung: Cookies und benutzerdefinierte Header manuell verwaltet.
- Erweiterte Logik: if-else, Schleifen und eigener C-Code zur Ablaufsteuerung eingefügt.
Wesentliche Schmerzpunkte & Einschränkungen mit LoadRunner
Trotz seiner Leistungsfähigkeit bringt LoadRunner mehrere Hürden mit sich: Komplexität der Aufzeichnung
- Die Auswahl zwischen HTML-basierter oder URL-basierter Aufzeichnung beeinflusst oft das Skript.
- Die Entscheidung zwischen WinInet und Socket-Ebene verwirrt Einsteiger – einige Apps reagieren nur korrekt auf spezifische Modi.
Protokollanalyse & Debugging
- LoadRunner-Protokolle sind protokollspezifisch und oft kryptisch – HTTP-Protokolle, XML-Dumps und Wiedergabelogs sind über Tabs verteilt und schwer in Echtzeit zuzuordnen.
- Live-Wiedergabe von Benutzersitzungen nicht verfügbar – erschwert die visuelle Fehleranalyse bei der Skriptausführung.
Protokollspezifische Korrelation
- Jedes Protokoll (SAP, Oracle, HTTP usw.) erfordert unterschiedliche Korrelationsansätze.
HTTP/HTML-Protokoll
web_reg_save_param, web_reg_save_param_ex, web_reg_save_param_json, web_reg_save_param_xpath (HTTP/HTML, Web Services), web_reg_save_param_attrib usw.
SAP GUI-Protokoll
sapgui_get_text, sapgui_select_active_window, sapgui_set_property, sapgui_get_property, sapgui_status_bar_set_text usw.
Oracle NCA-Protokoll
nca_set_window, nca_set_menu_item, nca_edit_set, nca_button_press, nca_get_text usw.
Web Service-Protokoll
web_custom_request, web_service_call usw.
- Es gibt kein einheitliches Korrelations-Framework – selbst TruClient verhält sich völlig anders und teilt keine Logik mit HTTP-Protokollen.
Performance & Benutzerfreundlichkeit
- TruClient-Skripte simulieren browserbasierte Abläufe, benötigen jedoch viele Ressourcen und laufen langsamer.
- Visuelles Ablauf-Editing ist rudimentär – Debugging erfordert oft Wechsel zwischen Log-Tabs und Snapshots.
Verteilte Lasttest-Einrichtung mit LoadRunner
- LoadRunner erfordert mehrere Komponenten: VuGen für Skripterstellung, Controller für Orchestrierung und Load Generators (LGs) für Verteilung.
- Manuelle Einrichtung notwendig, inkl. Firewall-Regeln, Portfreigaben, Netzwerkeinstellungen.
- Skalierung und Testorchestrierung erhöhen die Komplexität – nicht ideal für agile Teams mit schnellen Iterationen.
LoadRunner ist leistungsfähig für Legacy-Systeme, aber ungeeignet für moderne Webtests oder sprintbasierte Prozesse.
Mit LoadView: Reale Browser-Lasttests leicht gemacht
LoadView bietet einen modernen Ansatz mit cloud-nativen, browserbasierten Lasttests. Es simuliert reales Benutzerverhalten in Browsern wie Chrome oder Edge und validiert nicht nur Backend-Reaktionen, sondern auch Frontend-Leistung (UX-Metriken).
Für denselben Ablauf auf PhoneNumberMonitoring.com nutzten wir den EveryStep Recorder und schlossen die Einrichtung in unter 5 Minuten ab – kein Code, keine Konfiguration, keine Plugins.
Warum sich LoadView mühelos anfühlte
- Aufnehmen wie ein echter Benutzer: Einfach klicken, tippen, scrollen – wie ein echter Nutzer.
- Keine Korrelation notwendig: LoadView erfasst dynamische Werte (Tokens, Sessions).
- Vollständige C#-Skripting-Unterstützung: Für fortgeschrittene Nutzer bietet LoadView vollständiges C#-Scripting mit Schleifen, Bedingungen, Variablen und mehr – maximale Anpassbarkeit.
Beispiel: Skriptabbruch bei Inhaltsvalidierungsfehler
- Vordefinierte Cookies und Header: Konfigurierbare Header, Authentifizierung, Cookies und User Agents – realitätsnahe Tests.
- Einsteigerfreundlich, für Experten geeignet: Einfache Aufnahme für Anfänger, erweiterbar für Profis – seltene Kombination aus Einfachheit und Leistung.
- Volles Browser-Rendering: Unterstützt SPAs, AJAX, WebSockets – was du siehst, ist was du testest.
- Geoverteilte Tests: Auswahl aus über 40 Regionen zur realitätsnahen Lastsimulation.
- Live-Sitzungswiedergabe: Du kannst Schritt für Schritt ansehen, wie der Test lief – inklusive Seitenaufbau und Eingaben – in LoadRunner nicht möglich.
- Frontend-Metriken: LCP (Largest Contentful Paint), FCP (First Contentful Paint), TTI (Time to Interactive) direkt im Bericht.
- Visueller Ablaufeditor: Schritte visuell bearbeiten – kein Code, keine Logs nötig.
Funktionsvergleich: LoadRunner vs. LoadView
Funktion | LoadRunner | LoadView |
Aufzeichnungsoptionen | Mehrere Ebenen (WinInet, Socket), Protokollauswahl | Ein-Klick-Aufzeichnung im Browser |
Scripting erforderlich | Ja – komplexe Skripte, Parametrisierung, Korrelation | Nein – aufnehmen und starten ohne Code |
Handling dynamischer Werte | Manuell – je nach Protokoll | Automatische Korrelation |
Echte Browsersimulation | Nur mit TruClient (langsam, ressourcenintensiv) | Nativ Chrome/Edge |
Frontend-Metriken | Begrenzt in TruClient | Vollständig verfügbar (FCP, LCP, TTI) |
Live-Sitzungswiedergabe | Nicht verfügbar | Verfügbar – mit Playback |
Test-Erstellungszeit | 45–90 Minuten | 5–10 Minuten |
Log-Analyse | Komplexe Protokoll-Logs, manuelle Korrelation | UI-basierte Schritt-Logs, Screenshots |
Protokollspezifisches Handling | Unterschiedlich je nach App-Typ (HTML, SAP, Oracle) | Einheitlicher Recorder für alle Webflüsse |
Verteiltes Testen | Erfordert Load Generators und Controller | Integrierte Cloud-Ausführung |
Kompetenzanforderung | Hoch – Skripting & Debugging nötig | Gering – auch Business-User können testen |
Kosten & Lizenzierung | Teure Enterprise-Lizenzen | Transparente, nutzungsbasierte Preise |
Auswirkung auf reale Anwendungen
Anwendungsfall | LoadRunner | LoadView |
E-Commerce-Checkout | Erfordert Skripting für async-Tokens & JS-Verzögerungen | Browserbasierter Checkout-Flow mit UX-Validierung |
Banking
Dashboards |
Erfordert tiefe Korrelation, Token-Tracking | Einfaches Simulieren von Login & gesicherten Dashboards |
Geo-Lastsimulation | LG-Setup für jede Region erforderlich | Einfache UI-Auswahl globaler Regionen |
Agile Sprint-Tests | Langsames Anpassen & Wiederholen | Schnelle Erstellung, einfache Wiederverwendung |
Kundendemos & POCs | Erfordert Setup & Abstimmung | Aufnehmen & Testergebnisse sofort teilen |
Fazit
Wähle LoadRunner, wenn:
- Du tiefgreifende Protokolltests benötigst
- Du mit Legacy-Apps (SAP, Oracle, Mainframes) arbeitest
- Dein Team technisch versiert ist und dedizierte Infrastruktur hat
Wähle LoadView, wenn:
- Du moderne, browserbasierte Anwendungen testen möchtest
- Dir Frontend-Leistung und Benutzererfahrung wichtig sind
- Du einen schnellen, einfachen Testablauf mit echtem Browser benötigst