Automated Web Application Testing: End-to-End Test Case Generation with Large Language Models and Screen Transition Graphs

إليك ملخص تقني مفصل للورقة البحثية بعنوان "اختبار تطبيقات الويب المؤتمت: توليد حالات الاختبار من البداية إلى النهاية باستخدام النماذج اللغوية الكبيرة ورسوم الانتقال بين الشاشات."

1. بيان المشكلة

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

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

2. المنهجية

يقترح المؤلفون نظاماً مؤتمتاً يدمج الهياكل الرسومية (رسوم انتقال الشاشات ورسوم الحالة البيانية) مع النماذج اللغوية الكبيرة (LLMs) لتوليد حالات اختبار من البداية إلى النهاية. تنقسم العملية إلى وحدتين رئيسيتين:

أ. توليد اختبار تنقل الموقع

تركز هذه الوحدة على التحقق من إمكانية الوصول إلى صفحات ويب محددة من نقطة بداية.

1. بناء الرسم البياني: يقوم النظام بعملية زحف للويب تعتمد على Selenium لبناء رسم انتقال الشاشات (Screen Transition Graph).
   • العقد (Nodes): تمثل صفحات الويب (تتضمن الرابط URL، محتوى HTML، والبيانات الوصفية).
   • الحواف (Edges): تمثل مسارات التنقل (الروابط، الأزرار) بين الصفحات.
2. تحديد المسار: بالنظر إلى صفحة البداية والوجهة، يستخدم النظام خوارزمية ديكسترا (Dijkstra's algorithm) لإيجاد أقصر مسار في رسم انتقال الصفحات.
3. توليد الإجراءات: لكل حافة في المسار المحدد، يقوم نموذج لغوي كبير بتوليد أوصاف تفصيلية بلغة طبيعية لإجراءات المستخدم المطلوبة (مثل "انقر على زر 'المدونة'").
4. بناء السيناريو: يتم تجميع هذه الإجراءات في سيناريو اختبار مهيكل وقابل للتنفيذ مع النتائج المتوقعة.

ب. توليد اختبار ملء النماذج

تعالج هذه الوحدة تعقيد النماذج الثابتة والديناميكية.

1. تصنيف النماذج: تُصنف النماذج إلى بسيطة (هيكل ثابت) أو ديناميكية (حقول شرطية تتغير بناءً على مدخلات المستخدم).
2. بناء رسم الحالة البياني: يستخدم النظام رسم حالة (State Graph) لنمذجة تفاعلات النموذج.
   • العقد: تمثل حالات النموذج المختلفة.
   • الحواف: تمثل تفاعلات المستخدم التي تنقل النموذج من حالة إلى أخرى.
3. الاستكشاف المتكرر للحالة (الخوارزمية 1):
   • يقوم النظام بالمرور عبر جميع العناصر القابلة للتفاعل في النموذج.
   • يلتقط حالة HTML، ويحاكي تفاعلاً، ثم يلتقط HTML الجديد.
   • إذا تغير HTML، يتم حفظ حالة جديدة، وتقوم الخوارزمية بالاستكشاف المتكرر (Recursively) لمزيد من التفاعلات داخل تلك الحالة الجديدة.
   • آلية التراجع (Backtracking): بما أن برامج تشغيل Selenium لا تدعم بطبيعتها "التراجع" عن الإجراءات، فإن النظام يحتفظ بقائمة من التفاعلات لإعادة تشغيل التسلسل والعودة إلى الحالة السابقة بعد الاستكشاف المتكرر.
4. توليد السكريبت (Script Generation): بمجرد استكشاف جميع الحالات، يقوم النموذج اللغوي الكبير بتوليد سكريبتات Selenium لكل عقدة ورقية (الحالة النهائية) لاختبار تكوينات محددة.

3. المساهمات الرئيسية

1. دمج جديد بين الرسم البياني والنموذج اللغوي الكبير للتنقل: نهج جديد يجمع بين رسوم انتقال الشاشات والنماذج اللغوية الكبيرة لأتمتة توليد سيناريوهات اختبار التنقل، مما يضمن تغطية شاملة للمسارات.
2. أتمتة النماذج القائمة على رسم الحالة: منهجية تستخدم رسوم الحالة لنمذجة واستكشاف النماذج الشرطية المعقدة، مما يتيح التوليد الآلي لسكريبتات Selenium لجميع تكوينات النماذج الممكنة.
3. مجموعة بيانات مرجعية شاملة: إنشاء مجموعة بيانات تقييم قوية تتكون من:
   • 2,000 نموذج اصطناعي قائم على القواعد: 1,000 نموذج بسيط و1,000 نموذج ديناميكي مع مستويات متفاوتة من التعقيد ومنطق الحقول "المطلوبة".
   • 133 نموذجاً من العالم الحقيقي: تم جمعها من مجالات متنوعة (التجارة الإلكترونية، أنظمة إدارة المحتوى، الشبكات الاجتماعية) لاختبار التطبيق العملي.

4. النتائج التجريبية

تم تقييم النظام باستخدام كل من النماذج مغلقة المصدر (GPT-4o, GPT-4o-mini) والنماذج مفتوحة المصدر (DeepSeek Distill, Qwen, Llama).

• أداء تنقل الموقع:
  • حقق GPT-4o-mini أعلى أداء إجمالي، حيث تميز في الوضوح، الدقة، والاكتمال.
  • تفوقت النماذج الأكبر عموماً على النماذج الأصغر، رغم أن المتانة (Robustness) (التعامل مع الأخطاء غير المتوقعة) ظلت تحدياً لجميع النماذج.
• أداء ملء النماذج:
  • أظهر GPT-4o دقة فائقة عبر جميع الإعدادات (البسيطة، الديناميكية، والعالم الحقيقي)، خاصة في التعامل مع السيناريوهات المهيكلة والمعقدة.
  • النماذج الديناميكية: أظهرت معظم النماذح انخفاضاً ملحوظاً في الأداء في النماذج الديناميكية مقارنة بالبسيطة، مما يسلط الض الضوء على صعوبة التعامل مع المنطق الشرطي المعقد.
  • تحليل نوع الحقول: عمل النظام بشكل جيد مع الحقول الشائعة (النص، خانة الاختيار، التاريخ) لكنه واجه صعوبة مع الحقول المخفية والملفات، وكذلك قواعد التحقق المعقدة في نماذج العالم الحقيقي.
• التغطية: حسن النظام تغطية الاختبار بشكل كبير من خلال استكشاف مساحات الحالة بشكل منهجي، وهو ما غالباً ما تغفله الاختبارات اليدوية.

5. الأهمية

يعمل هذا العمل على تطوير حالة اختبار تطبيقات الويب من خلال:

• توحيد سير العمل: سد الفجوة بين نمذجة التنقل والتحقق من النماذج في إطار عمل واحد قابل للتوسع.
• التعامل مع التعقيد: توفير حل منهجي لـ "الانفجار التوافقي" للحالات في النماذج الديناميكية من خلال الاستكشاف المتكرر للحالة.
• تقليل الجهد البشري: أتمتة إنشاء سكريبتات Selenium، مما يقلل من الطبيعة المستهلكة للوقت والعرضة للخطأ في توليد حالات الاختبار اليدوية.
• وضع معيار مرجعي: إنشاء مجموعة بيانات جديدة لتقييم اختبار التفاعل مع النماذج، مما يسهل الأبحاث المستقبلية في مجال اختبار البرمجيات المدعوم بالذكاء الاصطناعي.

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