Performance Test in der mobilen Entwicklung: Was es ist, Metriken und wie es durchgeführt wird

Was ist Performance Test?

Performance Test ist eine Art nicht-funktionaler Tests, der bestimmt, wie schnell und effizient eine Anwendung ihre Aufgaben ausführt. Im Gegensatz zu Unit-Tests oder UI-Tests misst Performance Test quantitative Merkmale: Antwortzeit, CPU-Last, RAM-Verbrauch und Akkunutzung. Laut dem Sauce Labs Bericht (2025) binden 68% der mobilen Entwicklungsteams Performance Test in ihren regelmäßigen Testzyklus ein, und 41% automatisieren ihn in CI.

Das Hauptziel von Performance Test ist sicherzustellen, dass die Anwendung die in der Dokumentation festgelegten Leistungsanforderungen erfüllt. Wenn die Bildschirmstartzeit 500 Millisekunden überschreitet oder die Anwendung mehr als 200 MB RAM auf einem durchschnittlichen Gerät verbraucht, ist das ein Signal zur Optimierung. Die Baseline für die Leistung wird beim ersten stabilen Release festgelegt und bei jedem großen Update überprüft.

Performance Test wird auf echten Geräten durchgeführt, nicht auf Simulatoren, da die Emulation kein genaues Bild der CPU-, GPU- und Netzwerkressourcennutzung liefert. Laut Apple WWDC (2024) zeigen Tests auf dem Simulator im Vergleich zu einem echten Gerät um 15–30% höhere Ergebnisse. Ein echtes Gerät bleibt die einzig verlässliche Quelle für Leistungsdaten.

Die Häufigkeit der Performance Test-Ausführung hängt vom Entwicklungszyklus ab. Gemäß den Google Android Performance Empfehlungen (2024) sollten Baseline-Messungen bei jedem Pull Request durchgeführt werden, eine vollständige Suite vor jedem Release. Die Automatisierung dieser Messungen ermöglicht die frühzeitige Erkennung von Leistungsregressionen.

Wichtige Leistungsmetriken

In der mobilen Entwicklung werden fünf Hauptmetriken identifiziert, die 90% der Performance Test-Szenarien abdecken. Die Startzeit (Cold Start und Warm Start) ist die erste Metrik, die bei jedem Release überprüft wird. Die Google Play Console (2024) zeichnet die Startzeit nach Schwellenwert auf: Cold Start sollte 5 Sekunden nicht überschreiten, Warm Start — 1,5 Sekunden. Die Überschreitung dieser Schwellenwerte wirkt sich direkt auf die Bewertung im App Store aus.

Startzeit (Cold Start)

Der Cold Start wird vom Tippen auf das Symbol bis zum ersten Frame der Anwendung gemessen. iOS verwendet `dispatch_async` für die verzögerte Initialisierung, was die sichtbare Startzeit verkürzt. Der Android Cold Start umfasst die Prozesserstellung, die Application-Initialisierung und den Activity-Start. Laut Google Performance (2024) reduziert jede 100 ms Verzögerung des Cold Starts die Conversion Rate in E-Commerce-Anwendungen um 1,2%.

Bildrate (FPS)

FPS (Frames Per Second) ist die Bildrate während Animationen und Listen-Scrolling. Eine flüssige Oberfläche erfordert stabile 60 FPS. Der Android Studio Profiler und der Xcode GPU Report zeigen FPS-Einbrüche bei schweren Operationen — Bildladen, JSON-Parsing oder komplexem Layout-Rendering. Ein Abfall unter 30 FPS wird vom Benutzer als Ruckeln wahrgenommen und führt laut Adjust (2025) zu einer Verringerung der Retention Rate um 22%.

RAM-Verbrauch

Der RAM-Verbrauch ist die dritte kritische Metrik. Speicherlecks sind die Hauptursache für Leistungseinbußen in langlebigen Sitzungen. Instruments Allocations und Android Memory Profiler helfen, zyklische Referenzen in Swift und nicht freigegebene Activities in Android zu erkennen. Der Akkuverbrauch ist eine Metrik, die beim Testen oft übersehen wird. Laut Apple Developer (2024) werden Anwendungen mit hohem Energieverbrauch im Hintergrund unter iOS eingeschränkt. Energy Log in Xcode zeichnet das Wattage-Profil der Anwendung pro Sitzung auf.

Arten von Leistungstests

Lasttest (Load Test) überprüft das Verhalten der Anwendung unter der erwarteten Anzahl gleichzeitiger Benutzer. Für ein mobiles Backend bedeutet dies die Simulation von 1000–10000 gleichzeitigen API-Anfragen. Die Serverseite muss die Spitzenlast bewältigen, ohne die Antwortzeit um mehr als 20% gegenüber dem Basiswert zu erhöhen. Laut k6 Benchmarks (2024) umfasst eine typische Load Test-Konfiguration eine Rampe von 0 auf 1000 VUs (virtuelle Benutzer) über 5 Minuten.

Stresstest (Stress Test) bestimmt den Bruchpunkt der Anwendung — den Moment, in dem das System nicht mehr auf Anfragen reagiert oder inakzeptabel degradiert. Im Gegensatz zum Load Test belastet der Stress Test das System über normale Grenzen hinaus. Der Bruchpunkt wird anhand eines der Kriterien aufgezeichnet: Antwortzeit überschreitet 10 Sekunden, 5XX-Fehlerprozentsatz überschreitet 5%, oder RAM-Verbrauch erreicht 90% des verfügbaren Speichers.

Volumentest (Volume Test) bewertet das Verhalten der Anwendung bei der Arbeit mit großen Datenmengen. Im mobilen Kontext umfasst dies Tests mit Tausenden von Datensätzen in einer lokalen Datenbank, Dutzenden Gigabyte Cache oder Millionen von Push-Benachrichtigungen. SQLite unter Android und Core Data unter iOS zeigen unterschiedliche Leistung bei über 100.000 Datensätzen.

Werkzeuge für Performance Test

Xcode Instruments

Xcode Instruments ist das wichtigste Werkzeug zum Profiling von iOS-Anwendungen. Der Time Profiler zeigt, welche Methoden am meisten CPU verbrauchen, während Allocations die Speicherzuweisung und -freigabe verfolgt. Instruments unterstützt die Aufzeichnung über lange Sitzungen (bis zu 30 Minuten) und den Export von Traces zum Vergleich zwischen Builds. Activity Monitor in Instruments zeigt die Gesamtsystemlast in Echtzeit.

Android Studio Profiler

Android Studio Profiler ist der integrierte Profiler für Android. Er vereint CPU-, Speicher-, Netzwerk- und Energieprofiler in einer einzigen Oberfläche. Eine Besonderheit von Android Profiler ist die Unterstützung interaktiver Sitzungen: Entwickler können Aktionen in der Anwendung ausführen und die sofortige Reaktion der Metriken sehen. Laut Google I/O (2024) unterstützt Profiler die Aufzeichnung im .perf-Format, das mit einer Baseline in CI verglichen werden kann.

Charles Proxy

Charles Proxy und Proxyman sind Werkzeuge zur Analyse des Netzwerkverkehrs. Sie zeigen die Zeit jeder HTTP-Anfrage, Antwortgröße und Header. Für Performance Test ist es wichtig, Anfragen zu erfassen, die länger als 500 ms dauern — diese sind Kandidaten für Caching oder Optimierung. Charles unterstützt den Throttle-Modus zur Simulation langsamer Netze: 3G, Edge und LTE. Proxyman ist eine leichtere Alternative für macOS mit nativer Swift-Architektur.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

Performance Test in der CI/CD-Pipeline

Die Integration von Performance Test in CI/CD ist der Industriestandard für 2025–2026. Die Leistungspipeline umfasst drei Phasen: Pre-Commit (schnelle Messungen bei Pull Request), Nightly (vollständige Testsuite) und Pre-Release (Vergleich mit Baseline auf Referenzgeräten). Bitrise und GitHub Actions unterstützen die Ausführung von Xcode Instruments CLI und Gradle Profiler.

GitHub Actions (2024) hat eine offizielle Vorlage für iOS Performance Test mit `xcodebuild test-without-building` veröffentlicht. Die Vorlage führt Tests auf einer der GitHub-Maschinen aus und veröffentlicht den Bericht als Artefakt. Die Baseline wird in einer JSON-Datei im Repository gespeichert: bei Überschreitung des Schwellenwerts um 10% schlägt die Pipeline mit einem Fehler fehl. Dieser Ansatz verhindert Leistungseinbußen ohne manuelle Überprüfung jedes Builds.

Das Problem mobiler Performance Tests in CI ist die Instabilität der Ergebnisse auf verschiedenen Maschinen. Apple Silicon (M1–M4) und Intel Xeon liefern unterschiedliche Ausführungszeiten. Die Lösung ist die Verwendung eines prozentualen Verhältnisses zur Baseline anstelle absoluter Werte. Wenn ein Test 15% länger als die Baseline dauert, wird der Build als überprüfungsbedürftig markiert.

Performance Tests unter iOS und Android schreiben

XCTest Performance unter iOS verwendet die Methode `measure(metrics:)`, die einen Codeblock 10 Mal ausführt und Statistiken zurückgibt: Mittelwert, Median, Standardabweichung. Für Datenbankleistungstests verwendet XCTest bequemerweise XCTMemoryMetric, das den Spitzen-RAM-Verbrauch erfasst. Der Schwellenwert wird nach Abschluss des Tests über `XCTPerformanceReport` festgelegt.

Android Macrobenchmark ist eine Bibliothek von Google zur Leistungsmessung auf Anwendungsebene. Macrobenchmark führt Benutzerszenarien (Activity-Start, RecyclerView-Scrolling, WebView-Öffnung) aus und misst die Ausführungszeit. Baseline Profile ist eine Reihe von Klassen und Methoden, die der Android-Compiler voroptimiert. Google Play verwendet Baseline Profile, um den ersten Start um 30% zu beschleunigen.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

Beide Ansätze — XCTest Performance und Android Macrobenchmark — verwenden dasselbe Konzept: wiederholte Messung mit Mittelwertbildung und Vergleich mit einem Schwellenwert. Leistung kann nicht auf eine einzelne Zahl reduziert werden. Jeder Release sollte von einem Leistungsbericht begleitet werden, der die Metrik-Trends der letzten 5 Builds enthält. Ein solcher Bericht ermöglicht es dem Team, eine Verschlechterung zu erkennen, bevor die Benutzer sie bemerken.