Smoke Test в мобилното разработване — какво е, задачи и как се прилага

Какво е Smoke Test?

Smoke Test (пушено тестване) е набор от бързи тестове, които проверяват основните функции на приложението без дълбока анализа. Терминът идва от хардуерното инженерство: ако устройство след събиране запуши, не се изпраща за пълно тестване. В мобилното разработване, Smoke Test изпълнява същата функция — отсейва предварително неработещи изграждания. Според Microsoft DevOps (2024), внедряването на Smoke Test намалява броя на дефектите, които достигат до QA екипа, с 40%.

Smoke Test се изпълнява на всяко ново изграждане — като на Android, така и на iOS. Идеално Smoke Test не трябва да продължава повече от 15 минути и трябва да се пуска автоматично след успешно изграждане. Критерий за преминаване — 100% от тестовете от набора Smoke Test трябва да приключат успешно. Ако поне един тест се провали, изграждането се маркира като нестабилно и не се изпраща за понататъшно тестване. Според Google Testing Blog (2024), този подход намалява времето за доставяне на функции до потребителите с 25%.

Smoke Test може да бъде като ръчен (контролен списък от 5–10 точки), така и автоматизиран. В съвременните мобилни проекти предпочитание се дава на автоматизирания Smoke Test, вграден в CI/CD. Ръчен Smoke Test е оправдан само в ранните етапи на проекта, когато автоматизацията не е икономически изгодна. Според Bitrise (2025), 73% от екиповете за мобилно разработване автоматизират Smoke Test.

Как Smoke Test се различава от регресионното тестване

Smoke Test и регресионното тестване често се бъркат, но това са различни практики с различни цели. Регресионното тестване проверява дали промените в кода не са развалили съществуващата функционалност. То покрива всички модули и сценарии на приложението, включително редки и гранични случаи. Smoke Test проверява само критичния път — основните сценарии, без които приложението е безполезно. Дълбочина на покритие — основната разлика: Smoke Test покрива 5–10% от функционалността, регресията — 80–100%.

Втората разлика — време за изпълнение. Регресионният набор за мобилно приложение може да отнеме от 2 до 12 часа в зависимост от размера на проекта и броя на платформите. Smoke Test отнима 5–15 минути. Според Sauce Labs (2025), средното време за изпълнение на регресионния набор за iOS приложение е 4,5 часа, за Android — 3,2 часа. Smoke Test и на двете платформи се помества в 10–15 минути.

Третата разлика — място в тръбопровода. Smoke Test се изпълнява веднага след изграждането, преди регресионното тестване. Ако Smoke Test не е преминат, регресията не се пуска — това пести ресурси на CI/CD. Pipeline efficiency — Smoke Test отсейва до 30% от изгражданията, които няма да преминат регресията, и икономените ресурси са достатъчни за паралелно изпълнение на други задачи.

Какво включва Smoke Test на мобилното приложение

Стартиране на приложението

Стартиране на приложението — първият и най-важният тест. Приложението трябва да стартира без краш на всички целеви устройства. Smoke Test проверява студен старт: инсталация → отваряне → показване на първия екран. Ако приложението се сгрива при стартиране, понататъшното тестване е безсмислено. XCUITest и Espresso позволяват автоматизиране на проверката за стартиране в 2–3 реда код. Launch argument `-AppleLanguages (bg)` помага да се провери локализацията при стартиране.

Авторизация

Авторизация — вторият критичен сценарий. Smoke Test трябва да провери дали формата за вход се показва, полета за въвеждане реагират на докосване, бутонът за вход изпраща заявка и приложението преминава към началния екран след успешна авторизация. Грешка при авторизацията блокира достъпа до всички други функции, етапа нейният проверка е част от минималния набор. Token refresh — допълнителна проверка за приложения с OAuth 2.0.

Зареждане на съдържание и навигация

Зареждане на основното съдържание — третият тест на Smoke Test. Началният екран или потокът на приложението трябва да се зареди и да покаже данни. Ако API не отговаря или анализът на отговора е повреден, потребителят вижда празен екран. Мрежовата проверка в Smoke Test включва основно GET заявка към основния endpoint и проверка, че отговорът има очакваната структура. Навигация — четвъртият сценарий. Smoke Test преминава през основните екрани на приложението: начало → търсене → профил → настройки. Лентата с раздели и страничното меню — типични източници на проблеми в навигацията, които Smoke Test открива в ранен етап.

Автоматизация на Smoke Test в CI/CD

Fastlane — стандартният инструмент за автоматизация на мобилно CI/CD. Smoke Test на Fastlane се пуска чрез `scan` (за XCUITest) или `gradle` (за Espresso). Fastlane позволява конфигуриране на Smoke Test на няколко устройства паралелно, което намалява общото време. Конфигурация в Fastfile включва цел за набора Smoke Test и праг за преминаване: 100% успешни тестове.

GitHub Actions (2024) публикува шаблон за мобилно CI/CD с вграден Smoke Test. Шаблонът включва три етапа: изграждане → Smoke Test → регресия. Ако Smoke Test се провали, шаблонът автоматично приключва тръбопровода и изпраща уведомление до Slack или Telegram. Matrix strategy позволява едновременно изпълнение на Smoke Test на три версии на iOS и пет модела на Android.

Разделение на отговорностите в CI/CD: Smoke Test отговаря за бърза обратна връзка, регресията за пълно покритие. Smoke Test не трябва да дублира регресията и обратно. Гранулност Smoke Test — една проверка на критичен сценарий. Ако Smoke Test отнима повече от 15 минути, трябва да се оптимизира: премахнете на излишните проверки или паралелизирайте изпълнението.

# Fastfile конфигурация за 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

Инструменти за Smoke Test

XCUITest — рамката на Apple за UI тестване на iOS приложения. XCUITest се използва за автоматизация на Smoke Test: стартиране на приложението, проверка на елементите на интерфейса, симулиране на потребителски действия. В комбинация с Xcode Server или GitHub Actions, XCUITest се изпълнява при всяко програмиране. XCTest — основната рамка за unit тестове, която допълва XCUITest за проверка на логиката.

Espresso — рамката на Google за UI тестване на Android. Espresso се синхронизира с UI нишката и гарантира, че всички анимации са приключени преди започването на проверката. Espresso поддържа проверка чрез `onView(withId(...)).check(matches(...))`. Android Test Orchestrator изпълнява всяка Smoke Test в отделен процес, което предотвратява повлиянето на предишните тестове върху следващите.

Detox — рамка за React Native, която поддържа Smoke Test и grey-box тестване. Detox се синхронизира с React Native bridge и автоматично чака за приключването на асинхронните операции. Grey-box тестване позволява на Detox да проверява състоянието на приложението без директен достъп до изходния код.

Пример за Smoke Test в Swift и Kotlin

XCUITest за iOS съдържа две проверки: стартиране на приложението и показване на началния екран. Тестът стартира приложението чрез `XCUIApplication().launch()` и проверява дали ключовият елемент (напр. `navigationBar`) съществува. Ако приложението се сгрива при стартиране, XCTest рамката записва грешката и тестът приключва с FAIL. Smoke Test не проверява съдържанието — само че екранът се отваря.

Espresso за Android използва `ActivityScenario` за стартиране на Activity и `onView` за проверка на елементите. Критичната разлика между платформите: iOS симулаторът може да покаже различно поведение от истинското устройство, затова се препоръчва Smoke Test на Android да се изпълнява на Firebase Test Lab или емулатор. Firebase Test Lab поддържа паралелно изпълнение на Smoke Test на 10 устройства.

import XCTest

class LoginSmokeTest: XCTestCase {
    let app = XCUIApplication()

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

    func testLoginButtonExists() {
        XCTAssertTrue(app.buttons["Влез"].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))
    }
}

Горният пример показва Smoke Test за екрана за вход в iOS. Първият тест проверява дали бутонът за вход съществува на екрана. Вторият тест преминава през цялия авторизационен път и проверява дали след успешно входване се показва приветствено съобщение. Timeout от 5 секунди за waitForExistence — стандартна стойност за Smoke Test: ако UI елементът не се покаже в това време, приложението не работи правилно.