Smoke Test در توسعه موبایل — چیست، وظایف و چگونه استفاده می‌شود

Smoke Test چیست؟

Smoke Test (تست دودی) — مجموعه‌ای از تست‌های سریع است که توابع اصلی اپلیکیشن را بدون تحلیل عمیق بررسی می‌کنند. این اصطلاح از مهندسی سخت‌افزار گرفته شده است: اگر دستگاه پس از مونتاژ دود کند، برای تست کامل ارسال نمی‌شود. در توسعه موبایل، Smoke Test همان وظیفه را انجام می‌دهد — بیلدهای از پیش غیرقابل استفاده را جدا می‌کند. به گفته Microsoft DevOps (2024)، پیاده‌سازی Smoke Test تعداد نقص‌هایی که به تیم QA می‌رسد را ۴۰٪ کاهش می‌دهد.

Smoke Test روی هر بیلد جدید — هم در Android و هم در iOS — انجام می‌شود. در حالت ایده‌آل، Smoke Test نباید بیش از ۱۵ دقیقه طول بکشد و باید پس از بیلد موفق به صورت خودکار اجرا شود. معیار قبولی — ۱۰۰٪ تست‌های مجموعه Smoke Test باید با موفقیت به پایان برسند. اگر حداقل یک تست شکست بخورد، بیلد به عنوان ناپایدار علامت‌گذاری می‌شود و برای تست بیشتر ارسال نمی‌شود. به گفته Google Testing Blog (2024)، این رویکرد زمان تحویل ویژگی‌ها به کاربران را ۲۵٪ کاهش می‌دهد.

Smoke Test می‌تواند هم دستی (چک‌لیست ۵–۱۰ موردی) و هم خودکار باشد. در پروژه‌های مدرن موبایل، Smoke Test خودکار تعبیه‌شده در CI/CD ترجیح داده می‌شود. Smoke Test دستی فقط در مراحل اولیه پروژه، زمانی که خودکارسازی از نظر اقتصادی مقرون‌به‌صرفه نیست، توجیه‌پذیر است. به گفته Bitrise (2025)، ۷۳٪ تیم‌های توسعه موبایل Smoke Test را خودکار می‌کنند.

تفاوت Smoke Test با تست رگرسیون

Smoke Test و تست رگرسیون اغلب اشتباه گرفته می‌شوند، اما اینها روش‌های متفاوتی با اهداف متفاوت هستند. تست رگرسیون بررسی می‌کند که تغییرات در کد عملکرد موجود را خراب نکرده است. این تست تمام ماژول‌ها و سناریوهای اپلیکیشن، از جمله موارد نادر و مرزی را پوشش می‌دهد. Smoke Test فقط مسیر بحرانی — سناریوهای اساسی که بدون آنها اپلیکیشن بی‌استفاده است — را بررسی می‌کند. عمق پوشش — تفاوت اصلی: Smoke Test ۵–۱۰٪ عملکرد را پوشش می‌دهد، رگرسیون ۸۰–۱۰۰٪.

تفاوت دوم — زمان اجرا. مجموعه رگرسیون برای اپلیکیشن موبایل بسته به اندازه پروژه و تعداد پلتفرم‌ها می‌تواند از ۲ تا ۱۲ ساعت طول بکشد. Smoke Test ۵–۱۵ دقیقه طول می‌کشد. به گفته Sauce Labs (2025)، میانگین زمان اجرای مجموعه رگرسیون برای اپلیکیشن iOS ۴.۵ ساعت و برای Android ۳.۲ ساعت است. Smoke Test در هر دو پلتفرم در ۱۰–۱۵ دقیقه انجام می‌شود.

تفاوت سوم — مکان در خط لوله. Smoke Test بلافاصله پس از بیلد، قبل از تست رگرسیون انجام می‌شود. اگر Smoke Test قبول نشود، رگرسیون اجرا نمی‌شود — این باعث صرفه‌جویی در منابع CI/CD می‌شود. Pipeline efficiency — Smoke Test تا ۳۰٪ از بیلدهایی را که از رگرسیون عبور نمی‌کردند جدا می‌کند و منابع صرفه‌جویی‌شده برای اجرای موازی سایر وظایف کافی است.

در Smoke Test اپلیکیشن موبایل چه مواردی گنجانده شده است

راه‌اندازی اپلیکیشن

راه‌اندازی اپلیکیشن — اولین و مهم‌ترین تست. اپلیکیشن باید بدون کرش روی همه دستگاه‌های هدف راه‌اندازی شود. Smoke Test شروع سرد را بررسی می‌کند: نصب → باز کردن → نمایش صفحه اول. اگر اپلیکیشن هنگام راه‌اندازی کرش کند، تست بیشتر بی‌معنی است. XCUITest و Espresso امکان خودکارسازی بررسی راه‌اندازی را در ۲–۳ خط کد فراهم می‌کنند. Launch argument `-AppleLanguages (fa)` به بررسی بومی‌سازی در شروع کمک می‌کند.

احراز هویت

احراز هویت — دومین سناریوی بحرانی. Smoke Test باید بررسی کند که فرم ورود نمایش داده می‌شود، فیلدهای ورودی به لمس واکنش می‌دهند، دکمه ورود درخواست ارسال می‌کند و اپلیکیشن پس از احراز هویت موفق به صفحه اصلی منتقل می‌شود. خطای احراز هویت دسترسی به تمام توابع دیگر را مسدود می‌کند، بنابراین بررسی آن در مجموعه حداقل گنجانده شده است. Token refresh — بررسی اضافی برای اپلیکیشن‌های دارای OAuth 2.0.

بارگذاری محتوا و ناوبری

بارگذاری محتوای اصلی — سومین تست Smoke Test. صفحه اصلی یا فید اپلیکیشن باید بارگذاری شود و داده‌ها را نمایش دهد. اگر API پاسخ ندهد یا تجزیه پاسخ خراب باشد، کاربر صفحه خالی می‌بیند. بررسی شبکه در Smoke Test شامل درخواست GET پایه به اندپوینت اصلی و بررسی اینکه پاسخ ساختار مورد انتظار را دارد می‌شود. ناوبری — چهارمین سناریو. Smoke Test از صفحه‌های اصلی اپلیکیشن عبور می‌کند: اصلی → جستجو → پروفایل → تنظیمات. نوار برگه و منوی کناری — منابع معمول مشکلات در ناوبری که Smoke Test در مراحل اولیه شناسایی می‌کند.

خودکارسازی Smoke Test در CI/CD

Fastlane — ابزار استاندارد برای خودکارسازی CI/CD موبایل. Smoke Test در Fastlane از طریق `scan` (برای XCUITest) یا `gradle` (برای Espresso) اجرا می‌شود. Fastlane امکان پیکربندی اجرای Smoke Test روی چندین دستگاه به صورت موازی را فراهم می‌کند که زمان کلی را کاهش می‌دهد. پیکربندی در Fastfile شامل هدف برای مجموعه Smoke Test و آستانه قبولی است: ۱۰۰٪ تست‌های موفق.

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 بیش از ۱۵ دقیقه طول بکشد، باید بهینه‌سازی شود: بررسی‌های اضافی حذف یا اجرا موازی شود.

# پیکربندی 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 — فریمورک پایه برای تست‌های واحد که 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 روی ۱۰ دستگاه پشتیبانی می‌کند.

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 ۵ ثانیه برای waitForExistence — مقدار استاندارد برای Smoke Test: اگر عنصر UI در این مدت نمایش داده نشود، اپلیکیشن نادرست کار می‌کند.