Smoke Test in der mobilen Entwicklung — was es ist, Aufgaben und wie es angewendet wird

Was ist ein Smoke Test?

Smoke Test ist eine Reihe schneller Tests, die die Kernfunktionen einer Anwendung ohne tiefgehende Analyse überprüfen. Der Begriff stammt aus der Hardwaretechnik: Wenn ein Gerät nach der Montage zu rauchen beginnt, wird es nicht zur vollständigen Prüfung geschickt. In der mobilen Entwicklung erfüllt der Smoke Test dieselbe Funktion — er filtert offensichtlich nicht funktionsfähige Builds heraus. Laut Microsoft DevOps (2024) reduziert die Einführung eines Smoke Tests die Anzahl der Fehler, die das QA-Team erreichen, um 40%.

Ein Smoke Test wird bei jedem neuen Build ausgeführt — sowohl auf Android als auch auf iOS. Idealerweise sollte ein Smoke Test nicht länger als 15 Minuten dauern und automatisch nach einem erfolgreichen Build starten. Bestanden-Kriterium — 100% der Tests im Smoke-Test-Satz müssen erfolgreich abgeschlossen werden. Wenn auch nur ein Test fehlschlägt, wird der Build als instabil markiert und nicht zur weiteren Prüfung gesendet. Laut Google Testing Blog (2024) reduziert dieser Ansatz die Zeit für die Auslieferung von Funktionen an die Benutzer um 25%.

Ein Smoke Test kann manuell (eine Checkliste mit 5–10 Punkten) oder automatisiert sein. In modernen mobilen Projekten wird einem automatisierten, in CI/CD integrierten Smoke Test der Vorzug gegeben. Manueller Smoke Test ist nur in frühen Projektphasen gerechtfertigt, wenn die Automatisierung wirtschaftlich nicht sinnvoll ist. Laut Bitrise (2025) automatisieren 73% der mobilen Entwicklungsteams ihre Smoke Tests.

Wie unterscheidet sich ein Smoke Test vom Regressionstest?

Smoke Test und Regressionstests werden oft verwechselt, aber es sind unterschiedliche Praktiken mit unterschiedlichen Zielen. Regressionstests überprüfen, ob Änderungen am Code die bestehende Funktionaliteit nicht beeinträchtigt haben. Sie decken alle Module und Szenarien der Anwendung ab, einschließlich seltener und Grenzfälle. Ein Smoke Test prüft nur den kritischen Pfad — die wichtigsten Szenarien, ohne die die Anwendung nutzlos ist. Abdeckungstiefe ist der Hauptunterschied: Smoke Test deckt 5–10% der Funktionalität ab, die Regression 80–100%.

Der zweite Unterschied ist die Ausführungszeit. Ein Regressionstest-Set für eine mobile Anwendung kann je nach Projektgröße und Anzahl der Plattformen 2 bis 12 Stunden dauern. Ein Smoke Test dauert 5–15 Minuten. Laut Sauce Labs (2025) beträgt die durchschnittliche Ausführungszeit eines Regressionstest-Sets für eine iOS-Anwendung 4,5 Stunden und für Android 3,2 Stunden. Ein Smoke Test auf beiden Plattformen ist in 10–15 Minuten abgeschlossen.

Der dritte Unterschied ist die Position in der Pipeline. Ein Smoke Test wird unmittelbar nach dem Build, vor dem Regressionstest, ausgeführt. Wenn der Smoke Test fehlschlägt, wird die Regression nicht gestartet — das spart CI/CD-Ressourcen. Pipeline-Effizienz — ein Smoke Test filtert bis zu 30% der Builds heraus, die in der Regression durchgefallen wären, und die eingesparten Ressourcen reichen aus, um andere Aufgaben parallel auszuführen.

Was ist in einem Smoke Test einer mobilen App enthalten

App-Start

App-Start — der erste und wichtigste Test. Die Anwendung muss auf allen Zielgeräten ohne Absturz starten. Ein Smoke Test überprüft den Kaltstart: Installieren → Öffnen → Anzeigen des ersten Bildschirms. Wenn die App beim Start abstürzt, sind weitere Tests sinnlos. XCUITest und Espresso ermöglichen die Automatisierung der Startprüfung in 2–3 Codezeilen. Startargument `-AppleLanguages (ru)` hilft, die Lokalisierung beim Start zu überprüfen.

Authentifizierung

Authentifizierung — das zweite kritische Szenario. Ein Smoke Test muss überprüfen, ob das Login-Formular angezeigt wird, die Eingabefelder auf Berührung reagieren, der Login-Button eine Anfrage sendet und die Anwendung nach erfolgreicher Authentifizierung zum Hauptbildschirm navigiert. Ein Authentifizierungsfehler blockiert den Zugriff auf alle anderen Funktionen, daher ist seine Prüfung im minimalen Satz enthalten. Token-Refresh — eine zusätzliche Prüfung für Anwendungen mit OAuth 2.0.

Laden von Inhalten und Navigation

Laden der Hauptinhalte — der dritte Smoke Test. Der Hauptbildschirm oder Feed der Anwendung muss geladen werden und Daten anzeigen. Wenn die API nicht antwortet oder die Antwortanalyse defekt ist, sieht der Benutzer einen leeren Bildschirm. Die Netzwerkprüfung in einem Smoke Test umfasst eine grundlegende GET-Anfrage an den Hauptendpunkt und die Überprüfung, ob die Antwort die erwartete Struktur aufweist. Navigation — das vierte Szenario. Ein Smoke Test navigiert durch die Hauptbildschirme der Anwendung: Start → Suche → Profil → Einstellungen. Die Registerkartenleiste und das Seitenmenü sind typische Quellen für Navigationsprobleme, die ein Smoke Test frühzeitig erkennt.

Automatisierung von Smoke Tests in CI/CD

Fastlane — das Standardwerkzeug zur Automatisierung mobiler CI/CD. Ein Smoke Test in Fastlane wird über `scan` (für XCUITest) oder `gradle` (für Espresso) ausgeführt. Fastlane ermöglicht die parallele Ausführung von Smoke Tests auf mehreren Geräten, was die Gesamtzeit verkürzt. Konfiguration in der Fastfile enthält das Ziel des Smoke-Test-Sets und eine Bestehensschwelle: 100% erfolgreiche Tests.

GitHub Actions (2024) hat eine mobile CI/CD-Vorlage mit integriertem Smoke Test veröffentlicht. Die Vorlage umfasst drei Stufen: Build → Smoke Test → Regression. Wenn der Smoke Test fehlschlägt, beendet die Vorlage automatisch die Pipeline und sendet eine Benachrichtigung an Slack oder Telegram. Matrix-Strategie ermöglicht die gleichzeitige Ausführung des Smoke Tests auf drei iOS-Versionen und fünf Android-Modellen.

Aufgabenteilung in CI/CD: Der Smoke Test sorgt für schnelles Feedback, während die Regression für vollständige Abdeckung sorgt. Der Smoke Test sollte die Regression nicht duplizieren und umgekehrt. Granularität des Smoke Tests — eine Prüfung pro kritischem Szenario. Wenn ein Smoke Test länger als 15 Minuten dauert, muss er optimiert werden: überflüssige Prüfungen entfernen oder die Ausführung parallelisieren.

# Fastfile-Konfiguration für Smoke Test
platform :ios do
    lane :smoke do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone SE'],
            testplan: 'SmokeTest',
            output_directory: 'reports/smoke',
            fail_build: true
        )
    end

    lane :regression do
        scan(
            scheme: 'App',
            devices: ['iPhone 15', 'iPhone 14', 'iPhone SE'],
            testplan: 'FullRegression'
        )
    end
end

Werkzeuge für Smoke Tests

XCUITest — Apples Framework für UI-Tests von iOS-Anwendungen. XCUITest wird zur Automatisierung von Smoke Tests verwendet: Starten der App, Überprüfen von UI-Elementen, Simulieren von Benutzeraktionen. In Kombination mit Xcode Server oder GitHub Actions wird XCUITest bei jedem Commit ausgeführt. XCTest — das Basisframework für Unit-Tests, das XCUITest zur Logikprüfung ergänzt.

Espresso — Googles Framework für UI-Tests von Android. Espresso synchronisiert mit dem UI-Thread und stellt sicher, dass alle Animationen abgeschlossen sind, bevor die Prüfung beginnt. Espresso unterstützt Prüfungen über `onView(withId(...)).check(matches(...))`. Android Test Orchestrator führt jeden Smoke Test in einem separaten Prozess aus, wodurch verhindert wird, dass vorherige Tests nachfolgende beeinflussen.

Detox — ein Framework für React Native, das Smoke Tests und Grey-Box-Tests unterstützt. Detox synchronisiert mit der React-Native-Brücke und wartet automatisch auf den Abschluss asynchroner Vorgänge. Grey-Box-Tests ermöglichen es Detox, den Zustand der Anwendung ohne direkten Zugriff auf den Quellcode zu überprüfen.

Beispiel eines Smoke Tests in Swift und Kotlin

XCUITest für iOS enthält zwei Prüfungen: Starten der Anwendung und Anzeigen des Hauptbildschirms. Der Test startet die App über `XCUIApplication().launch()` und prüft, ob ein Schlüsselelement (z. B. `navigationBar`) vorhanden ist. Wenn die App beim Start abstürzt, zeichnet das XCTest-Framework den Fehler auf und der Test endet mit FAIL. Smoke Test prüft nicht den Inhalt — nur, dass der Bildschirm geöffnet wurde.

Espresso für Android verwendet `ActivityScenario` zum Starten einer Activity und `onView` zum Prüfen von Elementen. Ein kritischer Unterschied zwischen den Plattformen: Der iOS-Simulator kann ein anderes Verhalten als ein echtes Gerät zeigen, daher wird empfohlen, Android-Smoke-Tests auf Firebase Test Lab oder einem Emulator auszuführen. Firebase Test Lab unterstützt die parallele Ausführung von Smoke Tests auf 10 Geräten.

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["Anmelden"].exists)
    }

    func testLoginFlow() {
        app.textFields["email"].tap()
        app.textFields["email"].typeText("test@test.com")
        app.secureTextFields["password"].tap()
        app.secureTextFields["password"].typeText("password123")
        app.buttons["Log In"].tap()
        XCTAssertTrue(app.staticTexts["Welcome"].waitForExistence(timeout: 5))
    }
}

Das obige Beispiel zeigt einen Smoke Test für den Login-Bildschirm unter iOS. Der erste Test prüft, ob der Login-Button auf dem Bildschirm vorhanden ist. Der zweite Test durchläuft den vollständigen Authentifizierungspfad und prüft, ob nach erfolgreichem Login eine Begrüßungsnachricht angezeigt wird. Timeout von 5 Sekunden für `waitForExistence` ist der Standardwert für einen Smoke Test: Wenn das UI-Element in dieser Zeit nicht erscheint, funktioniert die Anwendung nicht richtig.