هل يمكن لنماذج اللغات الضخمة اختبار واجهات المستخدم الطرفية؟ 🚀

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

في دراسة مثيرة، تم تقييم 197 تطبيق TUI حقيقي. النتائج كانت مفاجئة، حيث تبين أن 12% فقط من رموز الاختبار تستخدم واجهة المستخدم، و45% من هذه الاختبارات لا ترسل مدخلات، بل تفحص إطاراً ثابتاً بدلاً من ذلك.

لذا، قمنا بتطوير معيار تحليل بدون واجهة مستخدم، يشمل تطبيقات مثل ratatui وRust وbubbletea وGo وtextual وPython وink وTypeScript، مع تعبئة كل منها في صورة Docker مجهزة. تم تسجيل تغطية الأسطر والواجهات حيثما كان ذلك ممكنًا، بالإضافة إلى حالات حدوث الأعطال.

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

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

الاختبار الآلي لواجهات المستخدم الطرفية ممكن لكنه لا يزال في مراحله الأولى، والاعتماد على نقاط البداية الموثوقة أهم من اختيار النموذج. ولتسهيل هذه العملية، أطلقت مجموعة الباحثين الأداة tuicov وأطر الاختبار tuibot، مما يحول طريقة تعامل المطورين مع اختبار TUI.