In unserem früheren Artikel „Web Load Testing: LoadRunner vs. LoadView – Real-World Scenario“ haben wir gezeigt, wie man eine typische Benutzerreise auf PhoneNumberMonitoring.com simuliert – die Website starten, sich einloggen, durch Tabs navigieren und sich ausloggen – mithilfe von LoadRunner und LoadView. Dieser Vergleich hob die Unterschiede beim Skripting-Aufwand, der Komplexität der Einrichtung und der Benutzerfreundlichkeit hervor.
Aufbauend auf dieser Übung bietet dieser Artikel einen detaillierten Vergleich zwischen LoadView und LoadRunner mit Schwerpunkt auf der Vorbereitung von Test-Szenarien und den Berichtsfunktionen. Wir untersuchen, wie jedes Tool bei der Ausführung eines realitätsnahen Benutzerablaufs mit mehreren virtuellen Benutzern abschneidet und wie gut sie dabei Folgendes handhaben:
- Sichtbarkeit und Genauigkeit der Ausführung
- Echtzeit- und Nachtest-Berichterstattung
- Dynamische Inhalte und Frontend-Verhalten
- Sitzungsdiagnose und Debugging auf Schritt-für-Schritt-Basis
Überblick
Dieser Vergleich konzentriert sich ausschließlich auf die Testeinrichtungs-Erfahrung und die Berichterstattungsfunktionen von LoadView und LoadRunner, zwei führenden Tools für Leistungstests.
Die Bewertung basiert auf einem echten Benutzerfluss – Start, Login, Aktionen durchführen, Logout – ausgeführt auf einer dynamischen Webanwendung. Der Vergleich betont:
- Einfachheit bei der Konfiguration von Lastszenarien
- Sichtbarkeit während der Testausführung
- Tiefe und Klarheit der Testberichte
- Debugging-Funktionen wie Video-Wiedergabe, Screenshot-Erfassung, Fehlerklassifizierung und Wasserfallanalyse
Da moderne Anwendungen zunehmend SPAs (Single-Page Applications) und JavaScript-lastige Frontends nutzen, sind Tools, die echtes Browserverhalten simulieren und visuelle Diagnosen in Echtzeit bieten, wichtiger denn je.
- Test-Szenario-Vorbereitung
LoadView
Szenario-Designer auf Browserbasis
LoadView zeichnet reale Browserinteraktionen (Klicks, Scrollen, Wartezeiten, AJAX-Auslöser) direkt in Chrome oder Edge auf. Jeder Schritt wird in einem visuellen Ablaufdiagramm abgebildet, was vollständige Übereinstimmung mit dem Benutzererlebnis gewährleistet.
Visueller Assistent zur Lastkonfiguration
Einfache Konfiguration von:
- Lasttypen: Laststufenkurve, Dynamische Anpassungskurve und Zielbasierte Kurve
- Lastmuster: Stufenweise, Exponentiell, Spike, Dauerlast, Belastungstest, Failover usw.
- Szenarioeinrichtung: Testdauer, Ramp-up, Reduktion, Haltezeit
- Regionen: 40+ globale Cloud-Standorte (z. B. Singapur, Kalifornien, London)
- Browser: Chrome oder Edge für echtes Rendering
Setup ohne lokale Umgebung
Es ist keine Installation oder Verwaltung von Load-Generatoren (LGs), virtuellen Maschinen, Firewall-Regeln oder Netzwerkkonfigurationen erforderlich. Die gesamte Infrastruktur wird automatisch in der Cloud von LoadView bereitgestellt.
Schrittweise Bedingungen
Pass/Fail-Kriterien für jeden Schritt konfigurieren, wie z. B.:
- Textvalidierung
- Sichtbarkeit von Elementen
- JavaScript-Auslöser
- HTTP-Statuscodes usw.
Vorschau mit einem Klick
Einzelbenutzer-Vorschau ausführen, um den gesamten Testablauf vor dem vollständigen Test zu überprüfen – einschließlich UI-Rendering, Validierungen und Antwortmetriken.
Weitere Hinweise:
- Transaktionsnamen, Verzögerungen, Messzeiten, Lighthouse, Netzwerkdrosselung usw. konfigurierbar.
- Verzweigungslogik, bedingte Wartezeiten und Schleifen direkt verfügbar.
LoadRunner
Szenarien-Design im Controller
Szenarien werden im LoadRunner Controller erstellt durch Zuweisung von:
- Benutzergruppen
- Ramp-up-Plänen
- Denkzeiten und Pausenintervallen
- Ausführungsdauern
Manuelles Setup von Load-Generatoren
Tester müssen LGs manuell auf Maschinen oder Cloud-Hosts bereitstellen und konfigurieren. Die Verbindung zwischen LGs und Controller erfordert Firewall-/NAT-Einstellungen, Portfreigaben und Infrastruktur-Berechtigungen.
Komplexe Geo-Tests
Um Lasten aus mehreren Regionen zu simulieren, müssen Benutzer Server in jeder Zielregion manuell bereitstellen, Zugänge konfigurieren und Testläufe synchronisieren.
Einfache Validierungslogik
Die Validierung erfolgt auf Protokollebene (z. B. HTTP 200). Visuelle Validierungen sind nur mit TrueClient-Skripten möglich, die ressourcenintensiv und wartungsaufwendig sind.
Vorschau der Ausführung
UI-Rendering in der Vorschau ist nur in TrueClient verfügbar. Bei anderen Protokollen bieten Trockendurchläufe keine visuelle Bestätigung des Testpfads.
Weitere Hinweise:
- Erfordert Skripting- und Protokollkenntnisse
- Protokollwahl (Web HTTP/HTML, SAP, Citrix usw.) beeinflusst das Skriptdesign
- Echtzeit-Sichtbarkeit während der Ausführung
LoadView
Umfassende cloudbasierte Berichte in Echtzeit: Leistungskennzahlen werden kontinuierlich während des Tests angezeigt.
Stetige Echtzeit-Aktualisierung von Leistungskennzahlen: Kennzahlen wie durchschnittliche Antwortzeit, 90. Perzentil, Minimum, Maximum und Fehlerrate werden live aktualisiert.
Fehlerklassifizierung zur schnelleren Ursachenanalyse: Fehler werden in Validierungs-, Client-, Server- und Drittanbieter-Kategorien gruppiert.
Cloudbasierte PDF-Berichte und teilbare Dashboards: Live-Dashboards lassen sich einfach verteilen oder zusammenfassend exportieren.
Interaktive Diagramme zu Antwortzeiten, Fehlerverteilung und Benutzeraktivitäten: Ermöglicht schnelle Identifikation von Spitzen, Trends oder Ausfällen. Eine umfassende Übersicht zur Überwachung des Testfortschritts in Echtzeit.
Die obere Hälfte zeigt einen plötzlichen Anstieg der durchschnittlichen Antwortzeit, was mit einem Rückgang erfolgreicher Sitzungen und einem Anstieg fehlgeschlagener Sitzungen (unterer Graph) korreliert. Dies ist ein perfektes Beispiel für LoadViews Fähigkeit, Leistungsprobleme visuell mit dem Benutzerverhalten zu korrelieren.
Kumulative Sitzungsverfolgung über Zeitfenster hinweg: Hilft bei der Beurteilung von Konsistenz und Stabilität des Tests während der Ausführung.
Lastkurven virtueller Benutzer: Visuelle Darstellung von Laststeigerungen im Zusammenhang mit Sitzungsleistung.
Dieses Diagramm zeigt, wie virtuelle Benutzer im Laufe der Zeit skaliert wurden. Die grüne Linie zeigt die tatsächliche Benutzeranzahl, die eng mit der orangefarbenen Linie (erwartete Benutzer) übereinstimmt. Die violette Linie markiert das maximal konfigurierte Limit.
Serverstatistiken aus jeder Geo-Zone: Diagnose von regionsspezifischen Problemen oder Latenzen.
Sitzungsbezogene Navigation mit Benutzerpfaden: Tiefenanalyse jedes virtuellen Benutzerpfads samt Antwortdaten.
Einblick in spezifische Sitzungs-IDs: Analyse einzelner Testverläufe mit detaillierten Netzwerkdaten und schneller Fehlerisolierung.
Diese Grafik zeigt, wie mehrere Cloud-Agenten (aus AWS-, Azure-Regionen) die Testlast gemeinsam trugen. CPU- und Speicherauslastung blieben überwiegend stabil – ein Beleg für LoadViews elastische Testverteilungs-Architektur.
Vergleich historischer Testläufe in LoadView
Ergebnisse über mehrere Testausführungen hinweg vergleichen
Während Echtzeit- und statische Berichte wertvoll sind, bietet LoadView auch standardmäßig eine Nachverfolgung historischer Trends. Jeder Testlauf wird automatisch archiviert und kann mit früheren Ausführungen verglichen werden.
Vorher-/Nachher-Vergleichsansicht der Performance
Dies ermöglicht es Teams, Änderungen im Anwendungscode, der Infrastruktur oder bei Drittanbieter-Diensten zu bewerten, indem sie frühere Leistungskennzahlen direkt mit den neuesten Ergebnissen vergleichen – ohne komplexe Integrationen oder Konfigurationen.
Keine Einrichtung erforderlich
Im Gegensatz zu LoadRunner, das typischerweise eine Integration mit externen Tools wie InfluxDB, Grafana oder HP ALM für Trendanalysen und historische Vergleiche erfordert, bietet LoadView eine integrierte historische Visualisierung über eine einfache, webbasierte Oberfläche – ohne zusätzliche Einrichtung oder Infrastruktur.
Beispiel: Ein Entwicklungsteam kann einen Test von vor zwei Wochen (vor einer Datenbankoptimierung) mit der neuesten Ausführung vergleichen und sofort Verbesserungen bei Antwortzeiten und Fehlerraten erkennen.
Weitere Vorteile:
- QA-Teams können Abläufe funktional und visuell validieren
- Verringert den Debugging-Aufwand durch Wegfall von Loganalysen oder rein backendbasierter Ansichten
LoadRunner
Controller-Diagramme (nur in lizenzierter Version)
Bei Lizenzierung stellt der LoadRunner Controller Metriken zur Laufzeit bereit wie:
- Ausführende VUsers
- TPS (Transaktionen pro Sekunde)
- Fehler pro Sekunde und einige weitere
Diese Diagramme sind in der kostenlosen Version nicht verfügbar, was die Sichtbarkeit während der Ausführung erheblich einschränkt.
Kein Frontend-Feedback
Screenshots, visuelle Validierungen und DOM-bezogene Daten sind nicht verfügbar, es sei denn, TrueClient wird verwendet. Selbst mit TrueClient sind diese Einblicke unter hoher Last schwer zu analysieren.
Keine geografische Aufschlüsselung
Out-of-the-box bietet LoadRunner keine segmentierte Leistungsdarstellung nach Regionen. Benutzerdefiniertes Skripting oder Tagging ist erforderlich.
Keine Sitzungsüberwachung auf Einzelbasis
LoadRunner bietet keine Einblicke auf Sitzungsebene, was es schwierig macht, nachzuvollziehen, welcher Schritt fehlschlug, was der Browser zu diesem Zeitpunkt darstellte oder wie sich die Sitzung durch den Ausführungspfad bewegte.
Weitere Einschränkungen:
- Keine integrierte Screenshot-Erfassung
- Keine Echtzeitdaten pro Sitzung
- Ursachenanalyse erst im Nachlaufbericht im Analysis-Tool möglich
- Vergleichstabelle – Zusammenfassung
| Funktion | LoadView | LoadRunner |
| Szenario-Builder | Visuell, browserbasiert | Skript- und protokollbasiert (Controller) |
| Geo-Lastverteilung | Integriert, cloudgesteuert | Manuelle LG-Bereitstellung erforderlich |
| Sichtbarkeit auf Sitzungsebene | Vollständig, mit Replays und Screenshots | Nicht vorhanden |
| Wasserfalldiagramm | Ja, auf Browser-Ebene | Nicht verfügbar |
| Video-Wiedergabe | Ja | Nein |
| Frontend-Metriken (FCP, LCP, TTI, CLS) | Ja | Nein |
| Fehlerkategorisierung | Automatisch gruppiert nach Typ | Manuelle Log-Analyse |
| Berichtsfreigabe | Cloud-Dashboards, PDF, Excel, Sharing-Links | Nur lokale HTML- oder PDF-Dateien |
| Historischer Ergebnisvergleich | Integriert | Benötigt ALM/externe Einrichtung |
| Berichte für Stakeholder | Ja, geschäftsfreundlich | Nur technisch |
| Umgebungseinrichtung | Cloud-gehostet, keine Infrastruktur notwendig | Erfordert Einrichtung von Load-Generatoren |
| Optimaler Einsatzzweck | Webanwendungen, UX, modernes Frontend | Backend-APIs, Protokolltests |
Beste Anwendungsfälle für LoadRunner (Protokollbasiertes Testen)
LoadRunner ist ein leistungsstarkes Performance-Testtool auf Enterprise-Niveau, das sich besonders für backend-lastige, protokollbasierte Tests eignet. Es simuliert den Datenverkehr auf der Transportschicht und ist daher ideal für Anwendungen, bei denen keine Browserdarstellung erforderlich ist.
| Anwendungsfall | Warum LoadRunner gut geeignet ist | Beispiel |
| 1. API-Lasttests | Unterstützt verschiedene Protokolle wie HTTP, Web Services und REST. Ermöglicht präzise Parametrisierung und Korrelation. | Lasttests einer Bank- oder Versicherungs-API mit hohem Transaktionsvolumen |
| 2. SAP-, Oracle-, Citrix-Tests | Bietet protokollbasierten Support für komplexe Enterprise-Systeme wie SAP GUI, Oracle Forms und Citrix. | Performance-Test von SAP HR-Systemabläufen |
| 3. Lasttests von Backendsystemen | Effektiv für Stresstests von Messaging-Queues, Datenbanken und Mainframes. | Lasttest eines COBOL-basierten Finanzberichterstattungs-Backends |
| 4. CI/CD-Pipeline-Integration | Integriert sich mit Jenkins, Azure DevOps und ALM für automatisierte Regressions- und Performance-Tests. | Nächtliche Performance-Tests nach Code-Merges ausführen |
| 5. Tests komplexer Protokolle | Simuliert FTP-, SMTP-, WebSocket- und Telnet-Interaktionen mit protokollgenauer Wiedergabe. | Lasttest der Dateiupload-Performance auf einem internen FTP-Server |
| 6. Custom-Scripting mit C | Volles C-Scripting erlaubt granularen Testaufbau, Logik und Datenhandling. | Simulation eines mehrstufigen Versicherungsprozesses per Code-Skripten |
Beste Anwendungsfälle für LoadView (Browserbasiertes Testen)
(Chrome, Edge), um tatsächliches Benutzerverhalten zu simulieren – ideal für moderne Webanwendungen und Teams, die Benutzererfahrung und visuelle Validierung priorisieren.
| Anwendungsfall | Warum LoadView am besten geeignet ist | Beispiel |
| 1. Browserbasierte Lasttests | Führt echte Benutzerreisen mit JavaScript, Cookies, DOM-Updates und Seitenrendering aus. | Lasttest eines Reisebuchungsportals |
| 2. SPA-Tests (React, Angular, Vue) | Handhabt automatisch asynchrone Vorgänge (AJAX, fetch, WebSockets) von JS-Frameworks. | Test eines Kunden-Dashboards in Angular |
| 3. UX-Validierung im E-Commerce | Misst Ladezeiten, FCP, LCP, TTI — echte Metriken, die sich auf Konversionsraten auswirken. | Lasttest eines Warenkorb-zur-Kasse-Ablaufs vor dem Black Friday |
| 4. Geo-verteilte Tests | Unterstützt Tests von über 40 Standorten, um Benutzerzugriffe aus verschiedenen Regionen zu simulieren. | Website-Geschwindigkeit aus den USA, Europa und Indien testen |
| 5. Skriptfreie Lasttests | Zeichnet Benutzerflüsse auf (Klicks, Scrollen, Filter, Navigation). Kein technisches Skripting erforderlich. | Produktmanager oder QA-Teams testen User-Flows ohne Entwicklerbeteiligung |
| 6. Stakeholder-gerechte Berichte | Berichte enthalten Session-Replays, visuelle Charts, PDF-Exporte – geeignet für Geschäfts- und Nicht-Techniker. | Ergebnisse mit VPs, Product Ownern oder Kunden teilen |
| 7. Validierung dynamischer Inhalte | Erfasst jede UI-Änderung, verzögertes Rendering, modale Fenster oder AJAX-basierte Filter. | Test einer Hotel-Website mit Filtern und Lazy-Loading |
Zusammenfassung des Artikels
LoadView bietet ein modernes, browserbasiertes Testerlebnis, das auf dynamische Webanwendungen optimiert ist. Es ermöglicht:
- Echtzeitzugriff auf Live-Metriken und Performance-Diagramme während der Testausführung
- Tiefe Einblicke auf Sitzungsebene mit Video-Wiedergabe, Screenshots und vollständigen Interaktions-Replays
- Einfache Berichtfreigabe über Cloud-Dashboards, PDFs und Excel-Exporte
- Vereinfachtes Debugging durch eingebaute Browsermetriken (FCP, LCP, TTI), geografische Aufschlüsselungen und automatische Fehlerklassifizierung
LoadRunner, obwohl robust für protokollbasierte Enterprise-Systeme, bietet:
- Begrenzte UI-Sichtbarkeit und keine integrierten Frontend-Metriken
- Nachgelagerte Berichte ohne Echtzeit-Dashboards oder Sitzungs-Replays
- Berichtsfunktionalität ist häufig auf Drittanbieter-Integrationen (z. B. ALM, InfluxDB, Grafana) angewiesen
- Browser-Simulation erfordert TrueClient-Skripting, was die Testkomplexität und Systembelastung erhöht