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. كفاءة خط الأنابيب — Smoke Test يصفي حتى 30% من البناءات التي كانت ستفشل في الارتداد، والموارد الموفرة تكفي لتشغيل مهام أخرى بالتوازي.

ما الذي يشمل Smoke Test لتطبيق الجوال

تشغيل التطبيق

تشغيل التطبيق — أول وأهم اختبار. يجب أن يبدأ التطبيق دون تعطل على جميع الأجهزة المستهدفة. Smoke Test يفحص البدء البارد: تثبيت → فتح → عرض أول شاشة. إذا تعذر التطبيق عند البدء، فالاختبارات الإضافية غير مجدية. XCUITest و Espresso يسمحان بأتمتة فحص البدء في 2–3 أسطر من الكود. معلومة البدء `-AppleLanguages (ru)` تساعد في التحقق من التوطين عند البدء.

تسجيل الدخول

تسجيل الدخول — السيناريو الحرج الثاني. يجب أن يتحقق 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 وحد النجاح: 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 لاختبارات واجهة المستخدم لتطبيقات iOS. يتم استخدام XCUITest لأتمتة Smoke Tests: تشغيل التطبيق، فحص عناصر واجهة المستخدم، محاكاة إجراءات المستخدم. بالاقتران مع Xcode Server أو GitHub Actions، يتم تشغيل XCUITest عند كل ارتكاب. XCTest — الإطار الأساسي لاختبارات الوحدات الذي يكمل XCUITest لفحص المنطق.

Espresso — إطار عمل Google لاختبارات واجهة المستخدم لنظام Android. يتزامن Espresso مع سلسلة واجهة المستخدم ويضمن اكتمال جميع الرسوم المتحركة قبل بدء الفحص. يدعم Espresso الفحص من خلال `onView(withId(...)).check(matches(...))`. Android Test Orchestrator يشغل كل Smoke Test في عملية منفصلة، مما يمنع تأثير الاختبارات السابقة على اللاحقة.

Detox — إطار عمل لـ React Native يدعم Smoke Test واختبارات الصندوق الرمادي. يتزامن Detox مع جسر React Native وينتظر تلقائيًا اكتمال العمليات غير المتزامنة. اختبارات الصندوق الرمادي تسمح لـ Detox بفحص حالة التطبيق دون الوصول المباشر إلى الكود المصدري.

مثال Smoke Test باستخدام Swift و Kotlin

XCUITest لـ iOS يحتوي على فحصين: تشغيل التطبيق وعرض الشاشة الرئيسية. يشتغل الاختبار التطبيق من خلال `XCUIApplication().launch()` ويتحقق من وجود عنصر رئيسي (مثل `navigationBar`). إذا تعذر التطبيق عند التشغيل، يسجل إطار XCTest الخطأ وينتهي الاختبار بنتيجة FAIL. Smoke Test لا يفحص المحتوى — فقط أن الشاشة افتتحت.

Espresso لـ Android يستخدم `ActivityScenario` لتشغيل Activity و `onView` لفحص العناصر. فرق حاسم بين المنصات: محاكي iOS قد يظهر سلوكًا مختلفًا عن الجهاز الحقيقي، لذلك يوصى بتنفيذ Smoke Tests لـ Android على Firebase Test Lab أو محاكٍ. Firebase Test Lab يدعم التنفيذ المتوازي لـ Smoke Tests على 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. الاختبار الأول يتحقق من وجود زر تسجيل الدخول على الشاشة. الاختبار الثاني يقوم بتسجيل الدخول كاملاً ويتحقق من ظهور رسالة الترحيب بعد تسجيل دخول ناجح. المهلة قدرها 5 ثوانٍ لـ `waitForExistence` هي القيمة القياسية لـ Smoke Test: إذا لم يظهر عنصر واجهة المستخدم خلال هذه المهلة، فالتطبيق لا يعمل بشكل صحيح.