Can LLMs Test Terminal User Interfaces?

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

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

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

---

قصة المحقق العظيم لواجهات الـ TUI

قرر الباحثون وراء هذه الورقة لعب دور المحقق. فقد جمعوا مجموعة ضخمة من 197 تطبيق TUI من العالم الحقيقي—بدءاً من مديري الملفات وصولاً إلى مراقبي النظام—ووضعوها تحت اختبار جهد صارم. ولكن أولاً، كان عليهم حل لغز: ما مدى جودة اختبار هذه التطبيقات حالياً؟

لقد استرقوا النظر داخل كود هذه التطبيقات الـ 197 ووجدوا سراً صادماً. حوالي 12% فقط من كود الاختبار حاول فعلياً التفاعل مع الشاشة. والأسوأ من ذلك، أن ما يقرب من نصف الاختبارات التي لمست الشاشة لم تكتب حرفاً واحداً! لقد اكتفوا فقط بالتحقق مما إذا كانت الشاشة تبدو صحيحة عند فتح التطبيق لأول مرة، مثل التحقق من طلاء السيارة دون تشغيل المحرك أبداً. اتضح أن معظم تطبيقات الـ TUI يتم اختبارها وأعينهم مغمضة.

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

1. القرد العشوائي: وهو روبوت يكتب مفاتيح عشوائية بأقصى سرعة ممكنة.
2. الدليل الذكي (AI Guide): وهو نموذج لغوي كبير (LLM) ذكي ينظر إلى الشاشة ويقرر ما الذي يجب كتابته بعد ذلك.
3. الدليل الذكي مع خريطة: وهو نفس الروبوت الذكي، ولكن هذه المرة يمتلك أيضاً القدرة على معرفة "رموز الإطلاق" (arguments) الصحيحة لتشغيل التطبيقات بشكل سليم.
4. كاتب السيناريو الآلي (AI Scriptwriter): وهو روبوت يقرأ الكود المصدري ويكتب خطة اختبار قبل البدء.

قاموا بتشغيل هذه الاستراتيجيات ضد الـ 197 تطبيقاً، ومنحوا كل منها 600 ثانية (10 دقائق) بالضبط للعثور على الأخطاء.

النتائج: من الفائز؟

كانت النتائج مفاجئة وغير متوقعة تماماً.

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

2. لكن الروبوت "الذكي" أكثر كفاءة بكثير.
هنا تكمن المفاجأة: إذا قمت بقياس مدى جودتهم لكل ضغطة مفتاح، وجدت أن روبوتات الذكاء الاصطناعي كانت أفضل بـ 13 مرة من القرد العشوائي. كان القرد العشوائي يرمي السهام في الظلام ويصيب بعضها بالصدفة، أما روبوتات الذكاء الاصطناعي فكانت تصوب بدقة. لقد كانت قادرة بشكل فريد على إيجاد الأخطاء "المعتمدة على المدخلات" (input-gated bugs)—وهي الانهيارات التي تحدث فقط إذا كتبت تسلسلاً معيناً من المفاتيح لفتح قائمة مخفية. القرد العشوائي لم يستطع أبداً اكتشاف الرمز، لكن الذكاء الاصطناعي فعل ذلك.

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

4. فخ "الانهيار" (The Crash Trap).
اكتشف الباحثون أيضاً فخاً كبيراً في طريقة عدّنا للأخطاء عادةً. وجدوا أن 82% من "الانهيارات" (توقف البرامج بشكل غير متوقع) كانت في الواقع مجرد رسائل من البرامج تقول: "مهلاً، أنا أحتاج إلى ملف!" أو "لقد أُمرت بالتوقف!". هذه ليست أخطاء حقيقية، بل هي سلوك طبيعي. إذا قمت فقط بعدّ كل مرة يتوقف فيها البرنامج، ستحصل على إنذارات كاذبة. اضطر الفريق لبناء "كاشف انهيار" خاص ينظر إلى النص الفعلي على الشاشة ليرى ما إذا كان خطأً حقيقياً أم مجرد خروج مهذب. بمجرد تصفية الضجيج، وجدوا 179 خطأً حقيقياً وصحيحاً عبر الـ 197 تطبيقاً.

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

الخلاصة

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

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