الرئيسية / دراسة حالة: نقل الاختبارات

دراسة حالة · NANO TECH

نقل 1,300 اختبار يدوي إلى اختبارات قبول مؤتمتة

انتقال جارٍ من اختبارات القبول اليدوية إلى اختبارات مؤتمتة، في تطبيق إدارة البيانات المرجعية لمجموعة في قطاع الصناعات الغذائية والزراعية. ويبقى اسم العميل سريًا.

1 · السياقعرض السياق

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

2 · المشكلةالمشكلة الأولية

  • كانت اختبارات القبول تعتمد على فحوصات يدوية يجب إعادتها بالكامل مع كل تسليم.
  • مع 30 كيانًا مترابطًا، يمكن لقيمة واحدة غير متسقة أن تؤثر في عدة شاشات.
  • فرق الأعمال التي تعتمد اختبارات القبول لا تقرأ شيفرة الاختبارات.

3 · النطاقنطاق المهمة

1,300اختبار يدوي تم نقله
~30كيانًا من بيانات الأعمال
  • نقل 1,300 اختبار يدوي لصحة البيانات واتساقها إلى Playwright.
  • مسارات مستخدمين مؤتمتة من البداية إلى النهاية.
  • خطط اختبارات قبول لكل كيان.
  • تشخيص الاختبارات غير المستقرة ومتابعة عمليات التشغيل.

4 · التقنياتالتقنيات

  • Playwright وTypeScript لجميع الاختبارات.
  • Azure DevOps في بيئة المشروع.
  • تقارير تنفيذ Playwright، تعالجها أداة متابعة طُوّرت خصيصًا للمهمة.

5 · المنهجيةالمنهجية المتبعة

  • نقل اختبارات القبول اليدوية القائمة إلى اختبارات مؤتمتة، كيانًا تلو الآخر.
  • اختبارات مبنية على أساس مشترك، بحيث يُضاف كيان جديد دون البدء من الصفر.
  • سيناريوهات من البداية إلى النهاية تمر عبر الواجهة، ثم تعيد البيانات إلى حالتها الأصلية.
  • خطة اختبارات قبول لكل كيان، مكتوبة انطلاقًا من حالات الاختبار: الهدف، والخطوات، والنتيجة المتوقعة.

6 · الصعوباتالمشكلات التقنية

نقرة تعترضها أداة واجهة

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

بحث يعيد الصف الخطأ

كان البحث العام يعمل بالكلمات المفتاحية: البحث عن «Mantem 2» يعيد أيضًا «Mantem 1»، فيتحقق الاختبار من سجل غير المقصود.

تقارير منفصلة

كان كل تشغيل يُنتج تقرير JSON مستقلًا، دون رؤية شاملة لتطور المدة والإخفاقات.

إخفاقات يصعب تفسيرها

كان لا بد من التمييز بين الأعطال الحقيقية في التطبيق والاختبارات الهشة قبل تصحيح أي شيء.

7 · الحلولالحلول المطبقة

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

8 · النتائجالنتائج الملموسة

  • اختبارات قبول مؤتمتة تضم 1,300 اختبار Playwright/TypeScript، جاهزة للتشغيل مع كل نشر.
  • اختبارات مستقرة: أُعيد استخدام حل النقرة الموجهة في الشاشات الأخرى.
  • لا مزيد من النتائج السلبية الخاطئة الناتجة عن البحث، مع إعادة بيانات الاختبار كما كانت تمامًا.
  • انحرافات مدة التشغيل ظاهرة في لوحة المتابعة.
  • خطة اختبارات قبول لكل كيان يستطيع فريق الأعمال اتباعها.

9 · الدروسما أستخلصه

  • الاختيار بمعرّف فريد بدلًا من التسمية: غموض أقل وبيانات قابلة للاستعادة.
  • انتظار حالة صريحة للواجهة بدلًا من مهلة ثابتة.
  • الفصل بين الأعطال الحقيقية والاختبارات الهشة قبل التصحيح.
  • كتابة اختبارات القبول بلغة فريق الأعمال، بما يتوافق مع ما تتحقق منه الاختبارات.

أتمتة الاختبارات باستخدام Playwright: تفاصيل الخدمة ←

نظام بيانات أو تطبيق تريد جعله موثوقًا؟

صِف سياقك، وسأرد عليك بالبريد الإلكتروني خلال يومَي عمل.