💬 NLP

WebTestBench: Evaluating Computer-Use Agents towards End-to-End Automated Web Testing

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

المؤلفون الأصليون: Fanheng Kong, Jingyuan Zhang, Yang Yue, Chenxi Sun, Yang Tian, Shi Feng, Xiaocui Yang, Daling Wang, Yu Tian, Jun Du, Wenchong Zeng, Han Li, Kun Gai

نُشر 2026-03-27

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Fanheng Kong, Jingyuan Zhang, Yang Yue, Chenxi Sun, Yang Tian, Shi Feng, Xiaocui Yang, Daling Wang, Yu Tian, Jun Du, Wenchong Zeng, Han Li, Kun Gai

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

المشكلة:
نظرت إلى الموقع، وبدا رائعًا حقًا. ولكن هل يعمل بالفعل؟

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

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

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

إليك كيف أعدوا هذا الاختبار:

"الامتحان" (المعيار المرجعي): أنشأوا 100 سيناريو مختلف لمواقع إلكترونية (مثل متجر حيوانات أليفة، أو نظام جدولة غرف اجتماعات، أو مدونة). استخدموا الذكاء الاصطناعي لبناء هذه المواقع، مع تعمد ترك بعض الأخطاء (Bugs) التي صنعها الذكاء الاصطناعي ليكون هناك شيء يمكن العثور عليه.
"المعيار الذهبي" (نموذج الإجابة): نظر خبراء بشريون إلى هذه المواقع وكتبوا قائمة مثالية بالأشياء التي يجب فحصها. لم يكتفوا بفحص ما إذا كان الزر يعمل؛ بل فحصوا "المنطق غير المرئي"، مثل: "إذا حجزت غرفة في الساعة 2 ظهرًا، فلا ينبغي للنظام أن يسمح لي بحجزها مرة أخرى في الساعة 2:30 ظهرًا".
"المتقدم للاختبار" (الوكيل): أخذوا نماذج ذكاء اصطناعي قوية مختلفة وطلبوا منها العمل كمختبرين. كان على الذكاء الاصطناعي القيام بشيئين:
- الخطوة 1: كتابة قائمة مراجعته الخاصة. بدلًا من إخباره بما يجب فحصه، كان على الذكاء الاصطناعي أن يستنتج: "مهلاً، أحتاج إلى التحقق مما إذا كان شريط البحث يعمل وما إذا كانت الصور تطابق الأوصاف".
- الخطوة 2: اختبار الموقع فعليًا. كان على الذكاء الاصطناعي النقر على الأزرار، وكتابة النصوص، والتنقل في الموقع لمعرفة ما إذا كان قد اجتاز الاختبار أم فشل.

النتائج: مواجهة الواقع
كانت النتائج صادمة نوعًا ما. حتى أكثر نماذج الذكاء الاصطناعي ذكاءً (مثل GPT-5 وClaude) سجلت درجات منخفضة جدًا — أقل من 30% من الدقة.

"النقطة العمياء": كان مختبرو الذكاء الاصطناعي سيئين جدًا في كتابة قائمة مراجعة كاملة. لقد فاتهم حوالي 40% من الأشياء التي كان يجب اختبارها. الأمر يشبه حارس أمن ينسى فحص الباب الخلفي.
"الإنذارات الكاذبة": عندما وجدوا شيئًا ما، كانوا غالبًا ما يصرخون "ذئب!" بينما لا يوجد ذئب. اعتقدوا أن زرًا يستغرق وقتًا طويلاً في التحميل هو زر معطل.
مشكلة "الذاكرة الطويلة": اختبار موقع معقد يتطلب خطوات عديدة (انقر هنا، انتظر، اكتب هناك، انقر مرة أخرى). ارتبك الذكاء الاصطناعي بعد فترة، ونسي ما كان يفعله قبل 10 خطوات.

لماذا يهم هذا؟
نحن ندخل عصر "برمجة الانطباعات" (Vibe Coding)، حيث يمكن لأي شخص بناء برمجيات بمجرد الدردشة مع الذكاء الاصطناعي. ولكن إذا بنى الذكاء الاصطناعي موقعًا إلكترونيًا ينهار عندما يحاول 10 أشخاص شراء تذاكر في وقت واحد، فستكون كارثة.

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

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

إليك ملخص تقني مفصل لورقة البحث بعنوان: "WebTestBench: تقييم وكلاء استخدام الحاسوب نحو اختبار الويب الآلي من الطرف إلى الطرف (End-to-End)."

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

أدى صعود "برمجة النبض" (vibe coding) -وهي استخدام النماذج اللغوية الكبيرة لتوليد تطبيقات ويب كاملة عبر اللغة الطبيعية- إلى نقل عنق الزجاجة في تطوير البرمجيات من مرحلة البرمجة إلى مرحلة الاختبار. وبينما تستطيع النماذج اللغوية الكبيرة توليد الكود، فإن التحقق من موثوقية هذه التطبيقات المولدة وظيفياً ومنطقياً يظل تحدياً حرجاً.

تعاني معايير اختبار الويب المؤتمتة الحالية من ثلاثة عيوب رئيسية:

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

المشكلة الجوهرية هي غياب معيار وإطار عمل قادر على تقييم اختبار الويب الآلي من الطرف إلى الطرف حيث يجب على الوكلاء توليد قوائم مراجعة الاختبار ذاتياً واكتشاف العيوب دون تدخل بشري.

2. المنهجية

أ. WebTestBench (المعيار المرجعي)

قدم المؤلفون WebTestBench، وهو مجموعة بيانات وإطار تقييم مصمم لمحاكاة سيناريوهات تطوير الويب الواقعية المدفوعة بالذكاء الاصطناعي.

بناء البيانات:
- المصدر: تم جمع 100 فكرة متنوعة لتطبيقات الويب من مجتمعات المطورين، وتصفيتها وتنميطها في تعليمات تطوير رسمية.
- التوليد: تم توليد التطبيقات باستخدام Lovable.dev (منصة تطوير ويب مدعومة بالذكاء الاصطناعي) لإنشاء صفحات ويب وظيفية تحتوي على عيوب تحدث بشكل طبيعي.
- الترميز (Annotation): قام مُرمّزون بشريون بإنشاء "قائمة مراجعة ذهبية" (Gold Checklist) لكل تطبيق، مع تصنيف عناصر الاختبار إلى أربعة أبعاد:
  1. الوظيفية (Functionality): إكمال المهام الأساسية.
  2. القيد (Constraint): القواعد المنطقية والظروف الحدية (مثل التحقق من صحة المدخلات، وثوابت الحالة).
  3. التفاعل (Interaction): التغذية الراجعة الديناميكية وتغيرات حالة واجهة المستخدم.
  4. المحتوى (Content): التوافق الدلالي للنصوص/الصور مع التعليمات.
- حقن العيوب: تضمن عملية الصقل المتكررة احتواء كل تطبيق على عيوب كافية (عناصر نجاح/فشل) للتقييم الصارم.
مقاييس التقييم:
- التغطية (Coverage): تقيس مدى اكتمال قائمة المراجعة التي ولدها الوكيل مقارنة بالمعيار الذهبي.
- اكتشاف العيوب: يعامل اكتشاف العيوب كمهمة تصنيف ثنائي (نجاح/فشل). وتشمل المقاييس الدقة (Precision)، والاستدعاء (Recall)، ومقياس F1، والتي تُحسب عبر مطابقة العناصر المتوقعة مع العناصر الذهبية باستخدام حكم دلالي (Qwen3.5-27B).

ب. WebTester (إطار العمل المرجعي)

لتقييم الوكلاء على WebTestBench، اقترح المؤلفون WebTester، وهو إطار عمل متتالي ذو مرحلتين:

وكيل توليد قائمة المراجعة ( $A_C$ ): يأخذ تعليمات المستخدم ويقوم بتفكيكها إلى قائمة مراجعة اختبار مهيكلة وقابلة للتنفيذ ( $T_{pred}$ ). يتضمن كل عنصر وصفاً، وإجراءً (مثل النقر، الكتابة)، ونتيجة متوقعة.
وكيل اكتشاف العيوب ( $A_D$ ): ينفذ قائمة المراجعة المولدة عبر محاكاة التفاعلات البشرية (باستخدام Playwright MCP) على تطبيق الويب المستهدف. ويحدد حكم النجاح/الفشل لكل عنصر ويولد تقارير الأخطاء في حالات الفشل.

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

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

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

قام المؤلفون بتقييم 10 نماذج لغوية كبيرة شهيرة (بما في ذلك GPT-5، Claude 4.5، Qwen3، GLM-5) باستخدام إطار عمل WebTester.

الأداء العام: أدت جميع النماذج أداءً ضعيفاً، حيث كانت درجات F1 أقل من 30%. أفضل أداء حققه GPT-5.1 بنسبة 26.4%.
الاختناقات الرئيسية المحددة:
- عدم كفاية اكتمال الاختبار: كانت التغطية باستمرار أقل من 70%. فشلت الوكلاء في توليد حالات اختبار للمتطلبات الضمنية، مما أدى إلى ارتفاع حالات "السالب الكاذب" (False Negatives).
- اختناقات الاكتشاف:
  - الإيجابيات الكاذبة (False Positives): أخطأت النماذج غالباً في تفسير تأخيرات واجهة المستخدم العابرة أو التحديثات غير المتزامنة على أنها أخطاء (الدقة ~30%).
  - السوالب الكاذبة (False Negatives): واجهت النماذج صعوبة في اكتشاف العيوب الفعلية، وغالباً ما كانت تلجأ إلى خيار "النجاح" بسبب "انحياز الصحة الافتراضي".
- عدم الموثوقية في المهام طويلة المدى: أدت المهام المعقدة التي تتطلب عشرات الدورات التفاعلية إلى فشل في التتبع وتكرار العمليات.
تحليل الأبعاد:
- الوظيفية: أعلى تغطية (المتطلبات الصريحة أسهل في الاستخراج).
- القيد: بمجرد تغطيته، كان الاكتشاف سهلاً نسبياً (إشارات واضحة).
- المحتوى: أسوأ أداء؛ واجهت النماذج صعوبة في التحقق من التوافق الدلالي للمحتوى المعروض.
تحليل إعداد "الأوراكل" (Oracle Setting): عند تزويد النماذج بـ القائمة الذهبية مباشرة (تجاوز مرحلة التوليد)، تحسن الأداء بشكل ملحوظ (F1 ~40-50% لأفضل النماذج). وهذا يؤكد أن توليد قائمة المراجعة هو الاختناق الرئيسي للنماذج مغلقة المصدر، بينما تعاني النماذج مفتوحة المصدر من صعوبات في كل من التوليد والاكتشاف.
تحليل الفئات: أدت النماذج بشكل أفضل في إدارة البيانات (حيث تكون انتقالات الحالة قابلة للملاحظة) وأسوأ في المحتوى الذي ينشئه المستخدم والبحث (التي تتطلب تحققاً دلالياً تجريدياً).

5. الأهمية والتوجهات المستقبلية

تحول النموذج: تسلط الورقة الض الضوء على أنه مع أتمتة البرمجة بالذكاء الاصطناعي، يصبح الاختبار الآلي هو العنق الحرج. وكلاء استخدام الحاسوب (CUAs) الحاليون ليسوا مستعدين بعد للنشر في المستوى الصناعي في هذا المجال.
توجيه البحث: تشير النتائج إلى أن الوكلاء في المستقبل يحتاجون إلى:
- تفكير أفضل لتحديد المتطلبات الضمنية والقيود المنطقية.
- تحسين التخطيط طويل المدى وتتبع الحالة.
- استراتيجيات أكثر قوة للتمييز بين مشكلات الرندرة (Rendering) العابرة والعيوب الوظيفية الفعلية.
توافر الموارد: تم جعل مجموعة البيانات، الكود، وبروتوكولات التقييم مفتوحة المصدر لتعزيز المزيد من الأبحاث في ضمان جودة البرمجيات المدعومة بالذكاء الاصطناعي.

في الختام، يكشف WebTestBench عن فجوة كبيرة بين قدرات النماذج اللغوية الكبيرة الحالية ومتطلبات اختبار الويب الآلي الموثوق، مما يوفر أساساً حيوياً لتطوير الجيل القادم من أدوات التحقق من "برمجة النبض".