In diesem Artikel vergleichen wir LoadRunner und LoadView anhand eines praktischen Testszenarios mit der Beispielanwendung PhoneNumberMonitoring.com. Der Testablauf ist einfach:
Anwendung starten → Einloggen → Zu einem Tab navigieren → Ausloggen
Wie dieser Ablauf jedoch in LoadRunner vs LoadView implementiert wird, ist völlig unterschiedlich – insbesondere in Bezug auf Einrichtungsaufwand, Flexibilität, Skalierbarkeit und realitätsnahe Simulation.
Mit LoadRunner: Protokollebene-Power bei hoher Komplexität
LoadRunner bietet tiefgehende Kontrolle auf Protokollebene mittels VuGen (Virtual User Generator) und unterstützt Protokolle wie HTTP/HTML, SAP, Web Services und TruClient usw. Während dies Flexibilität für Unternehmentests bietet, kann der Aufwand für die Konfiguration selbst eines einfachen Ablaufs überwältigend sein.
Für diesen Test verwendeten wir das Web HTTP/HTML-Protokoll, das für Webanwendungen ohne vollständige Browserdarstellung geeignet ist.
Was wir in LoadRunner gemacht haben
- Protokollauswahl: Ich habe HTTP/HTML gewählt; jedoch ist die Auswahl des richtigen Aufnahmemodus (HTML-basiert vs. URL-basiert) eine kritische Entscheidung und erfordert oft Trial-and-Error, um ein korrektes Skript zu erzeugen.
- Aufnahme mit VuGen: Port-Mapping konfiguriert (siehe Screenshot) und den Erfassungslevel (z. B. WinInet oder Socket) ausgewählt – jeder mit eigenem Verhalten und
- Korrelationseinrichtung: Dynamische Sitzungsdaten manuell mit web_reg_save_param_ex und JSON-Pfad extrahiert. Wenn Korrelation fehlt, schlägt der Test fehl – keine Auto-Vorschläge oder UI-Hinweise.
- Parametrisierung: Hartkodierte Werte durch Datendateien mit LoadRunners Data Parameterization Utility ersetzt.
- Think Time & Transaktionen: Kritische Aktionen in lr_start_transaction() eingewickelt und lr_think_time() hinzugefügt, um Nutzerverzögerungen zu simulieren.
- Sitzungsverwaltung: Cookies und benutzerdefinierte Header manuell verwaltet zwischen
- Erweiterte Logik: if-else, Schleifen und eigenen Code in C für Ablaufsteuerung hinzugefügt
Wesentliche Schmerzpunkte & Einschränkungen bei LoadRunner
Trotz der Leistungsfähigkeit bringt LoadRunner mehrere Reibungspunkte mit sich: Aufnahme-Komplexität
- Die Wahl zwischen HTML-basierter oder URL-basierter Aufnahme wirkt sich oft auf das Skript aus
- Die Wahl zwischen WinInet und Socket-Level-Erfassung kann Anfänger verwirren – einige Apps reagieren nur korrekt auf bestimmte Erfassungsmodi.
Log-Fehlerbehebung & Debugging
- LoadRunner-Logs sind protokollspezifisch und oft kryptisch – HTTP-Logs, XML-Dumps und Wiedergabelogs sind auf vielen Tabs verteilt und schwer in Echtzeit zu korrelieren.
- Live-Benutzersitzungswiedergabe ist nicht verfügbar – was es erschwert visuell zu erkennen, was während der Skriptausführung schiefgelaufen ist.
Protokollspezifische Korrelation
- Jedes Protokoll (SAP, Oracle, HTTP etc.) benötigt 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 Korrelationsframework – sogar TruClient verhält sich komplett anders und teilt keine Korrelationslogik mit dem HTTP-Protokoll.
Performance & Bedienbarkeit
- TruClient-Skripte simulieren browserbasierte Abläufe, verbrauchen aber hohe Systemressourcen und dauern deutlich länger in der Ausführung.
- Visuelles Flows-Editing ist grundlegend, Debugging-Fehler erfordern oft einen Wechsel zwischen mehreren Logfenstern und Snapshots.
Verteilte Lasttesteinrichtung mit LoadRunner
- LoadRunner benötigt mehrere Komponenten: VuGen für Skripterstellung, Controller für Orchestrierung und Lastgeneratoren (LGs) für die Verteilung.
- Erfordert manuelle Einrichtung, Firewallregeln, Freigaben von Ports und Netzwerk
- Skalierbarkeit und Ausführungsorchestrierung erhöhen die Komplexität – nicht geeignet für agile Teams mit schnellen Durchläufen.
LoadRunner ist leistungsfähig für Legacy-Systeme, aber weniger ideal für moderne Webtests oder sprintbasierte Iterationen.
Mit LoadView: Real Browser Load Testing einfach gemacht
LoadView bietet einen modernen Ansatz mit cloud-nativem, browserbasiertem Lasttest. Es simuliert echtes Nutzerverhalten in Browsern wie Chrome oder Edge und validiert nicht nur die Backend-Reaktion, sondern auch die tatsächliche Frontend-Performance (UX-Metriken).
Für den gleichen Ablauf auf PhoneNumberMonitoring.com verwendeten wir den EveryStep Recorder und schlossen die Testeinrichtung in unter 5 Minuten ab – kein Code, keine Konfigurationen, keine Plugins.
Warum LoadView mühelos wirkte
- Aufnehmen wie ein echter Nutzer: Einfach klicken, tippen, scrollen – wie ein echter Anwender interagiert.
- Keine Korrelation: LoadView erfasst dynamische Werte (Tokens, Sessions)
- Volle C#-Skriptunterstützung: Für fortgeschrittene Nutzer bietet LoadView umfassende C#-Skriptmöglichkeiten, inklusive Schleifen, Bedingungen, Variablendeklarationen und mehr – so können Abläufe flexibel angepasst werden.
Beispiel:- Abbruch der Skriptausführung bei einem Inhaltsvalidierungsfehler
- Voreingestellte Cookies und Header: Sie können Anforderungsheader, Authentifizierungsdetails, Cookies und User-Agent vor der Ausführung konfigurieren, um reale Szenarien genauer nachzubilden.
- Einsteigerfreundlich, expertenbereit: Während der einfache Aufnahmebeginn leicht fällt, skaliert LoadView mit den Bedürfnissen erfahrener Performance-Tester und ist damit eine seltene Mischung aus Einfachheit und Leistungsfähigkeit.
- Volle Browserdarstellung: Unterstützt SPAs, AJAX, WebSockets – was Sie sehen, testen Sie auch.
- Geo-verteiltes Testing: Wählen Sie aus über 40 globalen Regionen, um Nutzerlast aus realen Standorten zu simulieren.
- Live Session Replay: Sie können sehen, wie der Test ablief, Schritt für Schritt, inklusive Seitendarstellung und Eingabeaktivitäten – dies ist bei LoadRunner nicht möglich.
- Frontend-Metriken: LCP (Largest Contentful Paint), FCP (First Contentful Paint) und TTI (Time to Interactive) direkt im Bericht anzeigen.
- Visueller Flow-Editor: Jeden Schritt visuell bearbeiten – kein Code-Touch oder Log-Scan nötig
Feature-Vergleich: LoadRunner vs LoadView
| Feature | LoadRunner | LoadView |
| Aufnahmeoptionen | Mehrere Erfassungsebenen (WinInet, Socket), Protokollentscheidungen | Ein-Klick browserbasierte Aufnahme |
| Erforderliches Skripting | Ja – fortgeschrittenes Skripting, Parametrisierung, Korrelation | Nein – Aufnehmen und Ausführen ohne Skripte |
| Umgang mit dynamischen Werten | Manuell – pro Protokoll | Automatische Korrelation |
| Echte Browser-Simulation | Nur via TruClient (ressourcenintensiv, langsam) | Native Chrome/Edge |
| Frontend-Metriken | Begrenzt bei TruClient | Voll verfügbar (FCP, LCP, TTI) |
| Live Session Replay | Nicht verfügbar | Verfügbar – mit Wiedergabe |
| Test-Erstellungszeit | 45–90 Minuten | 5–10 Minuten |
| Log-Analyse | Komplexe Protokolllogs, manuelle Korrelation | UI-basierte Schritt-Logs, Screenshots |
| Protokollspezifische Handhabung | Variiert nach Anwendungstyp (HTML, SAP, Oracle) | Einheitlicher Recorder für alle Webflüsse |
| Verteiltes Testing | Benötigt Lastgeneratoren und Controller | Integrierte Cloud-Ausführung |
| Erforderliche Fähigkeiten | Hoch – benötigt Skripting & Debugging | Niedrig – auch Business User können testen |
| Kosten & Lizenzierung | Teure Enterprise-Lizenzierung | Transparente, nutzungsabhängige Preise |
Reale Anwendungs auswirkungen
| Anwendungsfall | LoadRunner | LoadView |
| E-Commerce Checkout | Benötigt Skripting für asynchrone Tokens & JS-Verzögerungen | Echter browserbasierter Checkout-Ablauf mit UX-Validierung |
| Banking Dashboards | Benötigt tiefe Korrelation, Tokenverfolgung | Einfach zu simulieren: Login & Navigation zu geschützten Dashboards |
| Geo-Lastsimulation | LG-Einrichtung für jede Region erforderlich | Einfache Geo-Auswahl über UI |
| Agiles Sprint-Testen | Langsamer zu modifizieren und erneut auszuführen | Schnelle Erstellung und einfache Wiederverwendbarkeit |
| Kunden-Demos & POCs | Erfordert Einrichtung und Koordination | Testresultate sofort aufnehmen & teilen |
Abschließende Zusammenfassung
Wählen Sie LoadRunner wenn:
- Sie tiefgehende Protokolltests benötigen
- Sie mit Legacy-Anwendungen (SAP, Oracle, Mainframes) arbeiten
- Ihr Team technisch versiert ist und eine dedizierte Infrastruktur besitzt
Wählen Sie LoadView wenn:
- Sie moderne, browserbasierte Anwendungen testen möchten
- Sie Wert auf Frontend-Performance und Benutzererfahrung legen
- Sie einen schnelleren, einfacheren Testzyklus mit echtem Browser-Support benötigen