Can LLMs Test Terminal User Interfaces?

कल्पना कीजिए कि आप एक वीडियो गेम डेवलपर हैं। आपने एक सुंदर, जटिल दुनिया बनाई है जिसमें पहाड़, शहर और पात्र हैं, लेकिन आप यह परीक्षण करना भूल गए कि दरवाजे वास्तव में खुलते हैं या नहीं या खिलाड़ी दीवार में फंस जाता है या नहीं। सॉफ्टवेयर की दुनिया में, यह एक बुरा सपना है। इसे रोकने के लिए, प्रोग्रामर "स्वचालित परीक्षकों" (automated testers) का उपयोग करते हैं—रोबोटिक सहायक जो बटन क्लिक करते हैं, कमांड टाइप करते हैं, और वास्तविक उपयोगकर्ताओं से पहले बग्स खोजने के लिए सॉफ्टवेयर को तोड़ने की कोशिश करते हैं।

लंबे समय से, हमारे पास परीक्षण के लिए दो मुख्य प्रकार के सॉफ्टवेयर रहे हैं। पहला, ग्राफिकल यूजर इंटरफेस (GUI), जैसे आपके फोन या कंप्यूटर पर ऐप्स। ये रंगीन कमरों की तरह हैं जिनमें लेबल वाले दरवाजे, खिड़कियां और बटन हैं। टेस्टर आसानी से कंप्यूटर से पूछ सकते हैं, "'स्टार्ट' बटन कहाँ है?" और उस पर क्लिक कर सकते हैं। दूसरा, कमांड-लाइन इंटरफेस (CLI), जो पुराने जमाने के टेलीग्राफ की तरह हैं। आप एक गुप्त कोड टाइप करते हैं, और कंप्यूटर टेक्स्ट के रूप में जवाब देता है। इन्हें टेस्ट करना आसान है क्योंकि ये सरल हैं: यह टाइप करो, वह प्राप्त करो।

लेकिन यहाँ एक तीसरा, चालाक प्रकार का सॉफ्टवेयर है जिसे टर्मिनल यूजर इंटरफेस (TUI) कहा जाता है। इन्हें "रेट्रो-फ्यूचरिस्टिक" ऐप्स की तरह समझें। ये पुराने टेलीग्राफ (सिर्फ काले स्क्रीन पर टेक्स्ट) की तरह दिखते हैं, लेकिन फैंसी कमरों की तरह काम करते हैं। इनमें चलते हुए कर्सर, पॉप-अप मेनू और जटिल अवस्थाएं (states) होती हैं जो आपके टाइप करने के साथ बदलती रहती हैं। ये हैकर्स, सिस्टम एडमिनिस्ट्रेटर और यहाँ तक कि AI कोडिंग सहायकों के बीच लोकप्रिय हैं। समस्या यह है कि हमें उन्हें ठीक से टेस्ट करने का तरीका नहीं पता है। वे साधारण टेलीग्राफ परीक्षकों के लिए बहुत जटिल हैं, लेकिन उनमें फैंसी रूम परीक्षकों की तरह "लेबल वाले बटन" भी नहीं हैं। यह पेपर एक बड़ा सवाल पूछता है: क्या आधुनिक आर्टिफिशियल इंटेलिजेंस (AI) रोबोट इन पेचीदा टेक्स्ट-आधारित ऐप्स का परीक्षण करना सीख सकते हैं, या वे भी हमारी तरह ही भ्रमित हैं?

---

द ग्रेट TUI डिटेक्टिव स्टोरी

इस पेपर के पीछे के शोधकर्ताओं ने जासूसी करने का फैसला किया। उन्होंने 197 वास्तविक दुनिया के TUI अनुप्रयोगों का एक विशाल संग्रह इकट्ठा किया—फाइल मैनेजर से लेकर सिस्टम मॉनिटर तक—और उन्हें एक कठोर तनाव परीक्षण (stress test) से गुजारा। लेकिन सबसे पहले, उन्हें एक रहस्य सुलझाना था: इन ऐप्स का अभी कितनी अच्छी तरह से परीक्षण किया जा रहा है?

उन्होंने इन 197 ऐप्स के कोड के अंदर झाँका और एक चौंकाने वाला रहस्य पाया। परीक्षण करने वाले कोड का केवल लगभग 12% हिस्सा वास्तव में स्क्रीन के साथ इंटरैक्ट करने की कोशिश करता था। इससे भी बदतर यह था कि जो परीक्षण स्क्रीन को छूते थे, उनमें से लगभग आधे ने कभी एक भी कुंजी (key) टाइप नहीं की! उन्होंने बस यह जांचा कि ऐप खुलने पर स्क्रीन कैसी दिखती है, जैसे कार के इंजन को चालू किए बिना केवल उसके पेंट की जांच करना। यह स्पष्ट है कि अधिकांश TUI का परीक्षण आंखें बंद करके किया जा रहा है।

इसलिए, टीम ने अपना खुद का टूल बनाया यह देखने के लिए कि क्या होगा यदि वे AI और रैंडम संभावनाओं को इन ऐप्स पर छोड़ दें। उन्होंने एक "हेडलेस" लैब (एक कंप्यूटर जिसमें कोई स्क्रीन नहीं, बस एक वर्चुअल टर्मिनल है) बनाई और प्रत्येक ऐप को एक विशेष कंटेनर में पैक किया। फिर उन्होंने चार रणनीतियों के बीच एक दौड़ आयोजित की:

1. द रैंडम मंकी (The Random Monkey): एक रोबbot जो बस जितनी तेजी से हो सके रैंडम कुंजियाँ टाइप करता है।
2. द AI गाइड (The AI Guide): एक स्मार्ट लार्ज लैंग्वेज मॉडल (LLM) जो स्क्रीन को देखता है और तय करता है कि आगे क्या टाइप करना है।
3. द AI गाइड विद अ मैप (The AI Guide with a Map): वही स्मार्ट रोबोट, लेकिन इस बार इसने सही "लॉन्च कोड" (arguments) भी खोज लिए हैं ताकि ऐप्स को ठीक से शुरू किया जा सके।
4. द AI स्क्रिप्टराइटर (The AI Scriptwriter): एक रोबोट जो सोर्स कोड को पढ़ता है और शुरू करने से पहले एक टेस्ट प्लान लिखता है।

उन्होंने इन 197 ऐप्स के खिलाफ इन रणनीतियों को चलाया, प्रत्येक को बग्स खोजने के लिए ठीक 600 सेकंड (10 मिनट) दिए।

परिणाम: कौन जीतता है?

परिणाम आश्चर्यजनक और थोड़े विरोधाभासी थे।

1. "स्मार्ट" रोबोट सबसे तेज़ नहीं है।
जब शोधकर्ताओं ने देखा कि प्रत्येक रणनीति ने प्रति रन कितने बग्स खोजे, तो रैंडम मंकी ने वास्तव में सबसे अधिक क्रैश खोजे। क्यों? क्योंकि वह अविश्वसनीय रूप से तेज़ था। 600 सेकंड में, रैंडम रोबोट सैकड़ों कुंजियाँ टाइप कर सकता था। AI रोबोट, जो विचारशील और "स्मार्ट" थे, अपना अधिकांश समय सोचने और उत्तरों की प्रतीक्षा करने में बिता देते थे, इसलिए वे उसी समय में केवल एक दर्जन कुंजियाँ ही टाइप कर पाए।

2. लेकिन "स्मार्ट" रोबोट बहुत अधिक कुशल है।
यहाँ मोड़ है: यदि आप प्रति की-प्रेस (key press) मापते हैं, तो AI रोबोट रैंडम मंकी की तुलना में 13 गुना बेहतर थे। रैंडम मंकी बस अंधेरे में तीर चला रहा था और भाग्य से कुछ हिट कर रहा था। AI रोबरो लक्ष्य सटीक लगा रहे थे। वे अनूठे रूप से "इनपुट-गेटेड" बग्स (input-gated bugs) को खोजने में सक्षम थे—ऐसे क्रैश जो केवल तभी होते हैं जब आप किसी छिपे हुए मेनू को अनलॉक करने के लिए कुंजियों का एक विशिष्ट क्रम टाइप करते हैं। रैंडम मंकी कभी कोड नहीं समझ पाया, लेकिन AI ने कर दिखाया।

3. "लॉन्च कोड" ही असली नायक था।
सबसे बड़ी सफलता AI की बुद्धिमत्ता नहीं थी; बल्कि इसकी ऐप्स को शुरू करने के तरीके को समझने की क्षमता थी। कई TUI को शुरू होने के लिए विशिष्ट फाइलों या आर्गुमेंट्स की आवश्यकता होती है। इनके बिना, वे तुरंत बंद हो जाते हैं। वह रणनीति जिसने ऐप्स को शुरू करने के लिए AI का उपयोग करके स्वचालित रूप से लॉन्च इनपुट व्युत्पन्न (derive) किए, उसने सबसे अधिक बग्स खोजे और सबसे अधिक कोड कवर किया। यह सच है कि आप कार का परीक्षण नहीं कर सकते यदि आपको चाबी घुमाने का तरीका नहीं पता है।

4. "क्रैश" का जाल।
शोधकर्ताओं ने यह भी खोजा कि हम आमतौर पर बग्स को कैसे गिनते हैं, इसमें एक बड़ा जाल है। उन्होंने पाया कि 82% "क्रैश" (प्रोग्राम का अप्रत्याशित रूप से रुक जाना) वास्तव में प्रोग्राम द्वारा यह कहना था कि, "हे, मुझे एक फाइल चाहिए!" या "मुझे रुकने के लिए कहा गया था!" ये वास्तविक बग नहीं हैं; ये केवल सामान्य व्यवहार हैं। यदि आप केवल हर बार प्रोग्राम के रुकने को गिनते हैं, तो आपको गलत अलार्म मिलेगा। टीम को एक विशेष "क्रैश डिटेक्टर" बनाना पड़ा जो वास्तव में स्क्रीन पर मौजूद टेक्स्ट को देखता है कि क्या यह एक वास्तविक त्रुटि है या केवल एक विनम्र विदाई। एक बार जब उन्होंने शोर को फ़िल्टर कर दिया, तो उन्हें 197 ऐप्स में 179 वास्तविक, वैध बग्स मिले।

5. अधिक कोड कवरेज $\neq$ अधिक बग्स।
सॉफ्टवेयर टेस्टिंग में, लोग आमतौर पर मानते हैं कि यदि आप कोड की अधिक लाइनों को कवर करते हैं, तो आप अधिक बग ढूंढते हैं। पेपर सुझाव देता है कि यह TUI के लिए सच नहीं है। उन्होंने पाया कि जिन परीक्षणों ने सबसे अधिक क्रैश खोजे, उनमें अक्सर कम कोड कवरेज था। क्यों? क्योंकि एक क्रैश मिलना परीक्षण को तुरंत रोक देता है! परीक्षण बीच में ही कट जाता है, इसलिए यह कोड के बाकी हिस्सों को कभी कवर नहीं कर पाता। इसका मतलब है कि TUI के लिए, यह गिनना कि कितने कोड लाइनों को छुआ गया है, यह मापने का एक बुरा तरीका है कि एक टेस्ट कितना अच्छा है।

निष्कर्ष

पेपर यह निष्कर्ष निकालता है कि इन टेक्स्ट-आधारित इंटरफेस के लिए स्वचालित परीक्षण संभव है, लेकिन यह अभी तक पूरी तरह हल नहीं हुआ है। कोई भी एक AI मॉडल स्पष्ट विजेता नहीं था; वास्तव में, एक साधारण रैंडम टेस्टर प्रतिस्पर्धी था क्योंकि वह तेज़ था। सफलता की असली कुंजी हाइब्रिड रणनीतियाँ थीं: ऐप को शुरू करने और सही स्थिति (state) तक नेविगेट करने के लिए AI का उपयोग करना, और फिर इंटरफ़ेस का तनाव परीक्षण करने के लिए उच्च-गति वाले रैंडम टेस्टिंग का उपयोग करना।

लेखक हमें चेतावनी भी देते हैं कि हमें बेहतर उपकरणों की आवश्यकता है। परीक्षण करने का वर्तमान तरीका (केवल यह देखना कि प्रोग्राम रुक जाता है) गलत अलार्म से भरा हुआ है। उन्होंने अपने स्वयं के उपकरण, tuicov और tuibot, जारी किए हैं ताकि अन्य लोग इन ऐप्स का ठीक से परीक्षण कर सकें। संदेश स्पष्ट है: TUI हमारे सॉफ्टवेयर जगत का एक बड़ा, बढ़ता हुआ हिस्सा हैं, लेकिन वे वर्तमान में परीक्षण के "वाइल्ड वेस्ट" (अराजक क्षेत्र) हैं। हमारे पास उन्हें पालतू बनाने के लिए उपकरण हैं, लेकिन हमें पुराने नियमों पर भरोसा करना बंद करना होगा और ऐसे परीक्षणों को डिजाइन करना शुरू करना होगा जो इन इंटरफेस की अनूठी, टेक्स्ट-आधारित प्रकृति को समझते हों।