مختبر يعيد بناء الاختبارات المتذبذبة: مشاريع تخرج هندسة البرمجيات

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

عرّف ما الذي يتذبذب

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

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

صمم مشغلاً قابلاً للضبط

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

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

مثال اختبار توقيت متسابق

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

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

قارن بخط أساس واضح

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

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

اختبارات قبول للمختبر

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

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

مخرجات الفريق

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

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