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