عيوب الانحدار

لماذا يهم

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

وللمختبِر في الانحدار ميزة تفتقدها معظم العيوب: إصدار سليم معروف يُقارَن به. فالتقرير الذي يذكر آخر إصدار كان يعمل وأول إصدار أخفق يتيح للمطور البحث في تغييرات قليلة بدلاً من الشيفرة كلها، وكل انحدار يكشف ثغرة في حزمة الانحدار يستطيع الفريق سدّها.

ما الذي يجعل العيب انحداراً

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

• المُدخَل (Introduced): التغيير نفسه يحمل الخطأ، كدالة مشتركة عُدّلت من أجل جهة تستدعيها فتعطّلت جهة أخرى.
• المكشوف (Uncovered): التغيير يُظهر عيباً أقدم كان مخفياً، كإصلاح يسمح للمدخلات بالوصول إلى فحص لم يكن يُنفَّذ من قبل.
• المُعاد (Reintroduced): عيب أُصلح سابقاً يعود، غالباً بسبب دمج ضاع فيه الإصلاح. وتسمّيه بعض الفرق العيب المتكرر (Recurring Defect).
• ليس انحداراً: سلوك لم يعمل قط، في ميزة جديدة أو كعيب قديم اكتُشف متأخراً. فهو يُخفق على الإصدار السابق أيضاً.

لماذا يحدث الانحدار

يُراجَع التغيير عادةً من أجل غرضه هو، لا من أجل كل مكان يعتمد عليه. ويشير منهج ISTQB للمستوى التأسيسي إلى أن آثاره السلبية قد تظهر في المكوّن الذي تغيّر، أو في مكوّنات أخرى من النظام نفسه، أو في أنظمة متصلة، وإلى أن اختبار الانحدار لا يقتصر على موضوع الاختبار (Test Object)، بل قد يشمل البيئة أيضاً. ويصل الانحدار إلى المستخدمين حين لا يفحص أي اختبار السلوك الذي تعطّل، أو لا يُشغَّل الاختبار، أو يفشل ولا يتصرف أحد. ومن الأسباب المعتادة:

• الشيفرة المشتركة: دالة أو مكوّن أو قاعدة تنسيق أو واجهة برمجية تُستخدم في أماكن عدة، تُغيَّر مع مراعاة واحد منها فقط.
• الإصلاحات وإعادة الهيكلة (Refactoring): صحيحة للحالة المُبلَّغ عنها، أو يُفترض ألا تغيّر شيئاً، لكنها تغيّر السلوك في حالة حدّية.
• ترقية المكتبات وأطر العمل والمتصفحات وقاعدة البيانات، وتغييرات التهيئة ومفاتيح الميزات (Feature Flags).
• البيانات: ترحيل للبيانات، أو قاعدة جديدة تصادف سجلات حُفظت وفق القاعدة القديمة.
• الدمج والأنظمة المتصلة: تعارض حُلّ بطريقة خاطئة، أو خدمة تغيّر عقدها.

كشف الانحدار: الحزم والمقارنة بالإصدار السليم والتنصيف

وُجدت حزمة الانحدار (Regression Suite) لكشف الانحدار: اختبارات لسلوك كان يعمل، يُعاد تشغيلها بعد التغييرات. ولأنها تُشغَّل مرة بعد مرة وتكبر مع كل إصدار، يعدّ منهج ISTQB اختبار الانحدار مرشحاً قوياً للأتمتة. والاختبار الذي نجح على البناء السابق ويفشل على هذا البناء هو أوضح إشارة إلى انحدار. استبعد أولاً الاختبار المتذبذب (Flaky)، ومشكلات البيئة أو البيانات، والاختبار الذي تقادم لأن السلوك تغيّر عن قصد، كما في درس الاختبارات الفاشلة والمحجوبة. ثم شغّل الاختبار على آخر إصدار يُفترض أنه سليم (خط الأساس، Baseline)، في البيئة نفسها. وكثيراً ما تكشف مقارنة مخرجات الإصدارين، كاستجابتين من واجهة برمجية، ما الذي تغيّر بالضبط.

يضيّق التنصيف (Bisecting) النطاق بين آخر إصدار سليم وأول إصدار معيب إلى تغيير واحد. إنه بحث ثنائي: اختبر الإصدار الواقع في المنتصف، واحتفظ بالنصف الذي تنتقل فيه النتيجة من ناجح إلى فشل، وكرّر. يحتاج ⁦16⁩ بناءً مرشحاً إلى ⁦4⁩ اختبارات على الأكثر، ويحتاج نحو ⁦1000⁩ إيداع (Commit، أي تغيير محفوظ في Git) إلى ⁦10⁩. ويتولى الأمر git bisect هذا التتبّع على الإيداعات، ومن دون الشيفرة المصدرية يمكنك تنصيف أرقام البناء أو الإصدارات في بيئة الاختبار بالطريقة نفسها.

• استخدم فحصاً موثوقاً: الاختبار المتذبذب يرسل البحث إلى النصف الخطأ.
• غيّر الإصدار وحده، وأبقِ البيئة والتهيئة والبيانات كما هي.
• تخطَّ الخطوة التي يتعذّر اختبارها (git bisect skip) بدلاً من التخمين.
• النتيجة هي أول تغيير يظهر عنده الإخفاق. وقد يكون هذا التغيير كشف عيباً أقدم، فهي دليل للمطور لا اتهام.

git bisect start
git bisect bad                # the version you are on fails
git bisect good v2.7.0        # the last version known to pass
# Git checks out a commit halfway: build it, run the test, then mark it
git bisect good               # or: git bisect bad
# repeat until Git prints "<commit> is the first bad commit"
git bisect reset              # return to where you started

جرّبها: مقارنة استجابات API جرّبها: مقارنة JSON جرّبها: مقارنة النصوص (Diff)

مثال تطبيقي: تنصيف انحدار في صفحة الدفع

ينجح تشغيل الانحدار الليلي على البناء ⁦140⁩ يوم الاثنين، ويفشل على البناء ⁦156⁩ يوم الثلاثاء: فالاختبار TC-311، أي الشراء بعنوان محفوظ بلا رمز بريدي، يتوقف الآن عند الدفع برسالة «العنوان غير مكتمل». وعند إعادة تشغيل TC-311 على البناء ⁦156⁩ يفشل بالطريقة نفسها، وعلى البناء ⁦140⁩، في البيئة نفسها وبالعميل نفسه، ينجح. إذن هذا انحدار، دخل في أحد البناءات من ⁦141⁩ إلى ⁦156⁩، ويتضمن كل منها تغييراً واحداً مدموجاً.

تكفي أربعة اختبارات للعثور عليه. لا يتضمن البناء ⁦147⁩ إلا PR-882، الذي أضاف إلى الدالة المشتركة validateAddress() فحصاً يجعل الرمز البريدي إلزامياً من أجل شركة الشحن الجديدة: صحيح للعناوين الجديدة، وخاطئ لكل عنوان حُفظ قبله. وقد نجحت فحوص طلب الدمج (Pull Request) لأن بيانات اختبارها لم تحوِ إلا عناوين جديدة.

• عنوان التقرير: «صفحة الدفع ترفض العناوين المحفوظة بلا رمز بريدي (انحدار منذ البناء ⁦147⁩)».
• الدليل: آخر بناء سليم ⁦146⁩، وأول بناء معيب ⁦147⁩، والتغيير المشتبه به PR-882، وكشفه TC-311 في التشغيل الليلي.
• يطبّق الإصلاح الفحص على شركة الشحن الجديدة فقط، ويُضاف TC-311 إلى فحوص طلبات الدمج.

Known good: build 140   Monday nightly run, TC-311 passed
Known bad:  build 156   Tuesday nightly run, TC-311 failed
Candidates: builds 141..156, one merged change each (16 builds)

Test  Build  TC-311  First bad build is in
1     148    fail    141..148
2     144    pass    145..148
3     146    pass    147..148
4     147    fail    147  -> first bad build

Build 147 contains one change: PR-882 "Require postcode for new courier"

منع الانحدار

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

• أجرِ تحليلاً سريعاً للأثر (Impact Analysis) قبل الدمج: من يستخدم هذه الشيفرة أيضاً؟ وأي بيانات مخزنة تصادف القاعدة الجديدة؟
• شغّل اختبارات الانحدار المتصلة بالتغيير، مختارةً حسب الأثر والمخاطر، على كل طلب دمج، والحزمة الكاملة على الفرع الرئيسي، بوصفها بوابة جودة قادرة على إيقاف التغيير.
• احتفظ ببيانات اختبار تشبه تاريخ الإنتاج: سجلات قديمة، وحقول اختيارية فارغة، وبيانات حُفظت وفق قواعد سابقة.
• لكل انحدار يُصلَح، أضف الاختبار الذي كان سيكشفه، في أدنى مستوى يمكنه التعبير عنه.
• أصلح الاختبارات المتذبذبة أو اعزلها، لكي يعني التشغيل الأحمر شيئاً دائماً.
• فضّل التغييرات الصغيرة، ورقِّ المكتبات في تغيير مستقل مع تشغيل للانحدار؛ فالتغييرات الصغيرة أسهل في المراجعة وفي التنصيف.

جرّبها: مولّد سيناريوهات الانحدار جرّبها: مولّد الاختبار المبني على المخاطر

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Reference — GitGit projectالمرجع الرسمي لكل أوامر Git وخياراتها، مجمّعةً حسب المهمة — الإعداد والتفريع والمشاركة وتطبيق الرقع والفحص وتتبّع الأخطاء.
• Continuous Integration (Martin Fowler)martinfowler.com · 2024الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.