Die Single-Page Application als neuer Trend

Das Modell einer traditionellen Webanwendung (links) im direkten Vergleich mit einer Ajax-Webanwendung (rechts). Autor: DanielSHaischt

Ende der 90er Jahre hat man in der Webentwicklung die These vertreten, dass die Rechenleistung der Server den Clients deutlich überlegen ist und aus diesem Grund sollen dynamisch generierte Inhalte auf Webservern oder Applikationsservern generiert werden und der Client bekommt eine statische HTML-Seite, die im Browser angezeigt wird.

Der Client mit dem Browser hat sich rein auf die Präsentation von Inhalten beschränkt, während Applikations- und Datenhaltungsschicht auf dem Server angesiedelt war.

Im Jahr 2005 kam mit Ajax eine Technologie auf, die einen ganz neuen Ansatz verfolgt. Auf dem Client gibt es mit der "Ajax-Engine" eine aktive Komponente, die Benutzeraktionen verarbeitet und wenn erforderlich Anfragen an den Server sendet und Antworten auswertet. Es entsteht für den Anwender der Eindruck, dass im Grunde die gesamte Applikation auf dem Client abläuft.

Heute sieht man viele weitere Frameworks, wie z.B. AngularJS, React oder Vue.js, die diesen Ansatz nutzen. Daneben haben sich auch neue Protokolle, wie z.B. WebSockets, etabliert, die darauf setzen, dass Information auf dem Client verarbeitet und aufbereitet werden.

In der Single-Page Application wird üblicher Weise nur am Anfang eine URL aufgerufen und HTML-Code übertragen. Zusammen mit dem HTML-Code wird auch JavaScript übertragen, das auf dem Client ausgeführt wird und dynamisch die DOM-Struktur der angezeigten Webseite verändert. Der Anwender sieht geänderte Inhalte in seinem Browser, die URL bleibt aber über die Nutzungsdauer der Applikation konstant.

Diese Trendwende hat auch Auswirkungen auf die Performanz einer Webapplikation. Während früher die Antwortzeiten des Servers eine Aussage zur Geschwindigkeit der Applikation treffen konnten, hängt die Performanz heute im Wesentlichen von der Rechengeschwindigkeit des Clients ab. Damit müssen sich der Test deutlich mehr Gedanken hinsichtlich der Testumgebungen machen, da die Webapplikation von einer großen Anzahl unterschiedlicher Endgeräte genutzt werden kann.

End-User-Experience als neue Metrik im Performanztest

Die meisten Testwerkzeuge zur Messung der Performanz arbeiten auf Ebene des Webprotokolls. Die Werkzeuge senden Anfragen an den Webserver und empfangen die Antwort und liefern Antwortzeiten als Messgröße.

Bei Single-Page Applikationen gibt es aber auf dem Client jetzt eine aktive Komponente, die den Inhalt von Antworten verarbeitet und die aktuelle DOM-Struktur anpasst. Die Dauer für diese Verarbeitung bis zur Anzeige im Browser ist nicht Bestandteil der Antwortzeit und kann je nach Client auch unterschiedlich ausfallen.

Um die Performanz einer Single-Page Applikation sicher bewerten zu können, ist die Antwortzeit keine ausreichend gute Metrik. Es gilt vielmehr die Zeit zu messen, die von der Benutzeraktion auf der Seite bis zur Änderung der Anzeige im Browser vergeht. Diese Zeit wird in der Literatur als End-User-Experience bezeichnet.

Die End-User-Experience beginnt z.B. mit dem Klick auf ein Element der Webseite und endet, wenn eine erwartete Information im Browser zu sehen ist. Damit sind auch beide Verarbeitungsschritte durch die aktive Komponente auf dem Client von dieser Metrik abgedeckt.

Gemeinsamer Einsatz von Performanztest- und Testausführungswerkzeugen

Testaufbau für den Performanztest mit Messung der End-User-Experience

Wenn es um die Messung der End-User-Experience geht, sind Testausführungswerkzeuge sehr geeignet, da diese in aller Regel mit einem Browser interagieren. Die Testskripte steuern die Applikation über Controls, die im Browser dargestellt werden und führen auf diesen auch Prüfungen aus.

Nachteilig ist meist jedoch an Testausführungswerkzeugen, dass man auf einem Rechner meist nur eine Instanz laufen lassen kann, da sich ansonsten die Testskripte durch Mausklicks oder Tastatureingaben gegenseitig im Ablauf stören.

Die parallele Ausführung mehrerer Testskripte über einen Rechner ist jedoch die Stärke von Performanztestwerkzeugen, da diese rein über die Netzwerkkarte Requests versenden.

Die beiden Stärken der jeweiligen Testwerkzeuge lassen sich kombinieren, wenn man wenige Rechner zur Messung der End-User-Experience einsetzt und parallel eine große Menge an Anfragen an die Server über das Performanztestwerkzeug generiert.

NeoLoad und QF-Test sind ein gutes Team für diese Aufgabe

Verwendung von QF-Test im Performanztest
Import von QF-Test-Skripten in NeoLoad

Wir, die Firma Muth Partners, setzen bei Performanztests mit Messung der End-User-Experience auf NeoLoad und QF-Test.

Die beiden Testwerkzeuge lassen sich mit Hilfe eines von uns entwickelten Plugins perfekt gemeinsam einsetzen. Neben der Messung der End-User-Experience lassen sich QF-Test-Skripte fast automatisch in NeoLoad importieren. Damit lassen sich die bestehenden Testskripte für die funktionalen Tests Ihrer Software einfach 

  • im Performanztest zur Messung der End-User-Experience verwenden und
  • in NeoLoad importieren,  um mit vergleichbaren Skripten Last zu erzeugen, ohne diese neu entwickeln zu müssen.

Mit Muth Partners zu besseren Performanztests

Wenn Sie Interesse an der Integration von NeoLoad und QF-Test haben, dann sprechen Sie uns an. 

Als Service Partner von Neotys und Partner von QFS können unsere Berater Ihnen helfen, die Integration der beiden Werkzeuge in Ihre Umgebung zu übertragen.

 englische Version

Ihr Nutzen

  • Messung der End-User-Experience als starke Metrik
  • Wiederverwendung bestehender Skripte
  • Import von Skripten
  • Single Point of Thruth in NeoLoad

Mehr Infos

Ihr Kontakt


Schweier, Dirk O.
Dirk O. Schweier
Teamleiter Testautomatisierung