اختبارات الدخان والمعاملات الاصطناعية: التحقق من نجاح النشر الفعلي

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

لهذا السبب توجد اختبارات الدخان والمعاملات الاصطناعية. إنها ليست بديلاً عن مجموعة الاختبارات الحالية لديك. إنها طبقة منفصلة تجيب على سؤال مختلف: ليس "هل الكود صحيح؟" بل "هل نجح النشر بالفعل؟"

أبسط فحص: اختبارات الدخان

اختبار الدخان هو أبسط شيء يمكنك القيام به بعد النشر. يجيب على سؤال واحد: هل التطبيق حي ويستجيب؟

فكر في الأمر مثل تشغيل رف خادم جديد في مركز بيانات. قبل تشغيل أي حمل عمل جاد، تتحقق من أن ضوء الطاقة مضاء، والمراوح تدور، ويمكنك الاتصال بواجهة الإدارة. لا تقوم بتشغيل معيار كامل. أنت فقط تؤكد أن الشيء قيد التشغيل.

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

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

إليك ما يبدو عليه اختبار الدخان العملي والمعاملة الاصطناعية في bash:

# Smoke test: quick health check
curl -f -s -o /dev/null http://myapp.com/health || exit 1

echo "Smoke test passed"

# Synthetic transaction: simulate a user login and search
#!/bin/bash
set -e

BASE="http://myapp.com"

# Step 1: Load login page
curl -s -o /dev/null -w "%{http_code}" "$BASE/login" | grep -q 200 || exit 1

# Step 2: Submit login form (simulated)
curl -s -c /tmp/cookies.txt -b /tmp/cookies.txt \
  -d "username=testuser&password=testpass" \
  -o /dev/null -w "%{http_code}" "$BASE/login" | grep -q 302 || exit 1

# Step 3: Search for a product
curl -s -b /tmp/cookies.txt "$BASE/search?q=laptop" | grep -q "results" || exit 1

echo "Synthetic transaction passed"

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

التعمق أكثر: المعاملات الاصطناعية

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

تخيل تطبيق تجارة إلكترونية. قد تقوم المعاملة الاصطناعية بما يلي:

  1. فتح الصفحة الرئيسية
  2. البحث عن منتج
  3. إضافة المنتج إلى السلة
  4. المتابعة إلى الدفع
  5. إكمال عملية الشراء

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

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

سيناريو شائع: ينجح اختبار الدخان لأن نقطة فحص الصحة ترجع 200 OK. لكن صفحة تسجيل الدخول ترجع خطأ 500 لأنه لم يتم نسخ ملف تكوين بشكل صحيح أثناء النشر. لم يتحقق اختبار الدخان من صفحة تسجيل الدخول أبدًا. ستكتشفها المعاملة الاصطناعية على الفور.

أين تتناسب في خط الأنابيب الخاص بك

تخدم اختبارات الدخان والمعاملات الاصطناعية أغراضًا مختلفة ويجب أن تظهر في مراحل مختلفة من خط أنابيب النشر الخاص بك.

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

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

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

ما تكتشفه هذه الاختبارات مما يفوته الآخرون

تعمل اختبارات ما قبل النشر في بيئات خاضعة للرقابة. تستخدم قواعد بيانات اختبارية، وخدمات وهمية، وملفات تكوين قد تختلف عن الإنتاج. حتى مع بيئات الاختبار التي تعكس الإنتاج عن كثب، توجد اختلافات.

تعمل اختبارات الدخان والمعاملات الاصطناعية في بيئة الإنتاج الفعلية. تكتشف المشكلات التي تظهر هناك فقط:

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

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

قائمة مرجعية عملية

عند تنفيذ اختبارات الدخان والمعاملات الاصطناعية لخط الأنابيب الخاص بك، ضع هذه النقاط في الاعتبار:

  • حافظ على اختبارات الدخان أقل من 10 ثوانٍ. إذا استغرقت وقتًا أطول، قم بتبسيطها.
  • ضع اختبارات الدخان مباشرة بعد النشر، قبل توجيه حركة المرور.
  • افشل خط الأنابيب عند فشل اختبار الدخان. لا تستمر.
  • قم بتشغيل المعاملات الاصطناعية بعد اجتياز اختبارات الدخان، قبل التحويل الكامل لحركة المرور.
  • حدد المعاملات الاصطناعية بـ 2-5 رحلات مستخدم حرجة.
  • لا تستخدم المعاملات الاصطناعية للاختبار الشامل. هذا ما توجد من أجله اختبارات ما قبل النشر.
  • راقب نتائج المعاملات الاصطناعية بمرور الوقت. قد يشير نمط من حالات الفشل المتقطعة إلى مشكلة أساسية.
  • تأكد من أن المعاملات الاصطناعية تعمل ضد بيئة الإنتاج الفعلية، وليس نسخة مكررة من بيئة الاختبار.

الخلاصة الملموسة

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