MASTOR: A Multi-Agent Approach to Semantic Test Oracle Generation for RESTful APIs
MASTOR एक मल्टी-एजेंट फ्रेमवर्क है जो RESTful APIs के लिए सिमेंटिक टेस्ट ओरेकल (semantic test oracles) उत्पन्न करने के लिए सोर्स कोड विश्लेषण और एक चैलेंजर-एजेंट समीक्षा प्रक्रिया का लाभ उठाता है, जो बिजनेस लॉजिक उल्लंघनों का पता लगाने में मौजूदा बेसलाइन से काफी बेहतर प्रदर्शन करता है और 75.4% म्यूटेशन स्कोर प्राप्त करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल, जटिल फैक्ट्री की जांच करने के लिए निरीक्षकों की एक टीम को काम पर रख रहे हैं जो डिजिटल उत्पाद (APIs) बनाती है। इस फैक्ट्री में सैकड़ों अलग-अलग मशीनें (endpoints) हैं जो इनपुट लेती हैं और उत्पाद बाहर निकालती हैं।
पारंपरिक रूप से, इन मशीनों का परीक्षण करते समय, निरीक्षक केवल शिपिंग लेबल की जांच करते हैं। वे पूछते हैं: "क्या मशीन चालू हुई? क्या इसने 'सफलता' का स्टिकर (HTTP 200) वापस दिया? क्या बॉक्स का आकार सही है?" यदि स्टिकर हरा है और बॉक्स सही दिखता है, तो निरीक्षक कहता है, "सब ठीक है!"
समस्या:
यह शोध पत्र तर्क देता है कि यह खतरनाक है। एक मशीन अंदर से खराब हो सकती है, गलत उत्पाद बना सकती है, लेकिन फिर भी बॉक्स पर एक सटीक "सफलता" का स्टिकर चिपका सकती है और सही आकार बनाए रख सकती है। लेबल यह नहीं बताता कि बॉक्स के अंदर वास्तव में वही उत्पाद है जो ग्राहक ने ऑर्डर किया था। यह एक "सिमेंटिक" (semantic) विफलता है—लॉजिक गलत है, भले ही सतह पर सब कुछ ठीक दिख रहा हो।
समाधान: MASTOR
लेखकों ने MASTOR (Multi-Agent Approach to Semantic Test Oracle Generation) नामक एक नया सिस्टम बनाया है। शिपिंग लेबल को देखने के बजाय, MASTOR विशेषज्ञों की एक टीम को फैक्ट्री के फर्श पर भेजता है, ब्लूप्रिंट (सोर्स कोड) को पढ़ता है, और ठीक यह समझता है कि प्रत्येक मशीन को वास्तव में कैसे काम करना चाहिए।
MASTOR कैसे काम करता है, इसे सरल चरणों में यहाँ दिया गया है:
1. ब्लूप्रिंट रीडर (सोर्स विश्लेषण)
परीक्षण करने से पहले, MASTOR एक सोर्स एक्सट्रैक्शन एजेंट को फैक्ट्री में भेजता है।
- यह क्या करता है: यह केवल एक मशीन को नहीं देखता; यह उस मशीन से जुड़े हर तार, पाइप और निर्देश पुस्तिका (एक "ट्रांजिटिव इम्पोर्ट क्लोजर") का पता लगाता है।
- परिणाम: यह प्रत्येक मशीन के लिए एक विस्तृत "सोर्स कॉन्टेक्स्ट" बनाता है। यह एक 'चीट शीट' की तरह है जो कहती है: "यदि आप 2 से छोटी संख्या डालते हैं, तो मशीन को 'बैड रिक्वेस्ट' एरर देना ही होगा। यदि आप एक वैध नाम डालते हैं, तो इसे विशिष्ट राजधानी लौटानी ही होगी।"
2. दो-ट्रैक निरीक्षण टीम (ओरेकल जनरेशन)
एक बार जब चीट शीट्स तैयार हो जाती हैं, तो MASTOR काम को दो समानांतर टीमों में विभाजित करता है:
- टीम A (सिंगल-ऑपरेशन पाथ): ये एजेंट एक समय में एक मशीन को देखते हैं। वे पूछते हैं: "यदि मैं इस मशीन को खराब इनपुट देता हूँ, तो क्या यह सही एरर कोड के साथ क्रैश होती है? यदि मैं इसे अच्छा इनपुट देता हूँ, तो क्या यह सटीक डेटा फील्ड्स लौटाती है?" वे यह सुनिश्चित करने के लिए चार अलग-अलग रणनीतियों (जैसे बाउंड्रीज की जांच करना और लॉजिक को उलटना) का उपयोग करते हैं कि वे कुछ भी मिस न करें।
- टीम B (मल्टी-ऑपरेशन पाथ): ये एजेंट देखते हैं कि मशीनें एक-दूसरे से कैसे बात करती हैं। उदाहरण के लिए, मशीन A एक यूजर बनाती है और उन्हें एक ID देती है। मशीन B को उस यूजर का प्रोफाइल प्राप्त करने के लिए उस ID की आवश्यकता होती है। टीम B जांच करती है: "क्या मशीन A ने वास्तव में ID को सही ढंग से सेव किया ताकि मशीन B बाद में उसे ढूंढ सके?" यह उन त्रुटियों को पकड़ता है जो तब होती हैं जब मशीनें मिलकर काम करती हैं।
3. सख्त संपादक (चैलेंजर एजेंट)
यही असली सफलता का मंत्र है। टीमों द्वारा अपने निरीक्षण नियम (ओरेकल) लिखने के बाद, वे उन्हें सीधे जमा नहीं करती हैं।
- समीक्षा: एक समर्पित चैलेंजर एजेंट (एक सख्त संपादक) हर नियम को पढ़ता है। वह पूछता है: "क्या आप पक्का हैं? क्या आपने वास्तव में ब्लूप्रिंट पढ़ा है, या आप केवल अनुमान लगा रहे हैं?"
- सुधार: यदि संपादक को कोई कमजोर नियम या अनुमान मिलता है, तो वह मूल टीम को एक नोट के साथ वापस भेजता है: "जाओ और इस विशिष्ट भाग को ठीक करो।" टीम केवल उसी भाग को फिर से लिखती है। यह सुनिश्चित करता है कि अंतिम नियम ठोस और वास्तविक साक्ष्य पर आधारित हों, न कि केवल कल्पनाओं पर।
4. अंतिम रिपोर्ट (नॉर्मलाइजेशन और आउटपुट)
अंत में, सिस्टम नियमों को साफ करता है, जो समझ में नहीं आते उन्हें हटा देता है, और उन्हें तीन उपयोगी प्रारूपों में बदल देता है:
- एक्सेक्यूटेबल कोड: जो स्वचालित रूप से CI/CD पाइपलाइन में चलने के लिए तैयार है (जैसे कि एक रोबोट जो हर रात फैक्ट्री की जांच करता है)।
- Postman स्क्रिप्ट्स: जो डेवलपर्स को मैन्युअल रूप से परीक्षण करने के लिए तैयार हैं।
- मानव पठनीय (Human Readable): एक साधारण अंग्रेजी विवरण ताकि एक इंसान समझ सके कि कोई टेस्ट क्यों मौजूद है।
परिणाम (स्कोरबोर्ड)
लेखकों ने इसे 13 वास्तविक दुनिया के फैक्ट्री प्रोजेक्ट्स (जिसमें 250,000 से अधिक लाइनों का कोड और 296 अलग-अलग मशीनें शामिल थीं) पर परखा।
- स्कोर: MASTOR ने छिपे हुए बग्स (म्यूटेशन) के 75.4% को पकड़ा जो कोड में डाले गए थे।
- तुलना:
- केवल शिपिंग लेबल के आधार पर नियम का अनुमान लगाने वाले स्मार्ट AI (डायरेक्ट प्रॉम्प्टिंग) की तुलना में, MASTOR 30% बेहतर था।
- केवल आधिकारिक मैनुअल को पढ़ने वाले टूल (SATORI) की तुलना में, MASTOR 49% बेहतर था।
- क्यों? क्योंकि SATORI और डायरेक्ट प्रॉम्प्टिंग जो लिखा गया है या जो अनुमान लगाया गया है उस पर निर्भर करते हैं। MASTOR उस पर निर्भर करता है जो वास्तव में कोड किया गया है। यदि मैनुअल कहता है "एक लिस्ट लौटाएं," लेकिन कोड कहता है "लिस्ट तभी लौटाएं जब यूजर एडमिन हो," तो MASTOR सच्चाई जानता है क्योंकि उसने कोड पढ़ा है।
लागत
यह सिस्टम एक साधारण अनुमान की तुलना में चलाने में थोड़ा महंगा है (औसतन प्रति API लगभग $0.56), लेकिन लेखक तर्क देते हैं कि यह उन गहरे, छिपे हुए लॉजिक एरर्स को खोजने के लिए सार्थक है जिन्हें अन्य उपकरण मिस कर देते हैं।
संक्षेप में:
MASTOR एक विशेषज्ञ जासूसों की टीम को काम पर रखने जैसा है जो केवल उत्पाद की पैकेजिंग की जांच नहीं करते; वे यह सुनिश्चित करने के लिए फैक्ट्री के आंतरिक वायरिंग डायग्राम को पढ़ते हैं कि उत्पाद के अंदर बिल्कुल वही है जो होना चाहिए। वे एक-दूसरे को क्रॉस-चेक करते हैं ताकि कोई भी गलती निकल न जाए, जिसके परिणामस्वरूप सॉफ्टवेयर के लिए बहुत उच्च गुणवत्ता वाला सुरक्षा जाल तैयार होता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।