Apps sollen vor allem schnell produziert werden und in der Entwicklung wenig kosten. Das Kostendiktat steht dabei im Gegensatz zu den hohen Qualitätsvorgaben - denn der Erfolg von App-basierten Marketingaktionen und Geschäftsmodellen hängt nicht zuletzt vom reibungslosen Funktionieren der Software ab. Eine auf Anhieb flüssige Performance ist daher Minimalanforderung für mobile Anwendungen.
Foto: Maksym Yemelyanov - Fotolia.com
Dies sicherzustellen, ist eine komplexe Aufgabe angesichts der Heterogenität der Endgeräte und Betriebssysteme mit ihren unterschiedlichen Versionen. Hinzu kommen Schwankungen in den verfügbaren Datenraten - jeweils in Abhängigkeit von regionalen Netzqualitäten, Zugriffen und Tageszeiten.
Es empfiehlt sich, die hohen Leistungs- und Qualitätserwartungen für Apps mit umfassenden Last- und Performance-Tests abzusichern. Dabei verdienen sechs wesentliche Bestandteile besondere Berücksichtigung:
Methodik: Agile - frühes Testen mit hoher Frequenz
Silodenken aufgeben: Tester sollten sich kontinuierlich im Team abstimmen und verständlich aufbereite Resultate mit den Entwickeln teilen
Für eine hohe Prozesseffizienz müssen App-Entwickler und -Tester ihre Zusammenarbeit enger aufeinander abstimmen als früher. Qualitätsmanagement ist nicht mehr nur retrospektiv, sondern begleitet "live" die Entstehung neuer Software. Die Performance-Prüfung sollten daher schon im Vorhinein eng mit Entwicklern koordiniert werden.
Fachübergreifende Interaktion: Performance-Prüfung in einem Tool konsolidieren.
"Agile" steht für interaktive Problemlösungen jenseits von Bereichsdenken. Damit Teammitglieder mit ihrer jeweiligen Expertise Hand in Hand bei Prüfroutinen zusammenwirken, sollten Test-Tools kollaborativ genutzt werden. Die Option, Elemente wie virtuelle Benutzer, Überwachungskonfigurationen, Lastprofile und Testergebnisse mit Teammitgliedern zu teilen, unterstützt diese Arbeitsweise. Grafische Nutzeroberflächen für eine intuitive Definition auch von komplexen Szenarien und die Wiederverwendbarkeit grundlegender Skripte (z.B. An- und Abmeldevorgänge) helfen "Performance-Laien" (z.B. Entwicklern) sich in die Qualitätssicherung einzubringen.
Lasthärte nachweisen: Leistungs-SLAs in den "Definition of Done"-Listen hinterlegen
Agile-Teams widmen der Performance-Optimierung häufig zu wenig Aufmerksamkeit. User Stories werden dann typischerweise aus funktionaler Perspektive geschrieben, z. B: "Als Benutzer kann ich auf die Schaltfläche 'Warenkorb anzeigen' klicken und die Seite 'Mein Warenkorb' anzeigen." Vollständig wäre die User Story allerdings erst, wenn sie auch messbare Performance-Anforderungen spezifiziert, z. B: "Als Benutzer kann ich auf die Schaltfläche 'Warenkorb anzeigen' klicken und die Seite 'Mein Warenkorb' in weniger als einer Sekunde anzeigen, während bis zu 1.000 andere Benutzer gerade dasselbe tun." Ähnlich wie Funktionstests sind Leistungschecks ein verbindlicher Punkt in der "Definition of Done"-Agenda. Eine Story- und Code-Modifikation sollte erst als "erledigt" gelten, wenn sie die SLA-Vorgaben erfüllt, z. B: "Jede Webpage muss mit allen Funktionserweiterungen auch weiterhin in weniger als einer Sekunde geladen sein."
CI-Integration: Testläufe automatisieren, um Produktionsprozesse möglichst wenig zu belasten
Kontinuierliche Integration (CI) und der direkte Übergang zwischen Agile-Entwicklung und Betrieb (DevOps) verlangen einen intensiven Austausch zwischen Produktion und Qualitätskontrolle. Prüfroutinen (Performance-, Rauch- und Regressionstests) sollten daher für jeden Entwicklungsschritt hinterlegt, automatisiert und am besten direkt mit dem Build-Server integriert werden. Eine vollständige Testeinbettung sieht vor, dass die Ergebnisse sofort im Build-Tool angezeigt und mit den aktuellen Entwicklungsleistungen bzw. Build-Operationen korreliert werden. Auf diese Weise werden Ursachen für Performance-Schwächen leicht eingegrenzt und zügig beseitigt.
Schnell-Tests: Prüfroutinen an die unterschiedlichen Build-Größen anpassen
CI-Builds, nächtliche Builds und zum Sprint-Abschluss erstellte Builds unterscheiden sich deutlich in ihrem Umfang. Daher sollten Lasttests an Art und Größe des ausgeführten Builds angepasst werden. Generell hat es sich bewährt, im kleinen Rahmen zu beginnen.
Bei CI-Builds sollten Tests umgehend nach der Übergabe einer Änderung ausgeführt werden, damit der Entwickler direkt die Auswirkungen auf das System erkennt. Dazu eignen sich am besten begrenzte Performance- und Rauch-Tests, die die am weitesten verbreiteten Szenarien abdecken, wobei die Last üblicherweise von internen Lastgeneratoren (On-Premise-Servern) erzeugt wird.
Bei nächtlichen Builds sollten bereits Ausnahmefälle simuliert werden, um Performance-Probleme zu ermitteln, die bei CI-Tests unentdeckt blieben. Am Ende des Sprints werden Anwendungen "gestresst", indem das Team Last aus der Cloud maximal skaliert, um Belastungsgrenzen, Fehlerbilder und Erholungszeiten einer Anwendung nach einem Absturz festzustellen.
Endgeräte: Die Vielfalt der Smartphones & Tablets simulieren
Die Vielzahl mobiler Betriebssysteme und Browserversionen macht Serverweichen erforderlich. Sie sorgen dafür, dass die passenden Website-Versionen ausgeliefert werden, die von dem jeweiligen Browser unterstützt werden. Mobile Browser identifizieren sich mit ihrem User-Agent-Header und liefern Informationen über Betriebssystem, Formfaktor, Verbindungsart und Gerätekonfiguration.
Da je nach anfragendem Browser unterschiedliche Datenvolumina ausgeliefert werden, beeinflussen Serverweichen die Ladezeiten für jedes Endgerät sowie die Server-Gesamtlast. User-Agent-Angaben zu manipulieren und die Serverweiche gezielt in einem wirklichkeitsnahen Browser-Mix anzusprechen, ist daher wichtig für authentische Testresultate.
Noch aus einem anderen Grund ist die Simulation einer realitätsnahen Browser-Verteilung wichtig: Browser beschleunigen den Seitenaufbau mit parallelen HTTP-Anfragen, deren Maximum wiederum Browser-spezifisch ist. Browser mit einer hohen Anzahl paralleler Anfragen, verkürzen Ladezeiten, erhöhen aber die Spitzenlast für Server. Es empfiehlt sich daher, eine Testpopulation mit typischen Browser-Präferenzen zusammenstellen. Dann lässt sich zuverlässig ermitteln, ob sich alle Nutzer mit ihrer jeweiligen Browserversion innerhalb der festgelegten "Komforttoleranzen" bewegen.
Netzqualität: Datenraten realitätsnah emulieren
Zur authentischen Ermittlung der Nutzererfahrung in Mobilfunknetzen sollten Lasttests nicht ausschließlich unter idealen LTE-Umgebungen erfolgen. Hier empfiehlt sich eine Testsoftware mit integrierter Bandbreitensimulation, die virtuellen Nutzern jeweils individuell Datentransferraten zuordnet. Die Deckelung der im Testlabor verfügbaren Bandbreiten gelingt auch mit WAN-Emulationssoftware, die Bandbreite, Latenzzeit oder Paketverlust simuliert. Der Nachteil: WAN-Emulatoren limitieren die Bandbreite als Ganzes, nicht für einzelne Test-Nutzer. Aber gerade darauf kommt es an, da Anwender in der Wirklichkeit je nach Provider, Vertrag oder Region mit unterschiedlicher Geschwindigkeit auf Webanwendungen zugreifen. Hier gilt es, mit flexibler Bandbreitensimulation heterogene Testpopulationen zu erzeugen, damit ein differenziertes Bild der Nutzerzufriedenheit entsteht.
Das Gesamtbild: Kommunikation zwischen Smartphone und Server komplett erfassen
Für den Lasttest muss zunächst die bestehende Kommunikation zwischen Server und Smartphone erfasst und aufgezeichnet werden. Bei nativen Apps kann dies anspruchsvoll sein, da hierzu die Server-Client Kommunikation abgefangen werden muss. Gute Lasttestlösungen bieten Proxy-Optionen, um den Datenverkehr umleiten und mitschneiden zu können. Falls Apps sich ungeachtet der Proxy-Einstellungen weiterhin direkt mit dem Server verbinden, bleibt der Rückgriff auf Network-Capture-Tools ("Sniffer").
Schwierig wird es bei einer HTTPS-verschlüsselten Kommunikation, da das Mitschneiden des Datenverkehrs über einen Proxy als Man-in-the-Middle-Angriff vereitelt wird. Während mobile Browser den Proxy optional zulassen, unterbinden native Apps dies häufig rigoros. Dann muss der Proxy eigens mit einem Root-Zertifikat autorisiert werden. Bei iOS-Geräten ist das unproblematisch, indem das Zertifikat einfach per Mail angefordert und installiert wird. Bei Android-Plattformen hängt der Installationsaufwand von Version und Gerätekonfiguration ab.
Performance: Hybride Lasttests für hoch skalierbarere Leistungschecks
Apps stressen: Traffic-Spitzen mit der Cloud erzeugen
Mit der fast unbegrenzt skalierbaren Cloud lassen sich gut Traffic-Spitzen erzeugen. Tester können dies nutzen, um Apps zu stressen und damit z.B. App-basierte Produkteinführungen im Online-Store abzusichern.
Realitätsnah testen: Regionale Besucherverteilung simulieren
Die Cloud erzeugt Last dort, wo Nutzer ihre Anfragen starten. Mit weltweit vernetzen Lastgeneratoren können regional ausdifferenzierte Besuchergruppen in beliebigem Umfang generiert werden. Haben Webshops tagsüber meistenteils Kunden aus Europa und abends aus den USA, lassen sich Zugriffe in der jeweiligen geografischen Verteilung simulieren. Dabei können Tester u.a. landesspezifischen Kauf- und Surfgewohnheiten, Plattform- und Browserpräferenzen sowie lokal verfügbaren Bandbreiten Rechnung tragen.
Aus Nutzersicht testen: Abdeckung der kompletten Server-Client-Lieferkette
Um Apps aus der Nutzerperspektive zu testen, sind Cloud-basierte Server (Lastgeneratoren) am besten geeignet. Denn hier werden Firewall, Router, Internet, Mobilfunknetze und Load Balancer gleich mit einbezogen. Die vollständige Abdeckung der Server-Client-Lieferkette erfasst bei Bedarf auch den Einfluss von Drittanbieter-Technologien (u.a. Ad-Server) auf Verfügbarkeit und Reaktionszeiten der Apps.
Sicherheit: Last erst niedrig dosieren, dann bis zum Maximum (und darüber hinaus) skalieren
Für Anwendungen, die noch in der Entwicklung und nicht ausreichend geschützt sind, empfehlen sich Tests hinter der Firewall mit wenigen virtuellen Nutzern. Damit wird die grundsätzliche Verfügbarkeit der Anwendung sichergestellt, bevor das Lastverhalten geprüft wird.
Schwachstellen-Lokalisierung: Interne und Externe Lasttests im Zusammenspiel
Um "hausgemachte" Schwachstellen abzugrenzen gegen die, die jenseits der Firewall entstehen, sollten interne und Cloud-basierte Lasttests ineinandergreifen. Der Vergleich der Resultate, die mit der Cloud bzw. hinter der Firewall erzielt werden, bringt Klarheit, ob eigene Anwendungen oder externe Faktoren wie DNS-Server der "Flaschenhals" sind. Idealerweise arbeiten Tester mit denselben virtuellen Nutzern abwechselnd aus der Cloud und innerhalb der Firewall.
App-Monitoring: Prüfung der Leistung und Verfügbarkeit im Produktivbetrieb
Auch nach dem Go-Live sollte die App-Performance weiter kontrolliert werden. Am besten verwenden Tester dafür dieselben Testpopulationen wie in ihren Lasttests. Mit ausgewählten virtuellen Nutzern lässt sich dann prüfen, ob die vereinbarten Zielwerte auch im Produktivbetrieb erreicht und dauerhaft gehalten werden. Das gesamte Leistungsmonitoring sollte dabei eng zwischen den IT- und Geschäftsverantwortlichen abgestimmt werden - denn Stabilität und Geschwindigkeit einer App machen häufig den Unterschied bei der Marktakzeptanz von Mobilen Service-Angeboten. (mb)