Mit Lasttests für mobile Apps Leistungsengpässen vorbeugen

Should I stay or should I go?
Kommentare

Egal, ob Cyber Monday oder mobiler Aktienhandel mit der Wertpapier-App: Eine flüssige 24/7-Verfügbarkeit der Verkaufs- und Service-Apps und die zügige Abwicklung von Transkationen entscheiden über Umsatz, Kundenzufriedenheit und Marktakzeptanz. Hier kommen Lasttests ins Spiel. Sie können zwar nicht die schwankenden Leistungen der Mobilfunknetze verbessern. Aber sie verhindern, dass fehlerhafte Apps und Serverinfrastrukturen das Surfen mit Tablet und Smartphone unnötig verlangsamen, und helfen, Webangebote auf verfügbare Datentransferraten und die Leistungsfähigkeit mobiler Browser optimal abzustimmen.

Eine aktuelle Studie [1] belegt, dass namhafte Webstores Smartphone-Kunden erst nach durchschnittlich zehn bis 13 Sekunden Einlass gewähren. Jeder siebte Aufruf scheitert ganz oder nimmt Ladezeiten von über einer Minute in Anspruch. Vergegenwärtigt man sich die bekannten Untersuchungsergebnisse von Amazon, die die direkte Abhängigkeit des Umsatzes von den Ladegeschwindigkeiten nachweisen, erklärt sich das starke Interesse der Onlinewirtschaft an der Performanceoptimierung ihrer Angebote. Bei der Identifikation und Lokalisierung der Ursachen für lange Wartezeiten spielen neben Funktions- vor allem Lasttests eine entscheidende Rolle. Während Funktionstests das Verhalten von Anwendungen unter idealen Laborbedingungen für einen einzelnen Nutzer untersuchen, messen Lasttests die tatsächliche Performance der Applikation in realitätsnahen Szenarien, etwa wenn Berufstätige in der Mittagszeit auf ihre Konten und Depots zugreifen oder Einkäufe erledigen. Eine beliebig skalierbare und zielgruppenkonform zusammengestellte Anzahl virtueller Testkunden überprüft dann die Wertpapier- und Shop-Anwendungen. Ihre hohe Verfügbarkeit auch unter Last ist mitentscheidend für Absatzzahlen, Kundenzufriedenheit und das Image eines Onlineanbieters. Denn egal, wie stark ein Webangebot frequentiert ist – so schleppend wie zu Zeiten von Modem und ISDN möchte heute niemand mehr durch Warenwelten flanieren oder Finanztransaktionen abwickeln.

Warum Lasttests?

Eine flüssige Navigation durch die virtuellen Abteilungen eines Online-Stores sind mehr als ein reiner Wohlfühlservice für Kunden. Wartezeiten oder Abbrüche der beauftragten Prozesse werden nicht akzeptiert. Vertriebsplattformen müssen dabei gerade für das Saisongeschäft oder den Kampagnenstart fit gemacht werden, damit stark ansteigende Zugriffsraten das Angebot nicht außer Gefecht setzen. Last- und Stresstests sind vor dem Go-Live eines App-Angebotes, aber auch parallel zum laufenden Produktivbetrieb ein wichtiges Mittel, Leistungsengpässe auszuschließen und die Qualität der Kundenservices abzusichern. Mithilfe künstlich erzeugter Nutzer wird z. B. ein Besucheransturm simuliert, um die Leistungsfähigkeit und -grenzen der Systeme auszumessen. Neben extremen Zugriffsszenarien steht aber auch der ganz normale Alltag im Fokus: Die virtuelle Testkundschaft zeigt in jeweils unterschiedlicher Zusammensetzung und Anzahl, wie der reale Käufer die Webshop-Funktionen erlebt und ob sich Leistungsparameter (z. B. die Antwortzeit einer Webanwendung) in vorher festgelegten Zielkorridoren bewegen. Lasttests erlauben eine frühe Identifikation von Schwachstellen, solange sie noch mit geringem Kosten- und Zeitaufwand zu beseitigen sind.

Warum mobile Lasttests?

Der Smartphone-Markt boomt, Mobilfunknetze werden für die Webnutzung der Kunden immer wichtiger. Banken und Handel rechnen sich auf diesem Gebiet erhebliches Umsatzwachstum aus, denn im Gegensatz zum stagnierenden stationären Handel verzeichnet der E-Commerce seit Jahren deutliche Zuwachsraten. Wachstumshoffnungen knüpfen sich vor allem wegen der durchgängigen Verbindung mit dem Internet an das Mobile-Business. Webanbieter haben daher ein hohes Interesse, Smartphone-Kunden ein ähnlich hohes Serviceniveau zu bieten, wie sie für WLAN- und Ethernet-Nutzer selbstverständlich sind. Hier besteht gesonderter Lasttestbedarf, da die Bandbreite im Funknetz geringer ist als bei drahtlosen und festnetzgebundenen DSL-Verbindungen. Zumindest bis LTE flächendeckend zur Verfügung steht, können Fehler im Handling von Browseranfragen wegen der geringeren Verbindungsgeschwindigkeiten viel schlechter kaschiert werden als z. B. bei ultraschnellen Glasfaserverbindungen. Zudem erschwert die Heterogenität der Tablet- und Smartphone-Betriebssysteme – die von iOS, Windows 8, Windows RT, BlackBerry OS bis zu den zahlreichen Android-Varianten reichen – die Programmierung von mobilen Websites und Apps, die Nutzern jederzeit stabil und hochperformant zur Verfügung stehen.

Wie funktionieren Lasttests generell?

Klassische Lasttests folgen einem Dreischritt aus „Recording“, „Playback“ und „Auswertung“. In der ersten Phase werden relevante Zugriffsszenarien festgelegt. Bei modernen Lasttestlösungen navigiert der Testspezialist durch das Onlineangebot. Dabei werden die Browseranfragen direkt aufgezeichnet und virtuellen Nutzerprofilen zugeordnet. Ein solches Profil entspricht einem Zugriffsverhalten, das sich z. B. durch eine bestimmte Klickfrequenz und Klickpfade auszeichnet. Hat z. B. Website Analytics ergeben, dass jeweils 1000 Geschäftskunden während der Mittagszeit zeitgleich auf eine mobile Wertpapierplattform zugreifen und 300 davon traden, 700 sich lediglich informieren, können Kundenprofile (z. B. Trader: Power-Trader und Freizeit-Trader; Infokunden: Chart-Surfer, Forumnutzer, News-Interessierte etc.) realitätsnah definiert werden. In der zweiten Phase werden die Zugriffsszenarien (z. B. gleichzeitig: 50 Power-Trader, 250 Freizeit-Trader; 300 Chart-Surfer, 330 News-Interessierte, 70 Forum-Surfer) abgespielt. Mithilfe von Lastgeneratoren (Servern mit aufgespielter Lasttestsoftware) werden die gewünschten Testnutzer (z. B. Power-Trader) bis zur benötigten Anzahl (z. B. 50) vervielfacht. Lasttests sollten dabei auch die Wahl der Browser (z. B. Safari, Google Chrome, Internet Explorer Mobile) in einem realistischen Verhältnis widerspiegeln. Ebenfalls gilt es, die regionale Verteilung der Kunden berücksichtigen. Hier bewährt sich die Lasttest-Cloud. Durch den gezielten Einsatz weltweit verteilter Server können z. B. auch Zugriffe auf den Online-Store simuliert werden, die aus dem Ausland gestartet werden. Der dritte Schritt ist die Auswertung. Sie stützt sich auf die quantifizierte Erfassung relevanter Kenngrößen, darunter:

  • Maximum der Nutzeranfragen, die der Server gleichzeitig verarbeiten kann
  • Abstand zwischen diesem Maximum und der durchschnittlichen Anzahl der Browseranfragen
  • Zeit, die der Server benötigt, um nach Traffic-Spitzen wieder zur erforderlichen Leistung zurückzufinden
  • Häufigkeit, mit der ein kompletter Neustart nach Überlast erforderlich ist
  • Verhältnis von Last zur Antwortzeit
  • Verhältnis von Überlast zu Time-outs/zu noch beantworteten Browseranfragen

Die Werte werden dann mit der für den Geschäftserfolg erforderlichen Zielperformance der Webanwendungen verglichen. Dabei wird vor allem geprüft, ob kritische Schwellenwerte überschritten sind, wie etwa die maximale Antwortzeit oder Fehlerraten, die Nutzer nach bisherigen Statistiken noch hinnehmen, ohne z. B. Bezahlvorgänge abzubrechen. Lasttests dienen dabei der Diagnostik (z. B. Identifizierung, Lokalisierung und Charakteristik der Engstellen), der Ursachenermittlung sowie der Handlungsempfehlung.

Die Besonderheiten mobiler Lasttests

Smartphones agieren weitgehend ähnlich wie Notebooks. Mobile und klassische Lasttests unterscheiden sich daher nur in wenigen, aber wichtigen Punkten. In dem methodischen Dreischritt „Recording“ (Vorbereitung: Definition virtueller Kundenprofile), „Playback“ (Durchführung:Zugriffssimulationen – virtuelle Testkundschaft auf Shoppingtour) und „Auswertung“ (Diagnostik, Ursachenermittlung, Handlungsempfehlung, Dokumentation) sind die Unterschiede vor allem in den ersten beiden Etappen angesiedelt.

Aufmacherbild: Doctor with a stethoscope in the hands on splash colors background von Shutterstock / Urheberrecht: everything possible

[ header = Recording, Playback und Auswertung ]

Recording: Definition und Aufzeichnung der Zugriffsszenarios

Zunächst gilt es zu ermitteln, welcher App-Typus getestet wird. Insbesondere sind native Apps von Web-Apps zu unterscheiden. Native Apps sind speziell für ein Betriebssystem und die spezifischen Schnittstellen eines Geräts programmiert. Diese Apps stammen in der Regel von Plattformen wie Android Market, BlackBerry App World oder iTunes. Demgegenüber ist eine Web-App eine mit modernen Technologien wie HTML5 oder Java erstellte „mobile“ Website, die für nahezu alle Browser ausgelegt ist oder das Endgerät erkennt und die Darstellung jeweils anpasst. Der dritte Typus ist eine Mischform, die hybride App. Sie liefert einen schnellen Zugang zu einem Smartphone-optimierten Webauftritt (Web-App) und schafft z. B. mit einem spezifischen Frame (native App) einen anbieterspezifischen Mehrwert.
Bei der Aufzeichnung der mobilen Zugriffe auf eine Web-App ist vergleichsweise wenig zu beachten. Ein moderner Desktop-PC-Browser kann die mobile Version einer Website fast immer problemlos darstellen. Wenn allerdings die Website mobile Endgeräte automatisch zu einer abgespeckten, weniger aufwändig gestalteten Version weiterleitet, muss der Desktop-PC-Browser so tun, als käme die Anfrage von einem mobilen Endgerät. Browser-Plug-ins ermöglichen in der Regel die Tarnung des klassischen Browsers als Tablet- oder Smartphone-Browser. Wird diese Tarnung nicht von einer modernen Lasttestsoftware unterstützt, muss der User Agent im Request Header händisch umgestellt werden. Da der Browser des aufzeichnenden PCs in der Lage sein muss, aktuelle Webtechnologien zu parsen und zu rendern, werden am besten aktuelle Versionen eingesetzt, also mindestens Explorer 9, Firefox 5, Chrome 15 oder Safari 5. Sind mobile Anwendungen mit WebKit-spezifischen Funktionalitäten ausgestattet, empfiehlt sich der Rückgriff auf den Chrome- oder Safari-Browser. Hybride Apps lassen sich ähnlich testen. In der Regel ist der URL der mobilen Website bekannt, sodass das Recording prinzipiell so verläuft wie bei jeder anderen Web-App auch.
Schwieriger ist die Aufzeichnung der Zugriffe, wenn es sich um native Apps handelt. Hier muss die Kommunikation zwischen dem Endgerät (bzw. einem PC, der im Rahmen des Testverfahrens ein mobiles Endgerät emuliert) und dem Server „abgefangen“ werden. Für diesen Mitschnitt sollte sich der aufzeichnende PC in demselben Netzwerk befinden wie das mobile Referenzgerät. Zudem darf der PC des Testspezialisten nicht hinter der Unternehmens-Firewall (im Intranet) positioniert sein, um den Datenverkehr eines Smartphones unter realitätsnahen Konnektivitäts- und Netzbedingungen aufzuzeichnen. Gute Lasttestlösungen bieten Proxy-basierte Aufzeichnungsfunktionen: In dem Fall ist es lediglich erforderlich, die WLAN-Einstellungen des mobilen Endgeräts so anzupassen, dass der Datenverkehr über diesen Proxy geht. Betriebssysteme wie iOS oder Android 4 ermöglichen das, ältere Android-Versionen nicht unbedingt. Zudem haben einige Apps die Eigenheit, sich ungeachtet der Proxy-Einstellungen direkt mit dem Server zu verbinden. Dann helfen zumeist nur spezielle Sniffer- oder Network-Capture-Tools beim Recording.
Ein weiteres Problem ergibt sich bei nativen Apps, wenn die Kommunikation mit dem Server HTTPS-gesichert ist. Der Versuch, den Datenverkehr über ein Proxy „abzuhören“, wird von dem mobilen Endgerät als Man-in-the-Middle-Angriff interpretiert. Während mobile oder Desktopbrowser Alarm schlagen, aber die Option bieten, den Proxy zuzulassen, unterbinden native Apps jedwede Verbindung zum Proxy. Ein Root-Zertifikat, das auf dem Endgerät installiert werden muss, ist zwingend erforderlich, um die Verbindung zum Proxy zu autorisieren. Einige Lasttestlösungen unterstützen dieses Verfahren, das bei iOS-Geräten problemlos funktioniert. Das Zertifikat wird einfach per Mail an das Smartphone gesendet, als Anhang geöffnet und ausgeführt. Bei anderen Plattformen wie Android hängt der Installationsaufwand stark von der jeweiligen Version des Betriebssystems oder auch der Gerätekonfiguration ab.

Playback: Testdurchführung und Lastsimulation

Unter dem Strich entscheidet die Zeit, die der „Roundtrip“ von der Browseranfrage an die Webserver bis zum Eingang der zurückgelieferten Daten beansprucht, über die Kundenzufriedenheit. Neben der Lasthärte der Webapplikationen (einschließlich der hinterlegten Datenbanken) und der Datenverarbeitungsleistung der Hardware sind die verfügbaren Datentransferraten eine kritische Einflussgröße auf die Antwortzeiten. Es empfiehlt sich daher, den Test von Webanwendungen nicht ausschließlich unter idealen DSL-Umgebungen durchzuführen, wie sie im Intranet bzw. hinter der Firewall zumeist vorliegen. Das ist generell wichtig, wenn die Nutzererfahrung in Regionen mit einer langsameren Netzgeschwindigkeit ermittelt werden soll, gilt aber in besonderem Maß für Mobilfunknetze. Bis 4G/LTE flächendeckend verfügbar ist, entsprechen sie in der Regel dem 3G-/UMTS-, seltener dem 3,5G- oder HSDPA-Standard. Bei starker Netzauslastung stehen regional und tageszeitabhängig teilweise nur Transferraten im GSM- oder GPRS-Bereich zur Verfügung. Im Rahmen realitätsnaher Lasttests sollten diese Bandbreitenbeschränkungen simuliert werden. Denn Webanwendungen, die unter Breitband-Ethernet/WLAN oder zumindest unter 3,5G-Bedingungen als reaktionsschnell wahrgenommen werden, können vom Kunden als zu langsam abgelehnt werden, wenn die Kombination aus niedrigeren Transferraten und Schwachstellen in den Webanwendungen Erinnerungen an gemächliche ISDN-Zeiten weckt. Zudem führen die – im Vergleich mit WLAN – langsameren 3G-Zugriffe zu mehr parallelem Traffic und bringen Webserver eher an Leistungsgrenzen bzw. an den Maximalwert, von dem an weitere Verbindungen zurückgewiesen werden. Scheitert der Verbindungsaufbau zum Server aufgrund von Überlastung, werden die Browseranfragen vom Nutzer immer wieder abgebrochenen und erneuert, sodass sich die Überlastung weiter verschärft. Die Simulation einer großen Zahl gleichzeitiger (3G-)Zugriffe ist deshalb ein wichtiger Aspekt mobiler Lasttestläufe. Weiterhin ist bei Lastsimulationen zu berücksichtigen, dass Smartphone-Kunden häufig sowohl WLAN- als auch Funknetze nutzen. Um authentische Ergebnisse zu erzielen, sollten auch die virtuellen Kunden jeweils beide Verbindungsarten im Wechsel testen.

Bandbreitensimulation: Datentransferraten gezielt einschränken

Bei den verfügbaren Datentransferraten weist Deutschland eine heterogene Verteilung auf: Während UMTS in Städten und HSDPA in ausgewählten Großstädten genutzt wird, sind ländliche Räume teilweise noch mit GSM, teilweise schon mit LTE versorgt. Authentizität und Exaktheit mobiler Lasttests hängen daher davon ab, virtuellen Nutzern jeweils eine eigene, individuell bestimmte Bandbreite zuordnen zu können. Das verdeutlicht ein Praxisbeispiel eines Lasttests, der prüft, ob 100 Smartphone-Kunden, die jeweils mit einem Datendurchsatz von 1 Mbps gleichzeitig auf eine Webshop-Funktion zugreifen, Antwortzeiten innerhalb der definierten Servicekorridors bietet. Die gesamte, für den Test erforderliche Bandbreite wäre dann 100 Mbps. Die Deckelung der im Testlabor verfügbaren 1 Gbps (oder mehr) auf diesen 100-Mbps-Wert kann grundsätzlich mit einer geeigneten WAN-Emulationssoftware oder einer Netzwerk-Appliance geleistet werden, die Bandbreite, Latenzzeit oder Paketverlust simuliert. WAN-Emulatoren können allerdings die Bandbreite nur als Ganzes, aber nicht individuell limitieren. Gerade das ist wichtig, um heterogene Testgruppen zu erzeugen, deren Mitglieder – wie in der Wirklichkeit – mit unterschiedlicher Geschwindigkeit (je nach Provider, Vertrag, Region) auf Webanwendungen zugreifen. Gegenüber WAN-Emulation ist daher eine Lasttestsoftware mit integrierter Bandbreitensimulation besser geeignet, um für jeden einzelnen virtuellen Nutzer Datentransferraten festzulegen und bedarfsgerecht zu skalieren.

Browsersimulation

Wenn ein Browser Inhalte von einem Webserver anfragt, identifiziert er sich über den User Agent Header selbst und häufig auch die Plattform, auf der er läuft. Webserver nutzen diese Informationen, um die passende Version der Webseite über so genannte Browserweichen auszuliefern. Dies ist nötig, da Browser nicht alle Webtechnologien adäquat unterstützen und dementsprechend einige Inhalte fehlerhaft darstellen würden. Die Plattformerkennung dient zum einen dazu, Formfaktoren (z. B. Tablets gegenüber Notebooks) oder Verbindungsarten (WLAN gegenüber 3G) zu differenzieren; zum anderen aber auch dazu, Subdifferenzierungen innerhalb des Tablet- oder Smartphone-Segments vorzunehmen (z. B. nach Displaygröße). Eine Serverweiche beeinflusst durch ihr dynamisches Antwortverhalten die Ladezeiten für jedes einzelne Endgerät. Und da der Server – je nach anfragendem Browser – unterschiedliche Datenvolumina ausliefert, beeinflusst die Browserweiche auch die Gesamtlast, die der Server verkraften muss. Daher ist die Möglichkeit, die User-Agent-Angaben im Header zu manipulieren und damit die Serverweiche gezielt in einem authentischen Browsermix anzusprechen, ein wichtiges Feature einer Lasttestlösung. Die Simulation verschiedener Browser und Plattformen ist noch aus einem anderen Grund von Bedeutung: Bekanntlich generieren Browser, egal ob klassisch oder mobil, parallele HTTP-Anfragen, um den Seitenaufbau zu beschleunigen. Das Maximum paralleler Anfragen ist allerdings von Browser zu Browser und je nach Plattform unterschiedlich. Browser und Plattformen, die eine hohe Anzahl paralleler Anfragen starten, verkürzen die Ladezeiten für das jeweilige Endgerät, erhöhen aber die Spitzenlast für den Server. Eine Lasttestlösung sollte diesen Zusammenhang adäquat abbilden und eine direkte Modifikation der User-Agent-Profile erlauben, um eine virtuelle Testgruppe zusammenzustellen, wie sie typischerweise zu bestimmten Zeiten auftritt. Dabei kann für jeden einzelnen Nutzer aus dieser Gruppe geprüft werden, ob er sich mit seinem Browser (Typ, Version, Firmware-Erweiterungen etc.) innerhalb der festgelegten „Service- und Komforttoleranzen“ bewegt.

Lasttests aus der Cloud

Die hohe Skalierbarkeit und 24/7-Verfügbarkeit machen die Cloud für Last- und Stresstests von Web-Apps interessant, zumal die Cloud methodisch einen Mehrwert schafft: Sie liefert eine Außensicht auf die eigene Serverinfrastruktur und damit Resultate, die häufig realistischer sind als bei Testverfahren unter Laborbedingungen hinter der Firewall. Die aus der „Wolke“ generierten Zugriffe auf Anwendungen können regional ausdifferenziert werden, wobei jeweils der gesamte Browseranfrage- und Antwortprozess ausgemessen und analysiert wird. Eine nahezu unbegrenzte Lasterzeugung, die hohe Kostenflexibilität (Pay-per-Use-Modelle) sowie reduzierte Investitionen in Hard- und Software gehören zu den Stärken der Cloud, die sie insbesondere bei drei Aufgaben ausspielt:

  • Apps und Websites „stressen“: Mit ihrer nahezu unbegrenzten Skalierbarkeit ist die Cloud gut geeignet, um Traffic-Spitzen zu erzeugen, wie sie in Online-Stores im Rahmen von Kampagnen, Social-Media-Hypes oder Produkteinführungen auftreten können. Hierfür auf eigene Server zu setzen, wäre verbunden mit erheblichen Investitionen in hochperformante Hardware, die für den relativ seltenen Fall einer Simulation von Last-Peaks ausgelegt sein müsste, ansonsten aber ungenutzt bliebe. Die On-Demand-Lasterzeugung ist dagegen ein vergleichsweise kostengünstiger Weg, Stresstests durchzuführen, die für die Einschätzung des Betriebsrisikos eines Webshops unerlässlich sind. Denn Stresstests helfen dabei, Stabilitätsgrenzen zu erkennen und zu ermitteln, wie sich die Verkaufsplattform jenseits dieser Limits verhält – z. B. mit Verlangsamung, einem Ansteigen der Fehlerrate, mit Absturz oder Rückkehr zur Normalität nach Ende eine Hochlastphase.
  • Regionale Besucherverteilung simulieren: Die Cloud erzeugt Last dort, wo auch die realen Nutzer sitzen und ihre Anfragen starten. Insbesondere können regional und international verteilte Besuchergruppen mit den weltweit vernetzen Lastgeneratoren der Cloud in beliebigem Umfang nachgebildet werden. Hat z. B. ein Webshop tagsüber meistenteils Kunden aus Europa, abends aus den USA, nachts aus Asien, können Cloud-basierte Lasttests die Zugriffe in der jeweiligen geografischen (Netz-)Verteilung und entsprechenden Größenordnung simulieren. Selbst ein landesspezifisches Kaufverhalten, typische Surfgewohnheiten, Plattform- und Browserpräferenzen oder regional verfügbare Bandbreiten können mit der Cloud abgebildet werden.
  • Den Gesamtprozess der Client-Server-Kommunikation abdecken: Mit ihren verteilten Servern kann die Cloud-Webapplikationen von außen, also aus der Nutzerperspektive, testen und bei Bedarf „stressen“. Firewall, Router, Internet, 3G-Netz und Load Balancer werden einbezogen, sodass die gesamte Lieferkette zwischen Webserver und Client (Servern, die die Browseranfragen generieren) abgebildet werden kann. Cloud-basierte Lasttests gewinnen weiter an Realitätsnähe, indem sie den Einfluss von Ad-Servern und anderen, von Drittanbietern gelieferten Technologien auf die Verfügbarkeit und Reaktionszeit eines Onlineangebots erfassen.

Dennoch sind Lasttests hinter der Firewall weiterhin eine wichtige Option. Dafür sprechen vor allem:

  • Sicherheit: Solange Anwendungen noch in der Entwicklung oder nicht ausreichend abgesichert sind, erfolgen Tests besser in geschützter Umgebung. Zunächst wird mit relativ wenigen virtuellen Nutzern nur die grundsätzliche Verfügbarkeit der Anwendung sichergestellt. Danach kann die Last vorsichtig erhöht werden. Steht die Infrastruktur für den Go-Live, können die externen Zugriffssimulationen aus der Cloud starten und bis zu Stressszenarien skaliert werden.
  • Schwachstellenlokalisierung: Um „hausgemachte“ Schwachstellen abzugrenzen gegen die, die jenseits der Firewall entstehen, sind komplementäre oder hybride Lasttests am besten geeignet. Ein Vergleich der Resultate, die jeweils mit der Cloud bzw. hinter der Firewall erzielt werden, zeigt, ob die Anwendungen oder doch eher eigene Netzwerkkomponenten, Lösungen von Drittanbietern oder externe Einflussgrößen (DNS-Server etc.) der Flaschenhals sind.

Die Cloud macht klassische Tests hinter der Firewall nicht überflüssig, sondern erweitert sie zu einem zweistufigen Verfahren. Eine Lasttestlösung sollte daher die Möglichkeit eröffnen, mit denselben virtuellen Nutzern alternierend aus der Cloud und innerhalb der eigenen Umgebung zu arbeiten.

Fazit

Für den Lasttest von Apps müssen IT-Verantwortliche nicht komplett umdenken. Zielstellung, Methoden und Prüfkriterien weichen nicht grundsätzlich von Zugriffssimulationen auf klassische Anwendungen ab. Was mobile Lasttests unterscheidet, ist die aufwändige Simulation der teilweise stark schwankenden Datentransferraten sowie die Vielzahl an Browserversionen, Betriebssystemen und Plattformen, die sich in ihrer Leistungsfähigkeit weit auffächern. Diese Besonderheiten mobiler Lasttests dürfen nicht vernachlässigt werden. Denn sie sind Schlüsselfaktoren, die das Nutzererlebnis eines kommerziellen Webangebotes stark beeinflussen. Sie sollten daher in Testläufen vollständig erfasst werden, um sicherzustellen, dass Kunden den Service erhalten, den Verkaufspsychologen und Marketingverantwortliche als erfolgskritisch definiert haben. Sollten Zielwerte – wie etwa maximale Antwortzeiten – verfehlt werden, helfen Lasttests dabei, die Ursachen zu ermitteln und festzustellen, ob die Beseitigung der Schwachstellen innerhalb des eigenen Handlungsbereichs gelingen kann. Während es in dem einen Fall möglich ist, die eigene Serverinfrastruktur für mehr Kundenkomfort zu optimieren, so ist es in anderen Fällen empfehlenswert, den Content so zu reduzieren, dass er zu den Datentransferraten passt, mit denen sich Smartphone-Nutzer und damit auch die Onlinewirtschaft bis auf Weiteres begnügen müssen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -