اختبار الانحدار في تطوير التطبيقات المحمولة — ما هو، أنواعه وكيف يتم

ما هو اختبار الانحدار؟

اختبار الانحدار هو نوع من الاختبارات يهدف إلى تأكيد أن تغييرات الكود لم تكسر الوظائف الحالية. المصطلح «انحدار» يعني العودة إلى حالة أسوأ — عندما تتوقف وظيفة كانت تعمل في الإصدار السابق عن العمل في الإصدار الجديد. يتم تنفيذ اختبارات الانحدار بشكل متكرر في كل دورة تطوير، مما يميزها عن اختبارات الميزات الجديدة التي تُكتب مرة واحدة.

تنبع الحاجة إلى اختبار الانحدار من تأثير التغييرات المتتالية: إصلاح خطأ في وحدة واحدة قد يحل المشكلة لكنه يكسر الوظائف المجاورة التي تعتمد عليها. على سبيل المثال، تغيير استعلام SQL في مستودع المستخدمين قد يسرع المصادقة لكنه يكسر تصدير البيانات الذي استخدم نفس الاستعلام. سيكتشف اختبار الانحدار على تصدير البيانات هذا الخلل قبل الإصدار.

وفقًا لتقرير CISQ 2023، فإن تكلفة إصلاح عيب انحدار تم اكتشافه في الإنتاج أعلى بـ 15 مرة من مرحلة تشغيل الانحدار الآلي. الشركات التي تستثمر في اختبار الانحدار الآلي تقلل حصة عيوب الانحدار في الإصدارات من 25% إلى 5% خلال عام من التنفيذ، وفقًا لتقرير Capgemini World Quality Report.

أنواع اختبار الانحدار

هناك عدة طرق لاختبار الانحدار تختلف في النطاق ومعايير اختيار الاختبارات. اختيار الطريقة يعتمد على حجم المشروع، وتواتر التغييرات، والوقت المتاح في خط أنابيب CI. فيما يلي الأنواع الرئيسية لاختبار الانحدار مع خصائصها.

اختبار الانحدار الكامل

تشغيل الانحدار الكامل ينفذ جميع الاختبارات الآلية للمشروع دون استثناء. يوفر هذا النهج أقصى درجات الثقة لكنه يتطلب موارد حاسوبية ووقتًا كبيرين. يتم إجراء التشغيل الكامل قبل الإصدارات الرئيسية — كل 2–4 أسابيع. لتطبيق يحتوي على 5000 اختبار، يستغرق التشغيل الكامل من 2 إلى 6 ساعات حسب البنية التحتية.

اختبار الانحدار الانتقائي

النهج الانتقائي يشغل فقط الاختبارات المرتبطة بالوحدات المعدلة. لتحديد الارتباط، يتم استخدام تحليل التبعيات على مستوى الكود: إذا تم تغيير فئة UserRepository، يتم تشغيل الاختبارات التي تعتمد على UserRepository بشكل مباشر أو غير مباشر. توفر أدوات مثل Jacoco وAndroid Test Coverage وXcode Code Coverage خرائط تغطية للاختيار الدقيق. يتم إجراء التشغيل الانتقائي عند كل طلب سحب ويستغرق 5–15 دقيقة.

الانحدار القائم على المخاطر

الانحدار القائم على المخاطر يصنف الاختبارات حسب أهمية الوظيفة واحتمالية الكسر. الوظائف الحرجة — المدفوعات، المصادقة، المزامنة — تُختبر عند كل تغيير في الكود. الوظائف المساعدة — شاشة «حول»، الرسوم المتحركة — تُختبر فقط قبل الإصدار. تتم مراجعة التصنيف كل ثلاثة أشهر بناءً على بيانات حوادث الإنتاج.

الفرق بين اختبار الانحدار وإعادة الاختبار

غالبًا ما يتم الخلط بين مفهومي اختبار الانحدار وإعادة الاختبار، على الرغم من أنهما عمليتان مختلفتان. إعادة الاختبار هي إعادة تشغيل اختبار محدد كان قد فشل سابقًا، بعد إصلاح العيب. الغرض من إعادة الاختبار هو التأكد من أن الإصلاح يعمل: لم يعد الخطأ يظهر. يتم إجراء إعادة الاختبار مرة واحدة، مباشرة بعد الإصلاح وتأكيد المطور للإصلاح.

اختبار الانحدار هو تشغيل اختبارات على الوظائف الحالية التي لم يتم تغييرها. الهدف هو التأكد من أن إصلاح عيب واحد لم يخلق عيبًا جديدًا في مكان آخر. يتم تشغيل اختبارات الانحدار بشكل متكرر في كل دورة تطوير، بغض النظر عن الأخطاء المحددة التي تم إصلاحها. الفرق الرئيسي: إعادة الاختبار تتحقق من الإصلاح نفسه، الانحدار يتحقق من عواقب الإصلاح.

في خط أنابيب CI/CD، يتم تنفيذ كلتا العمليتين بالتسلسل. بعد دمج طلب السحب، يتم إجراء إعادة اختبار للخطأ المحدد، يليه تشغيل انحدار كامل أو انتقائي. وفقًا لـ SmartBear (2022)، فإن فصل هذه العمليات يقلل وقت تشخيص عمليات CI الفاشلة بنسبة 30%، حيث يرى الفريق على الفور أي العيوب مرتبطة بالانحدار وأيها بالإصلاحات غير العاملة.

أتمتة اختبار الانحدار

تعد أتمتة اختبار الانحدار عاملاً حاسمًا للنجاح في المشاريع المحمولة الحديثة. اختبار الانحدار اليدوي لا يتوسع: مع مجموعة من 200 اختبار، تتطلب عملية تشغيل واحدة 2–3 أيام عمل من مهندس QA، مما يجعل عمليات التشغيل اليومية مستحيلة. يتم تنفيذ اختبارات الانحدار الآلية في 10–60 دقيقة دون تدخل بشري، مما يسمح بتشغيلها عند كل commit أو طلب سحب.

• اختبارات الوحدة — أساس مجموعة الانحدار (70%). يتم تنفيذها في ثوانٍ، لا تتطلب محاكيًا، وتعطي تحديدًا دقيقًا للفئة المكسورة.
• اختبارات التكامل — المستوى الثاني (20%). تتحقق من طبقة الشبكة وقاعدة البيانات والخدمات النظامية مع تبعيات خاضعة للرقابة.
• اختبارات UI و E2E — قمة الهرم (10%). تغطي سيناريوهات المستخدم الحرجة: التسجيل، الدفع، المزامنة.

للحفاظ على مجموعة الانحدار محدثة، يتم استخدام تحليلات الاختبارات: أدوات مثل Allure وReportPortal وXray تتتبع نسب النجاح والمدة والاستقرار لكل اختبار. الاختبارات التي ينخفض استقرارها عن 90% (غالبًا ما تنكسر بسبب تغييرات في المتطلبات) يتم وضع علامة عليها كقديمة وتعيينها للمالك للمراجعة.

مثال على إعداد اختبار الانحدار

دعنا نلقي نظرة على إعداد اختبار انحدار آلي على Android باستخدام مكتبة JUnit 5 وEspresso. يوضح المثال الانحدار الانتقائي — يتحقق الاختبار من أنه بعد إعادة هيكلة مستودع المستخدمين، لا تتعطل شاشة الملف الشخصي. بالنسبة لنظام iOS، يتم استخدام XCTest بمنطق مماثل — اختبار متكرر على سيناريو رئيسي.

Android: اختبار انحدار الملف الشخصي

يستخدم الاختبار MockWebServer لمحاكاة الخادم ويتحقق من المسار الكامل: تحميل بيانات المستخدم، عرضها على شاشة الملف الشخصي، ومعالجة الخطأ عند عدم توفر الخادم. يتم تضمين هذه الاختبارات في مجموعة الانحدار وتنفيذها عند كل تغيير في وحدة الملف الشخصي.

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("خطأ في التحميل").assertIsDisplayed()
    }
}

iOS: اختبار انحدار مع XCTest

بالنسبة لنظام iOS، يستخدم اختبار الانحدار XCTestExpectation للتحقق غير المتزامن من تحديث واجهة المستخدم بعد تلقي البيانات من API. يحاكي الاختبار استجابة الشبكة ويتحقق من تحديث عناصر واجهة المستخدم بشكل صحيح.

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

استراتيجية بناء مجموعة اختبارات الانحدار

بناء مجموعة انحدار فعالة هو عملية تكرارية تعتمد على بيانات العيوب وتغييرات الكود. الاستراتيجية الأولية هي تضمين جميع الاختبارات الحالية في مجموعة الانحدار وتشغيل تمريرة كاملة قبل كل إصدار. مع نمو قاعدة الاختبارات (أكثر من 2000 اختبار)، يصبح التشغيل الكامل طويلاً جدًا ويصبح النهج الانتقائي مطلوبًا.

المرحلة الثانية — تنفيذ أدوات تحليل التبعيات: Jacoco لنظام Android، Xcode Test Plan لنظام iOS. تبني هذه الأدوات خريطة «اختبار — فئة — طريقة» وتسمح بتحديد الاختبارات المتأثرة بتغيير معين. التشغيل الانتقائي القائم على تحليل التغطية يقلل وقت التنفيذ بنسبة 60–80% مع الحفاظ على فعالية اكتشاف الانحدار بنسبة 95%، وفقًا لـ Spotify Engineering (2022).

المرحلة الثالثة — المراقبة المستمرة والتحسين. الاختبارات التي لم تفشل لمدة 6 أشهر تُنقل إلى مجموعة ذات أولوية منخفضة. الاختبارات التي تفشل أكثر من مرة في الشهر هي مرشحة للمراجعة: إما أنها تكتشف مشاكل حقيقية (تحتاج إلى إصلاح) أو أنها هشة جدًا (تتطلب استقرارًا). المراجعة ربع السنوية لمجموعة الانحدار هي ممارسة قياسية للحفاظ على فعاليتها وسرعة تنفيذها.