اختبار الدخان والسلامة والانحدار: مقارنة

الدخان والسلامة والانحدار في لمحة

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

اختبار الدخان: هل البناء قابل للاختبار؟

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

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

Smoke suite: web shop, build under test on staging (example)

[ ] GET /health returns 200 for web, orders, pricing, payments services
[ ] Home page loads; no console errors; main navigation renders
[ ] Log in with the smoke test account (smoke.user@example.com)
[ ] Search returns results for a known product
[ ] Add a known product to the cart; cart total is shown
[ ] POST /api/v1/orders with a fixed payload returns 201
[ ] Payment sandbox call returns an authorised result
[ ] Invoice endpoint returns 200 with Content-Type application/pdf

Rule: any failure -> build rejected, deeper testing does not start.
Budget: under 5 minutes, fully automated, runs on every deployment.

جرّبها: فاحص صحة API

اختبار السلامة: مصطلح يُستخدم بأكثر من معنى

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

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

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

اختبار الانحدار: هل كسر التغيير شيئاً آخر؟

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

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

• اختبار التأكيد (إعادة الاختبار) — خطوات العيب الأصلي تنجح الآن.
• اختبار الانحدار — الاختبارات حول التغيير وما بعده ما زالت تنجح.
• حزمة الانحدار تنمو مع المنتج؛ وبلا صيانة تصبح بطيئة ومكررة ومتذبذبة.

اختيار اختبارات الانحدار: ماذا تشغّل

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

• إعادة اختبار الكل — شغّل الحزمة كاملة. أعلى ثقة وأعلى كلفة؛ الخيار المعتاد للتشغيلات الليلية والمرشحين للإصدار.
• الاختيار حسب الأثر — ابدأ مما تغيّر (الملفات والوحدات وواجهات API وجداول قاعدة البيانات والإعدادات) وضمّن الاختبارات التي تمارس هذه الأجزاء واعتمادياتها المباشرة. وأدوات تحليل أثر الاختبار (Test impact analysis) تؤتمت ذلك بربط الاختبارات بالكود، عادةً من بيانات التغطية.
• الاختيار حسب المخاطر — أضف اختبارات للمناطق ذات الأثر التجاري العالي أو ذات تاريخ من العيوب حتى لو بدا التغيير غير متصل بها: الدفع، والمصادقة، وتصدير البيانات.
• تحديد الأولويات — رتّب الاختبارات المختارة بحيث يعمل الأثمن أولاً: الاختبارات التي فشلت مؤخراً، واختبارات الكود المتغير، والرحلات الحرجة. فيصل الإخفاق مبكراً.
• نواة دائمة — فحوص الدخان وعدد قليل من الرحلات الشاملة الحرجة تعمل عند كل تغيير بغض النظر عن الاختيار.
• شبكة أمان — ما يتخطاه الاختيار لكل تغيير يغطيه التشغيل الكامل المجدول، فيُكتشف خطأ الاختيار خلال يوم لا عند الإصدار.

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

أين يعمل كل منها في خط أنابيب CI/CD

في خط الأنابيب، الثلاثة ليست مراحل منفصلة يؤديها أشخاص مختلفون؛ بل حزم مرتبطة بمحفّزات مختلفة. التوزيع التالي شائع ويصلح لمعظم منتجات الويب.

• طلب الدمج — فحوص مرحلة الإيداع مع مجموعة انحدار مختارة (حسب الأثر والمخاطر) على مستوى الوحدة وAPI؛ والرحلات الشاملة الحرجة.
• الدمج في الفرع الرئيسي — حزم انحدار الوحدة وAPI كاملة؛ وحزمة الاختبار الشامل في أجزاء متوازية.
• كل نشر إلى بيئة اختبار — حزمة الدخان أولاً؛ ولا يبدأ شيء آخر حتى تنجح.
• بعد نشر إصلاح — اختبار السلامة (التحقق من الإصلاح) من قِبل المختبِر الذي أبلغ عن العيب، بما في ذلك اختبار التأكيد.
• ليلياً — حزمة الانحدار الكاملة عبر جميع المستويات، مع تشغيلات غير وظيفية أطول.
• المرشح للإصدار — انحدار كامل أخضر، ثم دخان على الإنتاج فور الإصدار.

جرّبها: مولّد حالات اختبار من OpenAPI

مثال محلول: إصلاح تقريب ضريبة القيمة المضافة

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

• الدخان (مؤتمت، نحو 3 دقائق): هل يمكن اختبار هذا البناء أصلاً؟ نقطة النهاية ⁦/health⁩ تعيد 200 لخدمات الويب والتسعير والفواتير؛ وتسجيل الدخول بعميل الاختبار وإضافة صنف والوصول إلى صفحة الدفع؛ وإنشاء طلب عبر API يعيد 201؛ ونقطة نهاية ملف PDF للفاتورة تعيد 200 بنوع application/pdf.
• السلامة (مركّزة، نحو 20 دقيقة): هل الإصلاح نفسه صحيح؟ 100.00 ريال بخصم 10% تعطي مجموعاً فرعياً 90.00 وضريبة 15% قدرها 13.50 وإجمالياً 103.50؛ و3 × 33.33 ريال بخصم 5% تتبع إجمالياتها قاعدة التقريب في المواصفة؛ وملف PDF للفاتورة يعرض الضريبة نفسها التي تعيدها API الطلب؛ وخطوات تقرير الخطأ الأصلي لم تعد تُظهر الخطأ (اختبار التأكيد).
• الانحدار (مختار): هل انكسر شيء آخر؟ إلزامي: حزم وحدة التسعير وAPI التسعير كاملة، وحزمة API الفواتير، ورحلات الدفع الشاملة. مستحسن: المبالغ المستردة وإشعارات الدائن ورموز العروض الترويجية ومجاميع سجل الطلبات، لأنها كلها تستخدم الضريبة. يُتخطى: الملف الشخصي والإشعارات والبحث، إذ لا تعتمد على التسعير. لاحقاً: حزمة الانحدار الكاملة في التشغيل الليلي كما في كل ليلة.

Change: fix VAT rounding on invoices that have a discount (pricing service, invoice PDF)
Build: 5.8.1 on staging

1. SMOKE (automated, about 3 min): can this build be tested at all?
   [x] /health 200 for web, pricing and invoice services
   [x] log in with the test customer, add an item, reach checkout
   [x] create order via API -> 201
   [x] invoice PDF endpoint -> 200, application/pdf

2. SANITY (focused, about 20 min): is the fix itself right?
   [x] 100.00 SAR, 10% discount -> subtotal 90.00, VAT 15% 13.50, total 103.50
   [x] 3 x 33.33 SAR, 5% discount -> totals follow the rounding rule in the spec
   [x] invoice PDF shows the same VAT as the order API response
   [x] steps of the original bug report no longer reproduce (confirmation test)

3. REGRESSION (selected): did anything else break?
   must    pricing unit + API suites (all), invoice API suite, checkout E2E journeys
   should  refunds and credit notes, promo codes, order-history totals (all use VAT)
   skip    profile, notifications, search (no dependency on pricing)
   later   full regression suite in the nightly run, as every night

أخطاء شائعة

• معاملة تشغيل دخان أخضر كموافقة على الإصدار. الدخان يقول إن البناء قابل للاختبار، لا إنه صحيح.
• ترك حزمة الدخان تنمو حتى تستغرق نصف ساعة؛ فتتوقف عن العمل عند كل نشر.
• الإبلاغ بأن «اختبار السلامة نجح» دون ذكر ما فُحص.
• إغلاق العيب بعد اختبار التأكيد وحده، دون أي انحدار حول الإصلاح.
• اختيار اختبارات الانحدار من الذاكرة بدلاً من التغيير وقائمة مخاطر مكتوبة.
• عدم تشذيب حزمة الانحدار أبداً: الاختبارات المكررة، واختبارات الميزات المحذوفة، والاختبارات المتخطاة بشكل دائم تكلّف وقتاً في كل تشغيل.
• تخطي التشغيل الكامل المجدول لأن الاختيار لكل تغيير «كان جيداً حتى الآن».

جرّبها: كاشف حالات الاختبار المكرّرة بالذكاء الاصطناعي

الأسئلة الشائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018شرح واسع الاستشهاد لكيفية الموازنة بين اختبارات الوحدة والتكامل والعقود والواجهة في محفظة الاختبارات الآلية.
• Continuous Integration (Martin Fowler)martinfowler.com · 2024الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.